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.
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. >>>  = [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. >>>  = [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 >>>  = [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). >>>  = [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. >>>  = [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 >>>  = [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. >>>  = [ECHO-REPLY] <REFERENCE> This token is the response to the PLEASE-ECHO token. The <REFERENCE> here is copied from the one specified there. >>>  = [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 >>>  = [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 >>>  = [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. >>>  = [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 >>>  = [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. >>>  = [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. >>>  = [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. >>>  = [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. >>>  = [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 >>>  = [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. >>>  = [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: >>>  = [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 Transport Protocol Provides end-to-end transport Hides the network details Transport protocol or service (TS) offers: Different types of services QoS Data
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
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
Internet Protocol IP Datagram, Fragmentation and Reassembly IP Datagram Header Data Data (variable length) IP Packet Header number of IP protocol Current version is 4 6 has different header format IP Packet
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
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,
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
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
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
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
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
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
TCP/IP Page 1 of 5 TCP/IP INTRODUCTION The internet uses a variety of technologies to provide end-to-end communication between applications on different computers. Most applications use Transport Control
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
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
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
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.
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
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.
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,
TCP and UDP Professor of CIS Columbus, OH 43210 Jain@ACM.Org http://www.cis.ohio-state.edu/~jain/ 12-1 Overview Key features Header format Mechanisms Implementation choices Slow start congestion avoidance
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Access Control: Firewalls (1) World is divided in good and bad guys ---> access control (security checks) at a single point of entry/exit: in medieval castles: drawbridge in corporate buildings: security/reception
User Guide Verizon Centrex CustoPAK Telephone Number Verizon Telephone Number Switch Type: 1A 0 EWSD 2008 Verizon. All Rights Reserved. 3001-0708 Table of Contents Introduction to This Guide... 3 Overview
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
SFWR 4C03: Computer Networks & Computer Security Jan 3-7, 2005 Lecturer: Kartik Krishnan Lecture 1-3 Communications and Computer Networks The fundamental purpose of a communication network is the exchange
Application Note IP Addressing A Simplified Tutorial July 2002 COMPAS ID 92962 Avaya Labs 1 All information in this document is subject to change without notice. Although the information is believed to
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
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,
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
Empowered by Innovation User s Guide P/N 1770082 July 2006 Printed in U.S.A. This manual has been developed by NEC Unified Solutions, Inc. It is intended for the use of its customers and service personnel,
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
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
Module 7 Routing and Congestion Control Lesson 4 Border Gateway Protocol (BGP) Specific Instructional Objectives On completion of this lesson, the students will be able to: Explain the operation of the
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)
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