A Network Voice Protocol NVP-II

Size: px
Start display at page:

Download "A Network Voice Protocol NVP-II"

Transcription

1 ISI / RR A Network Voice Protocol NVP-II by Danny Cohen Stephen Casner James W. Forgie U S C / I S I 4676 Admiralty Way Marina del Rey, California Lincoln Laboratory Massachusetts Institute of Technology 244 Wood Street Lexington, MA April 1st, 1981

2 N V P - II NVP-II was born after a very long pregnancy. Longer than elephants. It was born out of an uncountable number of discussions (and even rare arguments) between the NVP-II staff of ISI, Lincoln Laboratory and SRI (in alphabetic order). Many proposals were made in several papers, in various presentations and in many discussions. We feel that all of these efforts contributed to the ideas and the shape of this protocol. All these participants deserve a share in any credit ever given to this protocol. All the blame should be directed to me for not listening, not understanding or not recognizing better ideas when they were presented. I hope the pregnancy is over, and that the newborn is not a dinosaur. The intent of this document is to provide a complete specification of some self-contained and extensible protocol. Therefore an effort was made to provide a set of primitives which allow the beginning of implementations which would have the capability to be expanded later to support future requirements. We expect this specification to be somewhere above the minimum set which is required for a reasonable operation under the expected conditions. If this is not so every effort must be made as soon as possible, to mend this situation. On the other hand, we are sure that this specification is well below the maximum set which may be required for ALL the problems and ALL the conditions which we are capable of imagining. NVP-II does not intend to solve all the problems associated with packet voice communication, point-topoint (PTP) or conferencing. It is designed to supply tools which may be used for solving a large class of problems in this area, with the hope that most of the interesting problems in this area are in this class. NVP-II intends to provide a quick and efficient method for establishing the routine transactions with an escape mechanism for performing more complicated and less frequent transactions.

3 i Table of Contents (A) GENERAL 2 (B) THE MODEL 3 (C) THE CONFERENCE MODEL 5 (D) CONTROL MESSAGES 7 (E) THE CONTROL TOKENS 8 (F) DEFINITION OF THE CONTROL TOKENS 9 (G) DEFINITION OF THE CONTROL TOKENS, FOR CONFERENCING 16 (H) THE NVP-II DATA PROTOCOL 21 (I) APPENDIX 23 I.1. CHARACTER PARITY 23 I.2. CHARACTER ORDER IN STRINGS 23 (A) AN ANNOTATED EXAMPLE FOR PTP COMMUNICATION 27 (B) AN ANNOTATED EXAMPLE FOR CONFERENCE COMMUNICATION 43 (C) SAMPLE SCENARIOS 63 (D) MORE NVP-II/ST SCENARIOS 66 D.1. A PTP call 69 D.2. Another PTP call 70

4 ii List of Figures Figure A-1: NVP-A=>NVP-B (IP.ST/NVP): An initial call. 31 Figure A-2: NVP-B=>NVP-A (IP.ST/NVP): Accepting the call. 33 Figure A-3: ST-A=>ST-B (ST.DG): a CONNECT message. 34 Figure A-4: ST-X=>ST-A (ST.DG): An ACK message to ST-A. 35 Figure A-5: ST-B=>ST-A (ST.DG): An ACCEPT message. 36 Figure A-6: NVP-A=>NVP-B (IP.ST/NVP): Please keep ringing. 37 Figure A-7: NVP-B=>NVP-A (IP.ST/NVP): We keep ringing. 38 Figure A-8: NVP-B=>NVP-A (IP.ST/NVP): Ready For data. 39 Figure A-9: ST-A=>ST-B (ST.ST): Data, (note the aggregation). 40 Figure A-10: NVP-B=>NVP-A (ST.DG): Normal call termination. 41 Figure A-11: ST-B=>ST-A (ST.DG): a REFUSE message. 41 Figure A-12: ST-A=>ST-B (ST.DG): a DISCONNECT message. 42 Figure B-1: NVP-A=>AC (IP.ST/NVP): I want to join a conference. 47 Figure B-2: AC=>NVP-A (IP.ST/NVP): You are accepted. 49 Figure B-3: ST-A=>AC (IP.ST/ST): Asking about #1+#2+#4. 50 Figure B-4: AC=>ST-A (IP.ST/ST): Info about #1+#2+#4. 53 Figure B-5: ST-A=>Ga (ST.DG): CONNECT to #1. 54 Figure B-6: ST-A=>Gb (ST.DG): CONNECT to #2. 55 Figure B-7: Ga=>ST-A (ST.DG): ACK of the CONNECT to #1. 56 Figure B-8: Gb=>ST-A (ST.DG): ACK of the CONNECT to #2. 56 Figure B-9: ST-1=>ST-A (ST.DG): ACCEPTing your CONNECT. 57 Figure B-10: ST-5=>Ga (ST.ST): Speech data for #1+#4. 58 Figure B-11: ST-5=>Gb (ST.ST): Speech data for #2. 59 Figure B-12: NVP-A=>AC (IP.ST/NVP): OUT + BYE. 60 Figure B-13: ST-5=>Ga (ST.ST): OUT+BYE for #1+#4. 61 Figure B-14: ST-A=>Ga (ST.DG): CONNECT to #1. 62

5 1 N O T E This document is based on ST. It does not specify the NVP/ST interface. The interface between ST and NVP is considered to be a "local implementation issue" which may be implemented in various ways at different sites without affecting the total system inter operability. It is possible to have a relatively "smarter" ST with a simpler NVP on top of it, or a simpler ST and a smarter NVP. In order to understand the proposed NVP and ST it is recommended to read the following documents: The ST document by Jim Forgie (IEN 119 and subsequent revisions). The NVP document (this one). Sample ST/NVP scenarios (included in this document). The user interface is also considered a "local implementation issue". The user voice terminal may range from "dumb" as in a dial telephone to as "intelligent" as one might wish to design. For example NVP II can communicate that a terminal is ringing, but it is beyond the scope of the protocol as to how ringing is implemented or how ringing is indicated on the calling terminal. Throughout this document: WORD means a 16 bit word; BYTE means an 8 bit byte; FIRST means "in the most significant position"; Numbers are decimal.

6 2 (A) GENERAL NVP-II is designed to be an improved version of the first NVP which has been operational since Its main improvements over NVP-I are in the following areas: Operation in the ARPA internetwork environment. Improved conference facilities. Providing the "handles" which are necessary in order to achieve high efficiency of intermediate networks and utilization of special features like stream-setup, when necessary, and broadcasting. More flexible control to allow future extensions like the support of multi-media communication. NVP-II, like NVP-I, is divided into a Control Protocol (CP) and Voice Data Protocol (VP). The control protocol is the main topic of this document. The module which implements the control protocol is called the CM. Its main objectives are (i) establishing and monitoring the communication paths, and (ii) supporting a convenient user interface. The control functions are performed by exchanging "control- instructions" between the participating CMs. These instructions are referred to as control-tokens. The voice data protocol is basically as defined for NVP-I, and is not expected to be intrinsically changed. As a matter of fact, all the forthcoming acoustic improvements of any algorithm (e.g., LPC and CVSD) should apply equally to both protocols. However, NVP-II packages the voice-data in a different way than NVP-I does. NVP-II, unlike NVP-I, is symmetric in the sense that in a two-party call, the distinction between the CALLER and the CALLEE does not exist, and in conference there is no information regarding whether a participant called the conference or vice versa. On the other hand, the supporting communication protocol, ST, is based on asymmetric full-duplex connections with the notion of "direction" (i.e., CALLER and CALLEE) which is maintained throughout the entire life of the connection. NVP-II supports two main communication modes: (i) Point-to-Point (PTP) full-duplex, two-party communication, and (ii) Multi-Destination "Half-Duplex" (MDHD) communication (conference).

7 3 (B) THE MODEL NVP-II supports communication between users, where each user is a process with some capabilities somewhere in the internetwork environment, capable of using both IP datagrams and the internet stream protocol (ST) [FORGIE]. A user is defined by a 32-bit internetwork address and an extension designator. In addition, a user may also have a "NICKNAME" represented by a string of ASCII characters, oriented for human consumption. The format of the IP-address is specified in the IP-4 document [POSTEL], and the format of the extension designator and the NICKNAME are specified in this document. The user s address, which consists both of the IP-address and the extension designator (and sometimes also a dialing sequence) is expected to be associated with the particular voice-terminal ("telephone"), whereas the nickname is associated with the current user, which is typically a particular person, like "EARL CRAIGHILL", or a function like "BOOKKEEPING". Ideally all these nicknames are globally unique, hence they are names. It is expected that in some implementations there will be many IP-addresses with only a few extensions, whereas in other IP-addresses there will be many extensions. The communication tool used by NVP-II is ST, which is used in one of three main modes: IP.ST which is single-destination datagrams without (probably: before) establishing an ST-connection, ST.DG which is single- destination datagrams using an existing ST-connection and ST.ST which is multi-destination streams. Here "multi" means one or more. Being a user of ST, NVP-II has the responsibility to manage the proper use of the resources offered by ST. IP.ST is IP-datagrams in the ST protocol format. ST messages are designated by an IP version number of five. ST.DG and ST.ST messages are distinguished by a Datagram/Stream bit. Before establishing an ST-connection, only control information may be communicated. This is done by the IP.ST mechanism. After establishing the ST-connection, data (with or without control) is communicated by the ST.ST mechanism, but control with no data may also be communicated by the ST.DG mechanism. For more details please refer to the example in the "Sample NVP/ST Scenarios" documents and to the ST document [FORGIE]. In case of any difference of parameter preferences between participants NVP-I had the notion that the negotiation master (which is the CALLEE by default unless otherwise was negotiated) has always the last word and is therefore responsible to terminate the negotiation phase. NVP-II with its symmetric approach does not have this notion. Negotiation (shall we call them "arguments"?) may be trivially short and terminate when either of the parties offers an acceptable solution, or loop for ever if both implementations are equally stubborn (and dumb). As a matter of fact not only dumb-stubbornness may cause infinite loops so may dumb-politeness. Suppose that both A and B may use either options V1 and V2, and that each has a different preference. Suppose further that at the same time (up to communication propagation delays) A suggests V1 and B suggests V2. A while later A would politely accept B s proposal and offer V2, just when B offers V1, a while later A offers V1 and B offers V2... NVP-II does not specify how this possible loop terminates. In any case it is recommended that implementations limit the length of this negotiation phase. It is encouraged that NVP-II implementations allow a cut-off user to reconnect without necessarily advising the other parties to this incident if it was trivially short.

8 NVP (IP.IP) ST / (IP.ST) / <- IP Version = 5 = ST IP (ST.DG) If Datagram/Stream Bit = 1 IP Version = 4 -> (ST.ST) If Datagram/Stream Bit = 0 (IP Datagrams) Local Net Protocol If when A believes he is in communication with B, a message arrives from B requesting to establish a connection, A would reconnect to this new communication. The new B is recognized to be the same as the old one by having the same address (IP-address plus extension) and the same nickname or having only the same non-null nickname (but different IP-address and extension) provided that the old address is not "alive" any longer. If A calls B when B calls A simultaneously then "by definition" both parties seem to be BUSY, just like in the telephone systems. It is hoped the randomness which is part of human behavior would help in keeping this situation from looping forever.

9 5 (C) THE CONFERENCE MODEL Following are some of the many issues which have to be addressed in the discussion of conferencing. * What is the model of a conference? Which roles are played in it? How tight/loose is its control? What is its access scheme? Etc. * Is a conference always chaired? If so - how? By whom? * What is the extent of the parameters negotiation? When is it performed? By whom? * What is the status of a conference? Who knows it? How can one inquire about it? In our module a conference has the following kinds of players: Initiator Access Controller (AC) Floor Controller (FC) and Scheduler Participants Each conference has a unique ID. It is the Access Controller s role to control the participants set, the Floor Controller s role is to sequence the speakers properly. The Initiator is the process who informs the AC about the conference, its starting time, its ID, its access scheme and the like. The access scheme may be a restricted participants list, anyone who knows the password, anyone who is approved online by some process (probably with a person in the loop), anyone who wants to, etc. The Access Controller (AC) is the process responsible for controlling the participation in the conference by approving or disapproving requests from participants to join a conference. The AC also assign globally unique CIDs (Connection-ID numbers) which are very important for efficient operation in networks with broadcasting capabilities. The Floor Controller (FC) arbitrates (schedules) the "use of the floor", i.e., who talks when. This function is defined here communication-wise only. It is quite conceivable that the FC and the person who "chairs" the conference are different. Conceivable, but not necessarily recommended.

10 6 Conferences may be performed in many styles (regimes) which vary from free-style (free-floor) to a tightly controlled conference. The algorithm to determine who speaks when is the SCHEDULER of the conference, and the mechanism to enforce it is the FC of the conference. Note that both the scheduler and the FC may involve people in the loop or may be fully automated, they may be centralized, distributed or duplicated. For all practical purposes the scheduler may be considered as an integral part of the FC. NVP-I and NVCP supported only a tightly controlled conferencing regime with a centralized scheduler and chairman (FC) which were usually implemented as automatic programs with a manual override. NVP-II does not restrict the style of conferences. It treats the style as one of the configuration parameters of a conference. The first style which is supported by NVP-II is the free-style one. The control tokens needed for supporting it are defined in this document. It is expected that additional styles will be added to NVP-II in the near future. By design a 2-party conversation (PTP) is a full duplex communication which cannot be expanded to include additional participants. Also, a conference with 2 participants only is not equivalent to the PTP conversation. PTP communication requires a simpler mechanism than conferences do. Since most PTP calls do not evolve to conferences we argue that it is better to take advantage of the simplicity which exists in the PTP case for efficiency reasons. It is assumed that conferences are arranged prior to their beginning. These arrangements include the notification of some people that they are expected to participate in a certain conference, at a certain time, using a certain language and a certain vocoder, to discuss a certain subject, under a certain conferencing style, etc. It is not expected that these arrangements are made within the conference. We believe once the conference starts it is too late to make these pre-arrangements. Therefore, no provisions are made within the conference framework to made such pre-arrangements.

11 7 (D) CONTROL MESSAGES Control tokens are preceded by a 16 bit checksum. The checksum value is computed according to the scheme of computing the checksum for ST, as defined in the ST-document [FORGIE]. Each of the NVP-II control tokens (instructions) consists of (up to) 3 fields, the first is an "op-code" byte, followed by a Data.Length (N) byte followed by N data words. N obviously may vary between 0 and 255. The op-code and the Data.Length are packed in a single word, with the op-code in the first (most significant) byte. Hence, a single zero word is a token complying with this format specification, having zero op-code and no data. Several control tokens may be packed (aggregated) together. It is possible to communicate these control tokens in several ways (e.g., by IP.ST, by ST-datagrams or with ST-data-streams). Once these control tokens arrive the destination is required to treat them in the same way, regardless of the scheme used for communicating them. In particular, when acting upon a control token which requests a response it is not expected that the same transport mechanism which was used by the sender of the request is necessarily used by the answerer. The receiving Control Module (CM) is expected to process these tokens in the same order in which they are communicated, i.e., first token first. It is always expected that control tokens which are not understood are discarded by the receiver. The meaning of the data fields in these tokens depends on the "op-code", obviously. Some op-code may have alphanumeric character strings as their data. Each character is represented by 7-bit ASCII code, right justified in an 8-bit byte, the high-order bit of the byte is zero. A null character (ASCII 0) is always appended at the end of a string. If then the number of these characters is odd, another null character is appended at the end of the string, as a filler. Note that the number of characters is 2N, including the filler(s). Hence, the null string is represented by a single zero word. In each word used for sending strings the character which is in the most significant byte precedes the one which is in the least significant byte. Hence, "ABC" is sent as "AB", "C-null", and "ABCD" as "AB", "CD", "null-null" (where "null-null" is a zero word). Please note the discussions on characters-parity and on the order of characters in string, which are in the Appendix. Using the terminology of "On Holy Wars" Big-Endians style is used. The exact format of the control messages, their headers, checksums and the like is specified later in this document. Please note again that the value of Data.Length in NVP is defined not to include the Data.Length field, unlike the notion of LENGTH in ST and IP, which includes itself.

12 8 (E) THE CONTROL TOKENS [ 0] UNUSED AT THIS TIME [ 1] [I-AM-READY] [ 2] [BYE] <REASON> [ 3] [I-AM-RINGING] [ 4] [VOCODING] <VOCODER-CODE> [ 5] [PRECEDENCE] <VALUE> [ 6] [PLEASE-ECHO] <REFERENCE> [ 7] [ECHO-REPLY] <REFERENCE> [ 8] [CONNECTION-NAME] <NAME> [16] [TELL-ABOUT-USER] <USER-ID> <USER-ID>...<USER-ID> [17] [USER-ADDRESS] <USER-ID> <IP-ADDRESS> <EXTENSION> [18] [ALTERNATIVE-ADDRESS] <USER-ID> <IP-ADDRESS> <EXTENSION> [19] [NICKNAME] <USER-ID> <NICKNAME> [20] [ARBITRARY-TEXT] <STRING> [21] [ARBITRARY-CODE] <VALUE> <VALUE>... <VALUE> [22] [WHAT-ARE-YOUR-CAPABILITIES?] [23] [PLEASE-SEND-YOUR-COMMUNICATION-STATISTICS] [24] [HERE-IS-MY-STATISTICS] <DATA> [25] [PLEASE-DIAL] <DIALING SEQUENCE> [32] [PLEASE-JOIN-A-CONFERENCE] [33] [I-WANT-TO-JOIN-THE-CONFERENCE] [34] [CONFERENCE-ID] <CONF-ID> [35] [CONFERENCE-CONNECTION-NAME] <CID> [36] [CONFERENCE-PASSWORD] <PW> [37] [CONFERENCE-ACCESS] <INFO-FOR-AC> [38] [CONFERENCE-STYLE] <STYLE> [39] [CONFERENCE-BIT-MAP] <USER-ID> <NP> <BM> [40] [PLEASE-GIVE-ME-THE-CONFERENCE-STATUS] [41] [USER-IS-OUT] <USER-ID> [48] [I-AM-TALKING-NOW] [49] [I-AM-DONE] [50] [NET-MEASUREMENT-TIMESTAMP] <VALUE> <HOST> <EXT>

13 9 (F) DEFINITION OF THE CONTROL TOKENS The control messages are composed of control tokens. The grouping of tokens into messages is not explicitly defined herein. Applications should group tokens into messages in such a way that the information which is required by receiver, at that state, is available. The exact format of many parameters is not defined yet. All the formats will be specified together with the format of message headers, checksums and the like. >>> [1] = [I-AM-READY] This token expresses that the CM is happy, believing that there are neither communication nor compatibility problems, and is ready to receive speech data. It implies that the handset (or equivalent) is online (aka "offhook"), and that some person is ready to hear the the speech data, or that a recording device is ready to accept the data to be recorded after going through all the file specification and access steps, as needed. For symmetry this token should also be sent by the call initiator. >>> [2] = [BYE] <REASON> This token expresses the inability to communicate. It may mean anything from a slight compatibility problem to a total rejection due to being engaged in another communication (aka BUSY) or lack of access rights. It is considered polite to (i) send this token rather than ignoring completely the calling party, and (ii) to provide a reason code. The following reason codes are defined herein: 0 = Other than the following. 1 = Normal call termination. We hang up. Have a nice day! 2 = I am engaged now, please try later (BUSY). 3 = The call is not authorized (access control problem). 4 = I give up, you are probably down. 5 = Parameters incompatibility. Let s work it out (off line). 6 = I have problems on my side. Sorry about that. 7 = We don t have such an extension 8 = Incorrect address (e.g., missing dialing sequence) 9 = We don t dial this sequence. 10 = Missing a necessary parameter.

14 10 >>> [3] = [I-AM-RINGING] This token means that the sender of this token would be READY (as defined above) as soon as it is switched to the online (offhook) state. The I-AM-RINGING may be terminated if the receiver does not get any message from the sender for a certain period (say 3 seconds). >>> [4] = [VOCODING] <VOCODER-CODE> The following vocoding codes are defined herein: 1 = LPC-I (fixed rate) 2 = LPC-II (variable rate) 3 = LPCM (multiple rate) 4 = CVSD (variable rate) 5 = CVSD (multiple rate) 6 = Belgard (fixed rate) more later... DEFINITION: a variable-rate vocoder is one with rate which may be deduced from the data. This is different than a multiple-rate vocoder which may use any one of several (few) rates (e.g., 8,12,16 Kbps) according to a selection which is external to the data stream. The rate data may follow the vocoder code, if needed. Hence, for a multiple rate it may be the list of all rates, for a variable rate the minimum and the maximum, and for fixed-rate the single rate value. Note that it is not really needed to specify rate(s) for either fixed or variable rates vocoders because these rates are known in advance for each type of these vocoders. Hence, the inclusion of the rate is optional only. >>> [5] = [PRECEDENCE] <VALUE> This token is used to announce the precedence level which the sender assigns to this communication. This is not the place to discuss who is authorize to announce which level of precedence, and the range of values which this precedence may assume.

15 11 >>> [6] = [PLEASE-ECHO] <REFERENCE> This token asks the receive to echo back a response with the reference number specified in this request. This exchange of request and echo may be used either for round trip time measurement, for verifying the operability of the receiver (e.g., when talking to a recording device), for the familiar acknowledgment, for keeping the receiver ringing, and more. The echo may be interpreted as an acknowledgment that ALL the control tokens which were sent together with the request actually arrived, and no retransmission is needed to insure their arrival. It does not mean by any way a functional approval or acceptance of any of the associated requests. The <REFERENCE> is a single arbitrary word. >>> [7] = [ECHO-REPLY] <REFERENCE> This token is the response to the PLEASE-ECHO token. The <REFERENCE> here is copied from the one specified there. >>> [8] = [CONNECTION-NAME] <NAME> The purpose of this token is to provide a cross-reference identification of a PTP-connection, between ST and NVP. This token should be used whenever any ambiguity may occur, regarding the identification of the connection. The NAME is defined as the IP-address of the initiator of the call, followed by his extension, followed by the connection number. The call initiator assigns the connection number which is an arbitrary 16-bit word. Since both the IP-address and the extension fields consists of 2 words each, a NAME is a 5 words sequence. NOTE: ONLY THE ABOVE TOKENS ARE COMPULSORY FOR ANY PTP COMMUNICATION. However, for a smooth operation it is recommended that the following control tokens be implemented too.

16 12 >>> [16] = [TELL-ABOUT-USER] <USER-ID> <USER-ID>...<USER-ID> This token is used by a participant who wants to get information about some other participants in a conference. The USER-ID is typically, in a conference, the position of that user in the conference BIT-MAP (See the CONFERENCE-BIT-MAP token). However, a zero ID may be used to indicate the sender or the receiver of the token (depending on the token type). In a PTP communication the USER-ID should always be set to zero. In particular, a zero USER-ID with [TELL-ABOUT-USER], means that the receiver is asked to tell about itself. In return to this token it is expected to receive the USER-ADDRESS all the ALTERNATIVE-ADDRESS,if any, and the NICKNAME tokens which are known for this user.

17 13 >>> [17] = [USER-ADDRESS] <USER-ID> <IP-ADDRESS> <EXTENSION> This token is used for sending information about participants, either in a PTP or in a conference communication. Typically this token is sent in response to the [TELL-ABOUT-USER] token. The first word, the USER-ID, identifies the user whose address is defined in this token. When a user identifies himself, a zero USER-ID may be used, especially in a PTP communication. In conferences users are identified by their serial number in the conference bit-map, as discussed above. The <IP-address> is the 32-bit internet address. The <extension> is the 32-bit local extension. The IP-address and the extension together form the address of this user. This address is associated with the hardware station, whereas the NICKNAME is associated with a certain person. It is expected that people are more mobile than the hardware, and that the nickname of the same station may change between calls, as people move around. If this user has several addresses they are communicated by the ALTERNATIVE-ADDRESS tokens, which are repeated in a decreasing order of preference. In conference, this token may be used for communicating information about several participants, by repeating the body of the token as many times as needed. This body consists of 5 words (per user): 1 for USER-ID, 2 for IP-address and 2 for the extension. If there is no information regarding a user about which information was requested, or if that user is not active any more, this is signaled by setting the first word after the USER-ID to zero. That word is usually the first word of the IP-address which contains the NET-ID, and therefore cannot assume the zero value. Hence, a zero in that word may be used as an "escape-code" without causing any ambiguity. If no information is known about that user, the next word is set to 1. If it is known that this user is no longer an active member of the conference, that word is set to 2. The value of the following two words is ignored. >>> [18] = [ALTERNATIVE-ADDRESS] <USER-ID> <IP-ADDRESS> <EXTENSION> The purpose of this token is to provide alternate addresses which may be used to reach the same user. This is done in anticipation of network problems. If no alternative address exists, this token is never sent. If more than one exists then such a token is repeated for each address in a decreasing order of preference. The format of this token is the same as of the USER-ADDRESS.

18 14 >>> [19] = [NICKNAME] <USER-ID> <NICKNAME> This token is used for communicating a text string which is associated with the identified user. It is expected that people are more mobile than the hardware units, hence, the same hardware unit (identified by IP-address and extension) may be used by different individuals. Systems with text display capabilities are expected to benefit from this token. The first arrangement of this token, the <USER-ID>, is as defined for the USER-ADDRESS token. This is followed by a text-string which is the nickname itself. >>> [20] = [ARBITRARY-TEXT] <STRING> This token is used to communicate a character string which is only for human consumption and carries no information which the CM has to understand, hence it is called "arbitrary". CMs may display this string to the user in any of many ways. >>> [21] = [ARBITRARY-CODE] <VALUE> <VALUE>... <VALUE> This token is an escape mechanism to support either a runtime assigned values of codes which may be used for certain interrupts, voting and the like, or as a simple way to implement a "private protocol" within this framework. Each value is a single word. >>> [22] = [WHAT-ARE-YOUR-CAPABILITIES?] This is a solicitation of information about the parameters (as defined above) of another user. It is expected that in response to this token the receiver will send VOCODER, PRECEDENCE, USER- ADDRESS, NICKNAME, and maybe more parameters if they are of any consequence. This token may be answered even when the CM is BUSY. >>> [23] = [PLEASE-SEND-YOUR-COMMUNICATION-STATISTICS] This is a solicitation of communication statistics which may be useful for some flow control scheme. The format of the data will be specified later.

19 15 >>> [24] = [HERE-IS-MY-STATISTICS] <data> This is the exposition of the communication statistics. This token may be sent whenever the CM "thinks" that someone is interested to get it. It may be in response to the request for it, or not. The format of the data will be specified later. >>> [25] = [PLEASE-DIAL] <dialing sequence> This is a specification of a dialing sequence for an auto-dialer, if such a device is installed on this extension. A dialing sequence is specified to be a character string, with the digits (1 through 9 and 0) and the symbols "A", "B", "C", "D", "*" and "#" used for the DTMF (Dual Tone Multi Frequency) signals. Any other character is ignored, except "+" which means a waiting period of a few seconds, usually for the dial-tone of the next level. An example string is "LL= " which may cause an ISI phone to get first an "outside-line", wait for a dial-tone, and then call Lincoln via Ma Bell. Note that since the above string has an odd number of characters a single null character has to be appended to it.

20 16 (G) DEFINITION OF THE CONTROL TOKENS, FOR CONFERENCING All the tokens which are defined for PTP connections are valid also for conferencing. However, more control token are needed for handling the additional issues which are required for conferencing. As mentioned before it is assumed that the pre-arrangements which are necessary for a proper performance of the conference have already been made, and that the anticipated participants know when they are expected to join the conference and which vocoder to use. The process of joining a conference involves also a control communication (i.e., tokens exchange) between CMs and ACs. Some of the tokens may be transmitted only from CMs to ACs and some only from ACs to CMs. This is unlike the PTP communication where any token may be transmitted in any direction. This document does NOT specify how the AC is told by the Conference Initiator about the conference parameters, its name, style, vocoder, access, time, and the like. The conferencing tokens are defined herein: >>> [32] = [PLEASE-JOIN-A-CONFERENCE] This token is used to invite a user to join a conference. It is expected that it is followed by other tokens specifying parameters like the conference-id and other access control information. In addition it may include an arbitrary text. The fact that a certain user was invited to join the conference is not a part of any status, and bears no additional privileges to this user.

Computer Networks. Chapter 5 Transport Protocols

Computer Networks. Chapter 5 Transport Protocols Computer Networks Chapter 5 Transport Protocols Transport Protocol Provides end-to-end transport Hides the network details Transport protocol or service (TS) offers: Different types of services QoS Data

More information

Lecture 15. IP address space managed by Internet Assigned Numbers Authority (IANA)

Lecture 15. IP address space managed by Internet Assigned Numbers Authority (IANA) Lecture 15 IP Address Each host and router on the Internet has an IP address, which consist of a combination of network number and host number. The combination is unique; no two machines have the same

More information

Module 7 Internet And Internet Protocol Suite

Module 7 Internet And Internet Protocol Suite Module 7 Internet And Internet Protocol Suite Lesson 21 Internet and IPv4 LESSON OBJECTIVE General The lesson will discuss a popular network layer protocol, i.e. the Internet Protocol Specific The focus

More information

Appendix B RCS11 Remote Communications

Appendix B RCS11 Remote Communications Appendix B RCS11 Remote Communications B.1 Host Computer Remote Communications Control and status messages are conveyed between the RCS11 and the host computer using packetized message blocks in accordance

More information

Transport Layer Protocols

Transport Layer Protocols Transport Layer Protocols Version. Transport layer performs two main tasks for the application layer by using the network layer. It provides end to end communication between two applications, and implements

More information

PRODUCT MANUAL SKX OPEN SKX ADVANCE ZN1RX-SKXOPEN. Edition 2 Version 1.1

PRODUCT MANUAL SKX OPEN SKX ADVANCE ZN1RX-SKXOPEN. Edition 2 Version 1.1 PRODUCT MANUAL SKX OPEN SKX ADVANCE ZN1RX-SKXOPEN Edition 2 Version 1.1 INDEX 1. Introduction... 3 1.1. SKX Interface... 3 1.2. SKX Installation... 5 1.3. SKX Advance: Application Program... 5 1.3.1. SKX

More information

(Refer Slide Time: 02:17)

(Refer Slide Time: 02:17) Internet Technology Prof. Indranil Sengupta Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture No #06 IP Subnetting and Addressing (Not audible: (00:46)) Now,

More information

(Refer Slide Time: 6:17)

(Refer Slide Time: 6:17) Digital Video and Picture Communication Prof. S. Sengupta Department of Electronics and Communication Engineering Indian Institute of Technology, Kharagpur Lecture - 39 Video Conferencing: SIP Protocol

More information

IP - The Internet Protocol

IP - The Internet Protocol Orientation IP - The Internet Protocol IP (Internet Protocol) is a Network Layer Protocol. IP s current version is Version 4 (IPv4). It is specified in RFC 891. TCP UDP Transport Layer ICMP IP IGMP Network

More information

NETWORK LAYER/INTERNET PROTOCOLS

NETWORK LAYER/INTERNET PROTOCOLS CHAPTER 3 NETWORK LAYER/INTERNET PROTOCOLS You will learn about the following in this chapter: IP operation, fields and functions ICMP messages and meanings Fragmentation and reassembly of datagrams IP

More information

Module 6. Internetworking. Version 2 CSE IIT, Kharagpur

Module 6. Internetworking. Version 2 CSE IIT, Kharagpur Module 6 Internetworking Lesson 2 Internet Protocol (IP) Specific Instructional Objectives At the end of this lesson, the students will be able to: Explain the relationship between TCP/IP and OSI model

More information

1. The subnet must prevent additional packets from entering the congested region until those already present can be processed.

1. The subnet must prevent additional packets from entering the congested region until those already present can be processed. Congestion Control When one part of the subnet (e.g. one or more routers in an area) becomes overloaded, congestion results. Because routers are receiving packets faster than they can forward them, one

More information

Communications and Computer Networks

Communications and Computer Networks SFWR 4C03: Computer Networks and Computer Security January 5-8 2004 Lecturer: Kartik Krishnan Lectures 1-3 Communications and Computer Networks The fundamental purpose of a communication system is the

More information

Internet Architecture and Philosophy

Internet Architecture and Philosophy Internet Architecture and Philosophy Conceptually, TCP/IP provides three sets of services to the user: Application Services Reliable Transport Service Connectionless Packet Delivery Service The underlying

More information

Network Working Group Request for Comments: 840 April 1983. Official Protocols

Network Working Group Request for Comments: 840 April 1983. Official Protocols Network Working Group Request for Comments: 840 J. Postel ISI April 1983 This RFC identifies the documents specifying the official protocols used in the Internet. Annotations identify any revisions or

More information

TCP. Raj Jain. Professor of CIS The Ohio State University Columbus, OH 43210 Raj Jain 20-1

TCP. Raj Jain. Professor of CIS The Ohio State University Columbus, OH 43210  Raj Jain 20-1 TCP Professor of CIS Columbus, OH 43210 Jain@ACM.Org http://www.cis.ohio-state.edu/~jain/ 20-1 Overview Key features, Header format Mechanisms, Implementation choices Slow start congestion avoidance, Fast

More information

Broadband Networks. Prof. Dr. Abhay Karandikar. Electrical Engineering Department. Indian Institute of Technology, Bombay. Lecture - 29.

Broadband Networks. Prof. Dr. Abhay Karandikar. Electrical Engineering Department. Indian Institute of Technology, Bombay. Lecture - 29. Broadband Networks Prof. Dr. Abhay Karandikar Electrical Engineering Department Indian Institute of Technology, Bombay Lecture - 29 Voice over IP So, today we will discuss about voice over IP and internet

More information

Applied Data Communication Lecture 14

Applied Data Communication Lecture 14 Applied Data Communication Lecture 14 Character oriented Data Link Character-oriented data link control Asynchronous Synchronous Kristjan Sillmann reaalajasüsteemide õppetool TTÜ automaatikainstituut character-oriented

More information

SVMi-4 & SVM-400. Voice Mail System. System Administration Manual

SVMi-4 & SVM-400. Voice Mail System. System Administration Manual SVMi-4 & SVM-400 Voice Mail System System Administration Manual Contents About this Book 3 How to use this online manual 4 How to print this online manual 5 Feature Descriptions 6 SYSTEM FEATURES 6 AUTO

More information

ACHILLES CERTIFICATION. SIS Module SLS 1508

ACHILLES CERTIFICATION. SIS Module SLS 1508 ACHILLES CERTIFICATION PUBLIC REPORT Final DeltaV Report SIS Module SLS 1508 Disclaimer Wurldtech Security Inc. retains the right to change information in this report without notice. Wurldtech Security

More information

Computer Network. Interconnected collection of autonomous computers that are able to exchange information

Computer Network. Interconnected collection of autonomous computers that are able to exchange information Introduction Computer Network. Interconnected collection of autonomous computers that are able to exchange information No master/slave relationship between the computers in the network Data Communications.

More information

4. H.323 Components. VOIP, Version 1.6e T.O.P. BusinessInteractive GmbH Page 1 of 19

4. H.323 Components. VOIP, Version 1.6e T.O.P. BusinessInteractive GmbH Page 1 of 19 4. H.323 Components VOIP, Version 1.6e T.O.P. BusinessInteractive GmbH Page 1 of 19 4.1 H.323 Terminals (1/2)...3 4.1 H.323 Terminals (2/2)...4 4.1.1 The software IP phone (1/2)...5 4.1.1 The software

More information

Protocols and Architecture. Protocol Architecture.

Protocols and Architecture. Protocol Architecture. Protocols and Architecture Protocol Architecture. Layered structure of hardware and software to support exchange of data between systems/distributed applications Set of rules for transmission of data between

More information

RARP: Reverse Address Resolution Protocol

RARP: Reverse Address Resolution Protocol SFWR 4C03: Computer Networks and Computer Security January 19-22 2004 Lecturer: Kartik Krishnan Lectures 7-9 RARP: Reverse Address Resolution Protocol When a system with a local disk is bootstrapped it

More information

Single channel data transceiver module WIZ2-434

Single channel data transceiver module WIZ2-434 Single channel data transceiver module WIZ2-434 Available models: WIZ2-434-RS: data input by RS232 (±12V) logic, 9-15V supply WIZ2-434-RSB: same as above, but in a plastic shell. The WIZ2-434-x modules

More information

Ethernet. Ethernet. Network Devices

Ethernet. Ethernet. Network Devices Ethernet Babak Kia Adjunct Professor Boston University College of Engineering ENG SC757 - Advanced Microprocessor Design Ethernet Ethernet is a term used to refer to a diverse set of frame based networking

More information

Indian Institute of Technology Kharagpur. TCP/IP Part I. Prof Indranil Sengupta Computer Science and Engineering Indian Institute of Technology

Indian Institute of Technology Kharagpur. TCP/IP Part I. Prof Indranil Sengupta Computer Science and Engineering Indian Institute of Technology Indian Institute of Technology Kharagpur TCP/IP Part I Prof Indranil Sengupta Computer Science and Engineering Indian Institute of Technology Kharagpur Lecture 3: TCP/IP Part I On completion, the student

More information

Allworx User s Guide (Release 7.2.3.x)

Allworx User s Guide (Release 7.2.3.x) Allworx User s Guide (Release 7.2.3.x) No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopy, recording,

More information

Understanding TCP/IP. Introduction. What is an Architectural Model? APPENDIX

Understanding TCP/IP. Introduction. What is an Architectural Model? APPENDIX APPENDIX A Introduction Understanding TCP/IP To fully understand the architecture of Cisco Centri Firewall, you need to understand the TCP/IP architecture on which the Internet is based. This appendix

More information

Best Practices for Role Based Video Streams (RBVS) in SIP. IMTC SIP Parity Group. Version 33. July 13, 2011

Best Practices for Role Based Video Streams (RBVS) in SIP. IMTC SIP Parity Group. Version 33. July 13, 2011 Best Practices for Role Based Video Streams (RBVS) in SIP IMTC SIP Parity Group Version 33 July 13, 2011 Table of Contents 1. Overview... 3 2. Role Based Video Stream (RBVS) Best Practices Profile... 4

More information

Networking Overview. (as usual, thanks to Dave Wagner and Vern Paxson)

Networking Overview. (as usual, thanks to Dave Wagner and Vern Paxson) Networking Overview (as usual, thanks to Dave Wagner and Vern Paxson) Focus For This Lecture Sufficient background in networking to then explore security issues in next few lectures Networking = the Internet

More information

PART OF THE PICTURE: The TCP/IP Communications Architecture

PART OF THE PICTURE: The TCP/IP Communications Architecture PART OF THE PICTURE: The / Communications Architecture 1 PART OF THE PICTURE: The / Communications Architecture BY WILLIAM STALLINGS The key to the success of distributed applications is that all the terminals

More information

Voice over IP. Demonstration 1: VoIP Protocols. Network Environment

Voice over IP. Demonstration 1: VoIP Protocols. Network Environment Voice over IP Demonstration 1: VoIP Protocols Network Environment We use two Windows workstations from the production network, both with OpenPhone application (figure 1). The OpenH.323 project has developed

More information

Requirements of Voice in an IP Internetwork

Requirements of Voice in an IP Internetwork Requirements of Voice in an IP Internetwork Real-Time Voice in a Best-Effort IP Internetwork This topic lists problems associated with implementation of real-time voice traffic in a best-effort IP internetwork.

More information

)454 6. SERIES V: DATA COMMUNICATION OVER THE TELEPHONE NETWORK Interfaces and voiceband modems. ITU-T Recommendation V.25

)454 6. SERIES V: DATA COMMUNICATION OVER THE TELEPHONE NETWORK Interfaces and voiceband modems. ITU-T Recommendation V.25 INTERNATIONAL TELECOMMUNICATION UNION )454 6 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (10/96) SERIES V: DATA COMMUNICATION OVER THE TELEPHONE NETWORK Interfaces and voiceband modems!utomatic ANSWERING

More information

TCP/IP: An overview. Syed A. Rizvi

TCP/IP: An overview. Syed A. Rizvi TCP/IP: An overview Syed A. Rizvi TCP/IP The Internet uses TCP/IP protocol suite to establish a connection between two computers. TCP/IP suite includes two protocols (1) Transmission Control Protocol or

More information

An Introduction to VoIP Protocols

An Introduction to VoIP Protocols An Introduction to VoIP Protocols www.netqos.com Voice over IP (VoIP) offers the vision of a converged network carrying multiple types of traffic (voice, video, and data, to name a few). To carry out this

More information

Voice Over IP Per Call Bandwidth Consumption

Voice Over IP Per Call Bandwidth Consumption Over IP Per Call Bandwidth Consumption Interactive: This document offers customized voice bandwidth calculations with the TAC Bandwidth Calculator ( registered customers only) tool. Introduction Before

More information

Session Initiation Protocol (SIP) The Emerging System in IP Telephony

Session Initiation Protocol (SIP) The Emerging System in IP Telephony Session Initiation Protocol (SIP) The Emerging System in IP Telephony Introduction Session Initiation Protocol (SIP) is an application layer control protocol that can establish, modify and terminate multimedia

More information

Chapter 3. TCP/IP Networks. 3.1 Internet Protocol version 4 (IPv4)

Chapter 3. TCP/IP Networks. 3.1 Internet Protocol version 4 (IPv4) Chapter 3 TCP/IP Networks 3.1 Internet Protocol version 4 (IPv4) Internet Protocol version 4 is the fourth iteration of the Internet Protocol (IP) and it is the first version of the protocol to be widely

More information

ICOM 5026-090: Computer Networks Chapter 6: The Transport Layer. By Dr Yi Qian Department of Electronic and Computer Engineering Fall 2006 UPRM

ICOM 5026-090: Computer Networks Chapter 6: The Transport Layer. By Dr Yi Qian Department of Electronic and Computer Engineering Fall 2006 UPRM ICOM 5026-090: Computer Networks Chapter 6: The Transport Layer By Dr Yi Qian Department of Electronic and Computer Engineering Fall 2006 Outline The transport service Elements of transport protocols A

More information

Bluetooth voice and data performance in 802.11 DS WLAN environment

Bluetooth voice and data performance in 802.11 DS WLAN environment 1 (1) Bluetooth voice and data performance in 802.11 DS WLAN environment Abstract In this document, the impact of a 20dBm 802.11 Direct-Sequence WLAN system on a 0dBm Bluetooth link is studied. A typical

More information

Internet Control Message Protocol (ICMP)

Internet Control Message Protocol (ICMP) Internet Control Message Protocol (ICMP) Relates to Lab 2: A short module on the Internet Control Message Protocol (ICMP). 1 Overview The IP (Internet Protocol) relies on several other protocols to perform

More information

Lab Exercise 802.11. Objective. Requirements. Step 1: Fetch a Trace

Lab Exercise 802.11. Objective. Requirements. Step 1: Fetch a Trace Lab Exercise 802.11 Objective To explore the physical layer, link layer, and management functions of 802.11. It is widely used to wireless connect mobile devices to the Internet, and covered in 4.4 of

More information

Table of Contents: Protocol Overview. Components H.225 Q.931 H.245. H.235v2 (Security) H.323 & FireWalls. Sample SIP Session.

Table of Contents: Protocol Overview. Components H.225 Q.931 H.245. H.235v2 (Security) H.323 & FireWalls. Sample SIP Session. Table of Contents: I. H.323 Protocol Overview Components H.225 RAS Q.931 H.245 H.235v2 (Security) H.323 & FireWalls II. /Skinny III. RTP and RTCP IV. SIP Sample SIP Session Request Methods Request Headers

More information

IP Network Layer. Datagram ID FLAG Fragment Offset. IP Datagrams. IP Addresses. IP Addresses. CSCE 515: Computer Network Programming TCP/IP

IP Network Layer. Datagram ID FLAG Fragment Offset. IP Datagrams. IP Addresses. IP Addresses. CSCE 515: Computer Network Programming TCP/IP CSCE 515: Computer Network Programming TCP/IP IP Network Layer Wenyuan Xu Department of Computer Science and Engineering University of South Carolina IP Datagrams IP is the network layer packet delivery

More information

Subnetting,Supernetting, VLSM & CIDR

Subnetting,Supernetting, VLSM & CIDR Subnetting,Supernetting, VLSM & CIDR WHAT - IP Address Unique 32 or 128 bit Binary, used to identify a system on a Network or Internet. Network Portion Host Portion CLASSFULL ADDRESSING IP address space

More information

Data Link Layer(1) Principal service: Transferring data from the network layer of the source machine to the one of the destination machine

Data Link Layer(1) Principal service: Transferring data from the network layer of the source machine to the one of the destination machine Data Link Layer(1) Principal service: Transferring data from the network layer of the source machine to the one of the destination machine Virtual communication versus actual communication: Specific functions

More information

EKSAMEN / EXAM TTM4100 18 05 2007

EKSAMEN / EXAM TTM4100 18 05 2007 1.1 1.1.1...... 1.1.2...... 1.1.3...... 1.1.4...... 1.1.5...... 1.1.6...... 1.1.7...... 1.1.8...... 1.1.9...... 1.1.10.... 1.1.11... 1.1.16.... 1.1.12... 1.1.17.... 1.1.13... 1.1.18.... 1.1.14... 1.1.19....

More information

Computer Networks. Data Link Layer

Computer Networks. Data Link Layer Computer Networks The Data Link Layer 1 Data Link Layer Application Transport Network DLL PHY 2 What does it do? What functions it performs? Typically: Handling transmission errors, a.k.a., error control.

More information

Module 11: TCP/IP Transport and Application Layers

Module 11: TCP/IP Transport and Application Layers Module 11: TCP/IP Transport and Application Layers 11.1 TCP/IP Transport Layer 11.1.1 Introduction to the TCP/IP transport layer The primary duties of the transport layer are to transport and regulate

More information

Quality of Service (QoS) on Netgear switches

Quality of Service (QoS) on Netgear switches Quality of Service (QoS) on Netgear switches Section 1 Principles and Practice of QoS on IP networks Introduction to QoS Why? In a typical modern IT environment, a wide variety of devices are connected

More information

Chapter 1 Configuring Serial Tunneling in SDLC and HDLC Environments

Chapter 1 Configuring Serial Tunneling in SDLC and HDLC Environments Chapter 1 Configuring Serial Tunneling in SDLC and HDLC Environments 1 This chapter describes Cisco s Serial Tunneling (STUN) implementation. The following topics are included in this chapter: Description

More information

Module 2 Communication Switching. Version 1 ECE, IIT Kharagpur

Module 2 Communication Switching. Version 1 ECE, IIT Kharagpur Module 2 Communication Switching Lesson 2 Circuit Switching INSTRUCTIONAL OBJECTIVES GENERAL This lesson is aimed at developing the concept and application of circuit switching which is a very important

More information

Microsoft Office Communicator 2007 Getting Started Guide. Published: July 2007

Microsoft Office Communicator 2007 Getting Started Guide. Published: July 2007 Microsoft Office Communicator 2007 Getting Started Guide Published: July 2007 Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless

More information

User Guide. Version 3.0 April 2006

User Guide. Version 3.0 April 2006 User Guide Version 3.0 April 2006 2006 Obvious Solutions Inc. All rights reserved. Dabra and Dabra Network are trademarks of Obvious Solutions Inc. All other trademarks owned by their respective trademark

More information

(Refer Slide Time: 4:45)

(Refer Slide Time: 4:45) Digital Voice and Picture Communication Prof. S. Sengupta Department of Electronics and Communication Engineering Indian Institute of Technology, Kharagpur Lecture - 38 ISDN Video Conferencing Today we

More information

UM8000 MAIL USER GUIDE

UM8000 MAIL USER GUIDE UM8000 MAIL USER GUIDE INT-2076 (UNIV) Issue 1.0 INTRODUCTION Welcome to UM8000 Mail User Guide. The UM8000 Mail is a simple yet powerful voice messaging system that can greet your callers and record your

More information

2. Compressing data to reduce the amount of transmitted data (e.g., to save money).

2. Compressing data to reduce the amount of transmitted data (e.g., to save money). Presentation Layer The presentation layer is concerned with preserving the meaning of information sent across a network. The presentation layer may represent (encode) the data in various ways (e.g., data

More information

Process Control and Automation using Modbus Protocol

Process Control and Automation using Modbus Protocol Process Control and Automation using Modbus Protocol Modbus is the fundamental network protocol used in most industrial applications today. It is universal, open and an easy to use protocol. Modbus has

More information

Guide to TCP/IP, Third Edition. Chapter 3: Data Link and Network Layer TCP/IP Protocols

Guide to TCP/IP, Third Edition. Chapter 3: Data Link and Network Layer TCP/IP Protocols Guide to TCP/IP, Third Edition Chapter 3: Data Link and Network Layer TCP/IP Protocols Objectives Understand the role that data link protocols, such as SLIP and PPP, play for TCP/IP Distinguish among various

More information

This service allows you to talk to the 3rd party before transferring the original called party to them. To use Attended Call transfer:

This service allows you to talk to the 3rd party before transferring the original called party to them. To use Attended Call transfer: Calling Features Attend Call Transfer Auto Redial Anonymous Call Rejection Call Blocking Call Forward Busy Line Call Forward Don't Answer Call Forwarding Remote Access Call Forwarding Universal Call Holding

More information

All Rights Reserved. Copyright 2009

All Rights Reserved. Copyright 2009 IMPORTANT NOTICE CONCERNING EMERGENCY 911 SERVICES Your service provider, not the manufacturer of the equipment, is responsible for the provision of phone services through this equipment. Any services

More information

Guideline for setting up a functional VPN

Guideline for setting up a functional VPN Guideline for setting up a functional VPN Why do I want a VPN? VPN by definition creates a private, trusted network across an untrusted medium. It allows you to connect offices and people from around the

More information

Transport Layer. Chapter 3.4. Think about

Transport Layer. Chapter 3.4. Think about Chapter 3.4 La 4 Transport La 1 Think about 2 How do MAC addresses differ from that of the network la? What is flat and what is hierarchical addressing? Who defines the IP Address of a device? What is

More information

04 Internet Protocol (IP)

04 Internet Protocol (IP) SE 4C03 Winter 2007 04 Internet Protocol (IP) William M. Farmer Department of Computing and Software McMaster University 29 January 2007 Internet Protocol (IP) IP provides a connectionless packet delivery

More information

CALLING FEATURE USER GUIDE

CALLING FEATURE USER GUIDE Quick Start CALLING FEATURE USER GUIDE FEATURE ACTIVATE CANCEL Call Waiting hookswitch (or flash) 3- Way Calling hookswitch (or flash) *69 Call Return (Automatic Recall) *69 *89 Cancel Call Waiting *70

More information

2. IP Networks, IP Hosts and IP Ports

2. IP Networks, IP Hosts and IP Ports 1. Introduction to IP... 1 2. IP Networks, IP Hosts and IP Ports... 1 3. IP Packet Structure... 2 4. IP Address Structure... 2 Network Portion... 2 Host Portion... 3 Global vs. Private IP Addresses...3

More information

PHONE USER 1 GUIDE. Morristown (MUS) Local Customer Calling FROM: Morristown (Area Code 423): 307, 317, 318, 522, 581, 585, 586, 587

PHONE USER 1 GUIDE. Morristown (MUS) Local Customer Calling FROM: Morristown (Area Code 423): 307, 317, 318, 522, 581, 585, 586, 587 PHONE USER 1 GUIDE Local Calling Area Windstream has defined the following local calling area. All calls to these areas are included in your local monthly charge. Calls outside of this area will be billed

More information

To activate Anonymous Call Rejection: 1. Lift the receiver and listen for dial tone. 2. Dial *77. 3. Listen for confirmation tone, hang up.

To activate Anonymous Call Rejection: 1. Lift the receiver and listen for dial tone. 2. Dial *77. 3. Listen for confirmation tone, hang up. Anonymous Call Rejection Anonymous Call Rejection allows a customer to deny any calls from ringing the line if the calling party has blocked the identification number. The calling party receives a message

More information

www.metrocast.com/business

www.metrocast.com/business www.metrocast.com/business All Rights Reserved The use, disclosure, modification, transfer or transmittal of this work for any purpose, in any form, or by any means, without the written permission from

More information

Telecommunications Switching Systems (TC-485) PRACTICAL WORKBOOK FOR ACADEMIC SESSION 2011 TELECOMMUNICATIONS SWITCHING SYSTEMS (TC-485) FOR BE (TC)

Telecommunications Switching Systems (TC-485) PRACTICAL WORKBOOK FOR ACADEMIC SESSION 2011 TELECOMMUNICATIONS SWITCHING SYSTEMS (TC-485) FOR BE (TC) PRACTICAL WORKBOOK FOR ACADEMIC SESSION 2011 TELECOMMUNICATIONS SWITCHING SYSTEMS (TC-485) FOR BE (TC) Department of Electronic Engineering NED University of Engineering and Technology, Karachi LABORATORY

More information

Functional Specifications Document

Functional Specifications Document Functional Specifications Document VOIP SOFT PBX Project Code: SPBX Project Advisor : Aftab Alam Project Team: Umair Ashraf 03-1853 (Team Lead) Imran Bashir 02-1658 Khadija Akram 04-0080 Submission Date:19-10-2007

More information

Voice mail Play messages Activate Deactivate. Voice mail. Activate? Voice mail. Play messages Activate Deactivate. Set ring time.

Voice mail Play messages Activate Deactivate. Voice mail. Activate? Voice mail. Play messages Activate Deactivate. Set ring time. Regarding Use of This Guide This guide is intended for users of DOCOMO mobile phones with a DOCOMO UIM Card (or otherwise a FOMA Card or DOCOMO mini UIM Card. Hereinafter the same applies). If the SIM

More information

Local Area Networks transmission system private speedy and secure kilometres shared transmission medium hardware & software

Local Area Networks transmission system private speedy and secure kilometres shared transmission medium hardware & software Local Area What s a LAN? A transmission system, usually private owned, very speedy and secure, covering a geographical area in the range of kilometres, comprising a shared transmission medium and a set

More information

Allworx Queuing and Automated Call Distribution Guide (Release 7.1.0.x)

Allworx Queuing and Automated Call Distribution Guide (Release 7.1.0.x) Allworx Queuing and Automated Call Distribution Guide (Release 7.1.0.x) No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic,

More information

High-Level Data Link Control

High-Level Data Link Control High-Level Data Link Control This class of data link layer protocols includes High-level Data Link Control (HDLC), Link Access Procedure Balanced (LAPB) for X.25, Link Access Procedure for D-channel (LAPD)

More information

Overview of Voice Over Internet Protocol

Overview of Voice Over Internet Protocol Overview of Voice Over Internet Protocol Purva R. Rajkotia, Samsung Electronics November 4,2004 Overview of Voice Over Internet Protocol Presentation Outline History of VoIP What is VoIP? Components of

More information

Shaw Business Hosted PBX user guide

Shaw Business Hosted PBX user guide Shaw Business Hosted PBX user guide Contents 4 Welcome 5 AASTRA Hosted IP Phone 7 Handling Calls 9 Voicemail / Greetings 11 Voicemail / Playback Features 12 Additional Voicemail Features 13 Call Forward

More information

Request For Comments: 1350 STD: 33 July 1992 Obsoletes: RFC 783

Request For Comments: 1350 STD: 33 July 1992 Obsoletes: RFC 783 Network Working Group K. Sollins Request For Comments: 1350 MIT STD: 33 July 1992 Obsoletes: RFC 783 Status of this Memo THE TFTP PROTOCOL (REVISION 2) This RFC specifies an IAB standards track protocol

More information

Hosted PBX Calling Features and Voice Mail Guide

Hosted PBX Calling Features and Voice Mail Guide Definition FairPoint Communications Hosted PBX is easy to use and manage. Hosted PBX is packed with a wide variety of useful standard, advanced and business group calling features, including voicemail.

More information

Hosted PBX Calling Features and Voice Mail Guide

Hosted PBX Calling Features and Voice Mail Guide Definition FairPoint Communications Hosted PBX is easy to use and manage. Hosted PBX is packed with a wide variety of useful standard, advanced and business group calling features, including voicemail.

More information

1 Getting Started. Before you can connect to a network

1 Getting Started. Before you can connect to a network 1 Getting Started This chapter contains the information you need to install either the Apple Remote Access Client or Apple Remote Access Personal Server version of Apple Remote Access 3.0. Use Apple Remote

More information

Network administrators must be aware that delay exists, and then design their network to bring end-to-end delay within acceptable limits.

Network administrators must be aware that delay exists, and then design their network to bring end-to-end delay within acceptable limits. Delay Need for a Delay Budget The end-to-end delay in a VoIP network is known as the delay budget. Network administrators must design a network to operate within an acceptable delay budget. This topic

More information

TCP (Transmission Control Protocol)

TCP (Transmission Control Protocol) TCP (Transmission Control Protocol) Originally defined in RFC 793 (September 1981) UDP features: multiplexing + protection against bit errors Ports, checksum Connection-oriented Establishment and teardown

More information

Smoking and any food or drinks are not permitted in the Applications Lab!

Smoking and any food or drinks are not permitted in the Applications Lab! 220 Lab C Introduction to Cisco IP Telephony Pre-Lab Activities: None Purpose of the experiment: To explore the Cisco IP Telephony System configuration options, and its use. Smoking and any food or drinks

More information

Implementing and testing tftp

Implementing and testing tftp CSE123 Spring 2013 Term Project Implementing and testing tftp Project Description Checkpoint: May 10, 2013 Due: May 29, 2013 For this project you will program a client/server network application in C on

More information

Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme. Auxiliary Protocols

Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme. Auxiliary Protocols Auxiliary Protocols IP serves only for sending packets with well-known addresses. Some questions however remain open, which are handled by auxiliary protocols: Address Resolution Protocol (ARP) Reverse

More information

Polycom SoundPoint IP 650

Polycom SoundPoint IP 650 Polycom SoundPoint IP 650 User Guide For training/documentation, please visit us @ http://customertraining.verizonbusiness.com or call 1 800 662 1049 2009 Verizon. All Rights Reserved. The Verizon and

More information

Application Protocols for TCP/IP Administration

Application Protocols for TCP/IP Administration Application Protocols for TCP/IP Administration BootP, TFTP, DHCP Agenda BootP TFTP DHCP BootP, TFTP, DHCP, v4.4 2 Page 60-1 BootP (RFC 951, 1542, 2132) BootP was developed to replace RARP capabilities

More information

Centrex CustoPAK USER GUIDE. Telephone Number. Verizon Telephone Number. Switch Type: 1A 5E DMS 100 EWSD DMS 10

Centrex CustoPAK USER GUIDE. Telephone Number. Verizon Telephone Number. Switch Type: 1A 5E DMS 100 EWSD DMS 10 Centrex CustoPAK USER GUIDE Telephone Number Verizon Telephone Number Switch Type: 1A 5E DMS 100 EWSD DMS 10 Table of Contents Introduction to This Guide... 3 Overview of Your CustoPAK System... 5 Terms

More information

TCP Session Management (SesM) Protocol Specification

TCP Session Management (SesM) Protocol Specification TCP Session Management (SesM) Protocol Specification Revision Date: 08/13/2015 Version: 1.1e Copyright 2015 Miami International Securities Exchange, LLC. All rights reserved. This constitutes information

More information

Voice Over Internet Protocol(VoIP)

Voice Over Internet Protocol(VoIP) Voice Over Internet Protocol(VoIP) By Asad Niazi Last Revised on: March 29 th, 2004 SFWR 4C03 Major Project Instructor: Dr. Kartik Krishnan 1. Introduction The telecommunications companies around the world

More information

NAT TCP SIP ALG Support

NAT TCP SIP ALG Support The feature allows embedded messages of the Session Initiation Protocol (SIP) passing through a device that is configured with Network Address Translation (NAT) to be translated and encoded back to the

More information

ELEC3030 (EL336) Computer Networks. How Networks Differ. Differences that can occur at network layer, which makes internetworking difficult:

ELEC3030 (EL336) Computer Networks. How Networks Differ. Differences that can occur at network layer, which makes internetworking difficult: How Networks Differ Differences that can occur at network layer, which makes internetworking difficult: It is impossible to resolve all differences, and the solution is to take a simple approach (as in

More information

ESSENTIALS. Understanding Ethernet Switches and Routers. April 2011 VOLUME 3 ISSUE 1 A TECHNICAL SUPPLEMENT TO CONTROL NETWORK

ESSENTIALS. Understanding Ethernet Switches and Routers. April 2011 VOLUME 3 ISSUE 1 A TECHNICAL SUPPLEMENT TO CONTROL NETWORK VOLUME 3 ISSUE 1 A TECHNICAL SUPPLEMENT TO CONTROL NETWORK Contemporary Control Systems, Inc. Understanding Ethernet Switches and Routers This extended article was based on a two-part article that was

More information

A Layered Approach to Computer Networks

A Layered Approach to Computer Networks A Layered Approach to Computer Networks Physical Layer Data Link Layer Network Layer Transport Layer Session Layer Presentation Layer Application Layer Different layer of abstraction Different error control

More information

Call Waiting. Cancel Call Waiting

Call Waiting. Cancel Call Waiting PhoneFeatures 1 Call Waiting Cancel Call Waiting 2 Three-Way Calling Personal Ringing 3 Speed Calling Call Transfer 4 Call Hold Call Forwarding 5 Call Forwarding Don t Answer Call Forwarding Busy Line

More information

Allworx Queuing and Automated Call Distribution Guide (Release 7.2.3.x)

Allworx Queuing and Automated Call Distribution Guide (Release 7.2.3.x) Allworx Queuing and Automated Call Distribution Guide (Release 7.2.3.x) No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic,

More information

Enghouse Interactive. Vision 80/20 Avaya IP Office. Installation manual - Avaya IP Office. Version 3.0

Enghouse Interactive. Vision 80/20 Avaya IP Office. Installation manual - Avaya IP Office. Version 3.0 Enghouse Interactive Installation manual - Avaya IP Office Vision 80/20 Avaya IP Office Version 3.0 All material is copyright protected and belongs to Visionutveckling. The material may not be sold, distributed

More information