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.

21 17 >>> [33] = [I-WANT-TO-JOIN-THE-CONFERENCE] This token is sent from a user who wants to participate in a particular conference to the AC of that conference, asking an approval to join. It is advised that together with this token some information be supplied to the AC in order to identify the conference and the access privileges. This information should include at least the specification of that user (address, extension, alternate-address and nicknames, if any) the ID of the conference, and the information which is required by the AC, if any. If the AC does not accept this user to the conference, he sends to this user a BYE token, or ignores him. It would be highly appreciated if the AC adds a REASON code to the rejection token. If the user is accepted, the AC sends him information about the conference, (vocoder and style) and the BM (see below) of the participants who have already joined this conference, and are still active in it. The BM is the CONFERENCE-BIT-MAP, having one bit per user. The full participants list, their addresses, extensions, alternate-addresses and nicknames may be requested by sending the TELL-ME- ABOUT-USERS token. See the CONFERENCE-BIT-MAP token for more details. >>> [34] = [CONFERENCE-ID] <CONF-ID> This token is used to communicate the CONF-ID, the conference identification, which may be any arbitrary sequence of words, character strings included. The value and format of the CONF-ID depend on the AC and the particular conference. It is recommended that CONF-ID be a set of 5 words, 2 specifying the IP-address of the conference originator, 2 specifying his extension and a random word assigned by him to this conference, in order to assure the uniqueness of this CONF-ID. This CONF-ID is given to the AC at conference set-up time. When the conference actually starts the AC assign a globally unique connection-id number (CID) to it. NVP-II identifies conference either by the CONF-ID or by the CID. On the other hand, ST has no notion of CONF-ID at all, and identifies conference only by their CIDs.

22 18 >>> [35] = [CONFERENCE-CONNECTION-NAME] <CID> This token is used to communicate the conference connection identification. The Conference-ID is a single arbitrary word assigned specifically to that conference by the AC. The globally uniqueness of CID is very important for efficient use of the broadcast capability, if any, of the supporting communication networks. Even though Conference may be identified by either the CONF-ID or by the CID, it is recommended to use CID, after it is received from the AC, because it is shorter, 1 word compared with the 5 words of the CONF-ID. ST identifies conferences only by their CIDs. >>> [36] = [CONFERENCE-PASSWORD] <PW> This token is used to communicate the conference password, which may be any arbitrary sequence of words, character strings included. Its value and format depend on the AC and the particular conference. >>> [37] = [CONFERENCE-ACCESS] <INFO-FOR-AC> The purpose of this token is to communicate any information which may be needed for gaining access to the particular conference. Its value and format depend on the AC and the particular conference. >>> [38] = [CONFERENCE-STYLE] <STYLE> This token describes the style of the conference according to the codes defined herein: 1 = free style more later...

23 19 >>> [39] = [CONFERENCE-BIT-MAP] <USER-ID> <NP> <BM> This token carries the entire active-participants list of the conference. It may be sent by any participant to any other participant. In particular it may be sent by the AC to a participant who is in the process of joining a conference. The USER-ID field is used only when this token is sent by the AC to a conference participant. Then the USER-ID field informs the newcomer which USER-ID is assigned to him. When this token is sent by any participant, probably in response for a request for conference status, the value of the USER-ID field is ignored. The next word is the Number-of-Participants, <NP>, in the conference, which really means the "highest USER-ID in the conference". As long as none of the participants leaves the conference NP is equal to the actual number of participants. Since USER-IDs are not recycled, participants who join after other have left, are assigned USER-IDs which are higher than the actual number of participants in the conference, at that time. Next, after the <NP>, the conference Bit Map, <BM>, is carried. The BM is a sequence of words, whose bits correspond to conference participants. The first bit (i.e., the most significant) of the first word corresponds to the user with USER-ID=1. The last (least significant) bit of the first word corresponds to USER-ID=16, the first bit of the second BM word corresponds to USER-ID=17, and so on. The bits of the <BM> which correspond to the active participants in the conference are set to 1, and all the other bits are set to 0. Note that the total number of 1 s in the <BM> is the number of actual participants in the conference, at that time. It is easy to verify that the number of words in the <BM> is the integer part of (NP+15)/16. The <BM> does NOT carry its own length which may be derived either from the length of this token or from the <NP>. Note that this token does not carry any information about the individual participants (addresses, extensions, alternate addresses and nicknames). This information may be requested by sending the TELL-ABOUT-USER token. >>> [40] = [PLEASE-GIVE-ME-THE-CONFERENCE-STATUS] This token requests the status of the conference. It is recommended that it is accompanied by the conference-id. It is expected that in response to this token the receiver will return all the tokens which describe the conference status. This includes always the BM (see above), and probably some additional information which depends on the style of the conference. The information about the users is not expected to be sent in response to this token. If it is needed, it may be obtained by the TELL-ABOUT- USER token.

24 20 >>> [41] = [USER-IS-OUT] <USER-ID> This token announces that a certain participant is no longer a part of the conference. This token is acted upon only if it was sent either by the AC or by that user. The AC may use this token to announce the departure of several participants at once. >>> [48] = [I-AM-TALKING-NOW] This token is used in a free style conference. The participant who believes that he has the floor sends this token occasionally (say every 2 seconds) using the ST.DG facility, i.e., as control without data. The purpose of this token is to help identifying speakers conflict which may rise as a result of a certain race conditions. It is recommended that the speaker s precedence is sent together with this token. >>> [49] = [I-AM-DONE] This token indicates that its sender "relinquishes the floor", i.e., has finished talking. This token is important when an automated process is monitoring the use of the floor (e.g., floor control), otherwise - this may be inferred from the speech (e.g., "That s all, folks" and "over and out"). >>> [50] = [NET-MEASUREMENT-TIMESTAMP] <VALUE> <HOST> <EXT> This token may be included in order to facilitate network measurement experiments. The value is either the low order one or two words of the number of milliseconds since Midnight (GMT) March 1, The date algorithm is number 199 from CACM collected algorithms. Leap seconds are ignored in this calculation. The host field is an optional two word host IP address. If the host field is present it may be followed by the NVP extension (two words). These fields must be in the order specified here. The length field specifies exactly which fields are present in this token. Length = 1: 16 bit timestamp only Length = 2: 32 bit timestamp only Length = 3: 16 bit + IP Address Length = 4: 32 bit + IP Address Length = 5: 16 bit + IP Address + Extension Length = 6: 32 bit + IP Address + Extension

25 21 (H) THE NVP-II DATA PROTOCOL The NVP-II data protocol consists of a two word header, followed by some options (if any), followed by the vocoding data. The header word has the following 4 fields in Big-Endian order: SEQUENCE-NUMBER Six bits field for a modulo-64 sequence number. It is not necessary to clear this field and to start each speech communication from SEQ=0. TIME-STAMP CHECKSUM TOKEN-LENGTH If no messages are lost the SEQ field should have continuous values through the speech in spite of the silence periods. Ten bits field indicating the time corresponding to the creation of the first parcel in this message. The TIME-STAMP is measured in vocoder-frames (messages). Hence, the difference between the values of the TIME-STAMP of successive messages should be equal to the number of parcels in the first message, unless silence or message loss occurred in between. One byte field to protect the NVP data header. The checksum value is computed according to the scheme of computing the checksum for ST, as defined in the ST-document [FORGIE]. One byte field specifies length of NVP control tokens which may follow. Length is expressed as words. If the length is non zero it must include the NVP checksum which must precede any NVP control tokens. The OPTIONS which may follow the header word are NVP-II control tokens. In order to use special privately agreed upon options -- tokens with CODEs above 127 (177-octal) should be used. By definition the options are an integral number of words. The following data is according to the definition of the vocoding which was agreed upon. The data is expected to be padded to occupy an integral number of words.

26 22

27 23 (I) APPENDIX I.1. CHARACTER PARITY The MSB of the ASCII codes (the 200 bit) is always set to 0. The possible options are: - always 0, - always 1, - even parity, - odd parity, - other, e.g., arbitrary. We can either agree on one of them (as we do here) or figure a way to achieve and/or verify the compatibility of the options used by the sender and the receiver. I.2. CHARACTER ORDER IN STRINGS It is recommended that the user read "On Holy Wars and a Plea for Peace" regarding word and byte order. Since the IP environment and 1822 are Big-Endians we recommend using Big-Endians order also for byte order in character strings, such that "EDNA" is "ED-NA" not "DE-AN".

28 24

29 25 Sample NVP/ST scenarios.

30 26 SAMPLE NVP/ST SCENARIOS This document consists of several parts: An annotated example for PTP communication An annotated example for conference communication An abbreviated example for PTP communication An abbreviated example for conference communication More NVP/ST abbreviated scenarios. The annotated examples show in great detail the NVP and the ST messages which are exchanged across the communication networks. It is highly recommended that any NVP communication follow these sample scenarios as closely as possible. The abbreviated examples are shown here in order to cover many different possible situations.

31 27 (A) AN ANNOTATED EXAMPLE FOR PTP COMMUNICATION In the following examples Arbitrary numbers have always 3 digits. Due to the application of unreliable transmission NVP always protects its tokens with the checksum feature. This policy is practiced even when reliable networks such as the ARPANET are used. The checksum is computed as the 1 s complement of the 1 s complement sum of all the words. The 1 s complement sum of the control tokens including checksum will equal -0 ( ). This is the same scheme defined in the ST-document [FORGIE]. Note that the length of the NVP control tokens must be computed from the length field in the ST header. Assume that A wants to initiate a PTP call to B. The first exchange is an NVP initial call which is carried as a datagram by IP.ST. The first message includes the IP-header (see IP-4, [POSTEL]) with the PROTOCOL field having the value 5, for ST. Following is the IP.ST message header (see Jim Forgie s IEN-119, section 5.0) which is identified as such by having the value [IP.ST]=1 in its first four bits. This IP.ST message header, which consists of 6 words, is followed by the NVP token checksum and five NVP tokens: CONNECTION-NAME, VOCODER, READY, and PLEASE-ECHO. This message is shown below in figure A-1. Please note that messages have a "sender" (or "source") and a "receiver" (or "destination") but connections have a "caller" and a "callee". The main difference is that each of A and B is both a sender and a receiver of messages, but only A is the caller and only B is the callee, of this connection. Note also that the CONNECTION-NAME is based on the address (IPaddress and extension) of the caller. If all goes well, as assumed here, B returns to A an IP.ST message with the following tokens: CONNECTION-NAME, I-AM-RINGING, ECHO-REPLY, and also his ALTERNATIVE-ADDRESSes and NICKNAME, if any. In our example B has two different IP-addresses (Baddr and Baddr ) but only one extension (Bx). This message is shown in figure A-2. In case of vocoder mismatch B sends a BYE token, with REASON=INCOMPATABILITY, followed by an optional TEXT explaining the situation, followed optionally by VOCODER tokens corresponding to all the available vocoders. If A wants to try to use another vocoder it has to send another initial connection token, with a different CONNECTION-NAME. It is recommended that the CONNNECTION- value be incremented by one for every new attempt of creating a new connection. After receiving the I-AM-RINGING, A tries to establish a FDX-ST-data connection, by issuing a CONNECT. The format of the CONNECT message is shown in figure A-3. Suppose that ST-X is an ST module between ST-A and ST-B. When it gets the above message an ACKNOWLEDGEMENT is issued back to A, as shown in figure A-4, while the CONNECT keeps propagating to B. In following figures the messages are shown as if no intermediate ST-agents exist between ST-A and ST-B. In that case only 2 CID exist, the one assigned by ST-A (147) and the one assigned by ST-B (741).

32 28 Finally B accepts the connect message, and an ACCEPT is propagated back to A. If there are any intermediate ST modules, each will acknowlege the ACCEPT. The ACCEPT message, as sent by B is shown in figure A-5. Please notice that CONNECTION-NAMEs and NVP s references are end-to-end entities whereas ST s CIDs (in PTP only) and references are hop-to-hop entities. CIDs in conferences are globally unique entities. It is possible for A to initiate an ST-connection without waiting for the NVP token I-AM-RINGING. Doing this expedites the call establishment but may cause the creation of ST connections which may have to be modified later due, for example, to vocoders mismatch. The ST messages are recognized to be different than the standard IP messages, by having the value 5 in their first 4 bits field, which is treated by gateways as IP-version. Note, it is a nice coincidence that the value 5 serves both as the indicator of ST, both in the IP-version and the IP-protocol fields. Every few seconds A asks B to keep ringing by sending him a message including only the CONNNECTION-ID as shown in figure A-6, to which B responds with another I-AM-RINGING token, as shown in figure A-7, until finally the call is answered by some person, and B sends an I-AM-READY to A, as shown in figure A-8. Finally, after B is READY (a la NVP) and the FDX-data-connection is open (a la ST) speech data may be exchanged by using ST.ST messages. A data message from A to B is shown in figure A-9. The speech communication may be terminated either voluntarily by either party, B in this example, or by any of many possible system malfunction. Figure A-10 shows the NVP termination token, BYE, as sent by B. In addition, B terminates the ST-connection by issuing a REFUSE as shown in figure A-11, in the meanwhile A may also take the ST connection down by issuing a DISCONNECT as shown in figure A-12. Note that the asymmetry of the REFUSE and DISCONNECT messages matches the asymmetry of the CONNECT and ACCEPT messages. This connection has CIDs assigned to it, 147 by ST-A in the CONNECT message (figure A-3), and 741 by ST-B in the ACCEPT message (figure A-5). However, since the DISCONNECT and REFUSE messages are directed to the ST as a whole (including all the intermediate ST agents), they are sent with CID=0.

33 29

34 IP-version 4 IHL=5 (32bit) Type Of Service IP 1 Total IP-message Length, in octets 56. IP 2 IP-message IDentification IP 3 0 : 0 : 0 Fragment Offset IP 4 Time To Live Protocol = ST = 5 IP 5 IP Header Checksum IP 6 IP +--- IP-address of the Sender (Aaddr) IP 8 IP +--- IP-address of the Receiver (Baddr) IP 10 Protocol=IP.ST=1 ST-version Length in octets 36. ST 11 Header Checksum ST 12 ST +--- Sender extension (Ax) ST 14 ST +--- Receiver extension (Bx) ST 16 Token Checksum NVP 17 Token = CONNECTION-NAME 8 Token Data.Length (words) 5 NVP 18 NVP +--- IP-address of the Caller (Aaddr) NVP 20 NVP +--- Caller extension (Ax) NVP 22 Connection-Number 772 NVP (continued on the next page)

35 Token = VOCODER-CODE 4 Token Data.Length (words) 1 NVP 24 L P C M 3 NVP Token = I-AM-READY 1 Token Data.Length (words) 0 NVP Token = PLEASE-ECHO 6 Token Data.Length (words) 1 NVP 27 My end/end R E F E R E N C E 700 NVP Figure A-1: NVP-A=>NVP-B (IP.ST/NVP): An initial call.

36 IP-version 4 IHL=5 (32bit) Type Of Service IP 1 Total IP-message Length, in octets 64. IP 2 IP-message IDentification 222 IP 3 0 : 0 : 0 Fragment Offset IP 4 Time To Live Protocol = ST = 5 IP 5 IP Header Checksum IP 6 IP +--- IP-address of the Sender (Baddr) IP 8 IP +--- IP-address of the Receiver (Aaddr) IP 10 Protocol=IP.ST=1 ST-version Length in octets 44. ST 11 Header Checksum ST 12 ST +--- Sender extension (Bx) ST 14 ST +--- Receiver extension (Ax) ST 16 Token Checksum NVP 17 Token = CONNECTION-NAME 8 Token Data.Length (words) 5 NVP 18 NVP +--- IP-address of the Caller (Aaddr) NVP 20 NVP +--- Caller extension (Ax) NVP 22 Connection-Number 772 NVP (continued on the next page)

37 Token = ALT-ADDRESS 18 Token Data.Length (words) 5 NVP 24 USER-ID = myself 0 NVP 25 NVP +--- My alternate IP-address (Baddr ) NVP 27 NVP +--- My alternate extension (Bx) NVP Token = I-AM-RINGING 3 Token Data.Length (words) 0 NVP Token = ECHO-REPLY 7 Token Data.Length (words) 1 NVP 31 Your end/end R E F E R E N C E 700 NVP Figure A-2: NVP-B=>NVP-A (IP.ST/NVP): Accepting the call.

38 Protocol=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 40. hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 15. hdr 5 ST-OP-CODE = CONNECT.PTP 5 Length of this body(words) 15. body 6 Checksum of this body body 7 body +--- IP-Address of Sender body 9 My hop/hop Reference 321 body 10 body +--- IP-address of the Caller (Aaddr) body 12 body +--- Caller extension (Ax) body 14 Connection-Number 772 body 15 body +--- IP-address of the Callee (Baddr) body 17 body +--- Callee extension (Ax) body 19 CID (hop/hop) 147 body Figure A-3: ST-A=>ST-B (ST.DG): a CONNECT message.

39 Protocol=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 20. hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 3 hdr 5 ST-OP-CODE = ACK 1 Length of this body (words) 5 body 6 Checksum of this body body 7 body +--- IP-Address of Sender (Baddr) body 9 Your hop/hop Reference 321 body Figure A-4: ST-X=>ST-A (ST.DG): An ACK message to ST-A.

40 Protocol=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 40. hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 15. hdr 5 ST-OP-CODE = ACCEPT.PTP 6. Length of this body(words) 15. body 6 Checksum of this body body 7 body +--- IP-Address of Sender (Baddr) body 9 My hop/hop Reference 444 body 10 body +--- IP-address of the Caller (Aaddr) body 12 body +--- Caller extension (Ax) body 14 Connection-Number 772 body 15 body +--- IP-address of the Callee (Baddr) body 17 body +--- Callee extension (Bx) body 19 CID (hop/hop) 741 body Figure A-5: ST-B=>ST-A (ST.DG): An ACCEPT message.

41 IP-version 4 IHL=5 (32bit) Type Of Service IP 1 Total IP-message Length, in octets 46. IP 2 IP-message IDentification IP 3 0 : 0 : 0 Fragment Offset IP 4 Time To Live Protocol = ST = 5 IP 5 IP Header Checksum IP 6 IP +--- IP-address of the Sender (Aaddr) IP 8 IP +--- IP-address of the Receiver (Baddr) IP 10 Protocol=IP.ST=1 ST-version Length in octets 26. ST 11 Header Checksum ST 12 ST +--- Sender extension (Ax) ST 14 ST +--- Receiver extension (Bx) ST ================================================================+ 16 Token Checksum NVP 17 Token = CONNECTION-NAME 8 Token Data.Length (words) 5 NVP 18 NVP +--- IP-address of the Caller (Aaddr) NVP 20 NVP +--- Caller extension (Ax) NVP 22 Connection-Number 772 NVP Figure A-6: NVP-A=>NVP-B (IP.ST/NVP): Please keep ringing.

42 IP-version 4 IHL=5 (32bit) Type Of Service IP 1 Total IP-message Length, in octets 48. IP 2 IP-message IDentification IP 3 0 : 0 : 0 Fragment Offset IP 4 Time To Live Protocol = ST = 5 IP 5 IP Header Checksum IP 6 IP +--- IP-address of the Sender (Baddr) IP 8 IP +--- IP-address of the Receiver (Aaddr) IP 10 Protocol=IP.ST=1 ST-version Length in octets 28. ST 11 Header Checksum ST 12 ST +--- Sender extension (Bx) ST 14 ST +--- Receiver extension (Ax) ST 16 Token Checksum NVP 17 Token = CONNECTION-NAME 8 Token Data.Length (words) 5 NVP 18 NVP +--- IP-address of the Caller (Aaddr) NVP 20 NVP +--- Caller extension (Ax) NVP 22 Connection-Number 772 NVP Token = I-AM-RINGING 3 Token Data.Length (words) 0 NVP Figure A-7: NVP-B=>NVP-A (IP.ST/NVP): We keep ringing.

43 IP-version 4 IHL=5 (32bit) Type Of Service IP 1 Total IP-message Length, in octets 48. IP 2 IP-message IDentification IP 3 0 : 0 : 0 Fragment Offset IP 4 Time To Live Protocol = ST = 5 IP 5 IP Header Checksum IP 6 IP +--- IP-address of the Sender (Baddr) IP 8 IP +--- IP-address of the Receiver (Aaddr) IP 10 Protocol=IP.ST=1 ST-version Length in octets 28. ST 11 Header Checksum ST 12 ST +--- Sender extension (Bx) ST 14 ST +--- Receiver extension (Ax) ST 16 Token Checksum NVP 17 Token = CONNECTION-NAME 8 Token Data.Length (words) 5 NVP 18 NVP +--- IP-address of the Caller (Aaddr) NVP 20 NVP +--- Caller extension (Ax) NVP 22 Connection-Number 772 NVP Token = I-AM-READY 1 Token Data.Length (words) 0 NVP Figure A-8: NVP-B=>NVP-A (IP.ST/NVP): Ready For data.

44 IP.versn=ST=5 ST-version Length of ST-header (words) 7 hdr 1 Total Length in octets 48. hdr 2 ST-header checksum hdr 3 CID (hop/hop) 741 hdr1 +PTP+STRM : 0 : 0 : 0 : 0 : 0 : 0 : 0 Body1 Length.Data (words) 7 hdr1 5 CID (hop/hop) 321 hdr2 +PTP+STRM : 0 : 0 : 0 : 0 : 0 : 0 : 0 Body2 Length.Data (words) 10 hdr2 7 SEQUENCE-NUMBER TIME=STAMP, in vocoder frames bdy1 8 Header Check sum Token Length (Words) 0 bdy1 9 Data word 1, for connection 741 bdy1 10 Data word 2, for connection 741 bdy1 11 Data word 3, for connection 741 bdy1 12 Data word 4, for connection 741 bdy1 13 Data word 5, for connection 741 bdy1 ================================================================+ 14 SEQUENCE-NUMBER TIME=STAMP, in vocoder frames bdy2 15 Header Check Sum Token Length (words) 5 bdy2 16 Token Checksum NVP 17 Token = PLEASE-ECHO 6. Token Data.Length (words) 1 NVP 18 My end/end R E F E R E N C E 666 NVP 19 Token = NET-MEASUREMENT-TS 50 Token Data.Length (words) 1 NVP 20 TIME STAMP NVP Data word 1, for connection 321 bdy2 22 Data word 2, for connection 321 bdy2 23 Data word 3, for connection 321 bdy2 Figure A-9: ST-A=>ST-B (ST.ST): Data, (note the aggregation).

45 IP.versn=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 20. hdr 2 ST-header checksum hdr 3 CID (hop/hop) 741 hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 5 hdr 5 Token Checksum NVP 6 Token = BYE 2 Token Data.Length (words) 1 NVP 7 R E A S O N = normal termination 1 NVP Figure A-10: NVP-B=>NVP-A (ST.DG): Normal call termination IP.versn=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 32 hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 11 hdr 5 ST-OP-CODE = REFUSE.PTP 7 Length (words) 11 body 6 Checksum of this body body 7 body +--- Sender IP-address My hop/hop Reference 123 body 10 body +--- IP-address of the Caller (Aaddr) body 12 body +--- Caller extension (Ax) body 14 Connection-Number 772 body 15 No reason is given 0 body Figure A-11: ST-B=>ST-A (ST.DG): a REFUSE message.

46 IP.versn=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 32 hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 11 hdr 5 ST-OP-CODE = DISCONNECT.PTP 8 Length (words) 11 body 6 Checksum of this body body 7 body +--- Sender IP-address My hop/hop Reference 555 body 10 body +--- IP-address of the Caller (Aaddr) body 12 body +--- Caller extension (Ax) body 14 Connection-Number 772 body 15 No reason is given 0 body Figure A-12: ST-A=>ST-B (ST.DG): a DISCONNECT message.

47 43 (B) AN ANNOTATED EXAMPLE FOR CONFERENCE COMMUNICATION In the following example we follow the steps taken (and the messages sent) for joining a conference and participating in it. We assume that there is only one access controller (AC) whose address is well known. The existance of a single AC does not mean that it is necessarily implemented in a centralized way. It is expected that the AC will be implemented in a distributed way. We assume that the AC has already been informed by the conference initiator about the conference and all its parameters. As a part of the conference set-up procedure the conference initiator (say G) gave the AC the ID of this conference, the CONF-ID, which in this example is the following 5 words: {Gaddr, Gx, 666}. When the expected participants are notified about the conference they are told the essential information about the conference like topic, language, time, vocoder, style, access-scheme (e.g., password), other participants and the like. In addition, they are told what the CONF-ID is. Suppose that the user A is the 5th person who joins the conference, and that by then the 3rd participant is already out of the conference. The joining process starts when A, the person, tells his NVP (NVP-A) that he wishes to join the conference specified by the given CID. In addition, person-a tells the NVP his own nickname ("Joe"), the password of the conference ("CONF123") and any other information which is needed in order to be admitted to the conference. The NVP uses this information to construct an IP.ST message to the AC. Since this site has 2 IPaddresses (Aaddr and Aaddr ), the NVP tells the AC about both, using the former (Aaddr) as the primary one and the latter (Aaddr ) as the alternate one. This IP.ST message is shown in figure B-1. The AC checks the information supplied by A and decides to accept him into the conference. It advises A about his acceptance by sending him information about the conference Connection-ID, the CID (say 777), the vocoding used (say LPCM), the style (say FREE) and the CONFERENCE-BIT-MAP (BM) specifying the participants which are already (and still) active in the conference, hence to whom A should issue a CONNECT. In addition, the AC assigns to A a USER-ID, which obviously is higher than the ones of the participants refered to by the bit-map. Since A is the 5th participant to join the conference he gets USER-ID=5. Since the 3rd participant is not active only 3 (out of 4 possible) bits in the BM are 1s. Note that A s own bit (the 5th one) is 0. The above CID, 777, is the CONNECTION-ID for this conference. The AC makes sure that it is globally unique because this is important for efficient operation over broadcast networks.

48 44 This positive response of the AC to NVP-A is sent as an IP.ST message, as shown in figure B-2. Upon receiving the above acceptance-to-the-conference message from the AC, NVP-A turns to his ST module (ST-A) tells it the CID of the conference and asks it to CONNECT to the users which are specified by the BM. A special CONNECT message is sent to each of the already active participants here. ST-A has no idea who these participants are. It turns around and asks the AC to supply information about them. It uses the ST-op-code TELL-ME (which is similar to NVP s TELL-ABOUT-USER). This request is communicated to the AC via an IP.ST message which is shown in figure B-3. The AC has no simple way to tell a-priory if an IP.ST carries NVP tokens or ST-op-codes. In order to ease this task the following convention is recommended: Even AC-extensions are reserved for NVPtokens, and the odd (successive) AC-extensions are reserved for ST-op-codes of the same conference. Hence a conference is always assigned 2 succesive even-followed-by-odd AC-extensions for NVP/ST control communication. Note that in the following example (and the figures) NVP-A communicates with the AC-extension 122 whereas ST-A communicates with 123. The AC responds by sending the addresses of these users back to ST-A, by using the ST-op-code INFO (which is similar to NVP S INFO-ABOUT-USER token). This message is shown in figure B-4 as it is when arriving back at ST-A. Note that at this point it carries the same hop/hop-reference as the message of figure B-3 did. After receiving this information ST-A figures out the routing to these users. Suppose that it figures out that participants #1 and #4 may be reached via the intermediate ST agent Ga, and that participant #3 may be reached via Gb. ST-A then sends to Ga 2 ST-CONNECT messages, one for #1 and one for #4. The CONNECT message for #1 is shown in figure B-5. ST-A also sends to Gb an ST-CONNECT message for #2, as shown in figure B-6. These messages are full fledged ST messages, using the ST.DG mechanism. Note that the above messages are identical except in their TARGET and (possibly, but not necessarily) REFERENCE fields. Ga cannot ACCEPT the CONNECT requests without clearing them all the way with the actual target users, #1 and #4 here. However, in the meanwhile it ACKs the CONNECT requests to let ST-A know that no retransmission of these CONNECT requests is necessary. The ACK message which is shown in figure B-7 is the one refering to the message shown in figure B-5. Similarly, Gb ACKs the other CONNECT request, as shown in figure B-8. Note that the only possible difference between these ACK messages is the REFERENCE field. Upon receiving the CONNECT message Ga may realize that it has no information whatsoever about this conference. In this case it would send to the AC an TELL-ME message, similar to the one sent by ST-a, shown in figure B-3, but asking only about participants #1+#4. The AC would send this information by an INFO message, similar to the one shown in figure B-4. On the other hand, Ga may already know about this conference and about both participants #1 and #4, or about one of them only.

49 45 It is possible that Ga would request, from the AC, the information about #1 only before getting the CONNECT for #4, and then would send a separate message to the AC about #4 only. In this case the AC may respond in two separate messages to Ga, or may combine the two responses into a single message, even though the request arrived separately. Another possibility for Ga is to turn back to ST-A and ask it to supply the required information about these users. Similarly, Gb may request information about the conference and about participant #2, from the AC. If so, a TELL-ME and an INFO messages are exchanged. On the other hand, it is possible that Gb already has this information and does not have to request it from the AC. After knowing about the target participants, Ga and Gb send CONNECT messages in the direction of the participants. This way the CONNECT request propogate toward the target destinations, where they are (hopefully) ACCEPTed. Upon ACCEPTing the CONNECT requests, ACCEPT messages are sent to the originators of the CONNECTs. Figure B-9 shows the ACCEPT message which ST-1, the ST of partiicpant #1 sends to ST-A, the ST of participant #5. This ACCEPT message should be ACKed by a message similar to those shown in figures B-7 and B-8. Similar ACCEPT messages are also sent by participants #2 and #4. After all the ACCEPT messages arrive at ST-A, this user (#5) is a full fledged member of the conference, and may submit and receive data by using the ST.ST conncetion. Figure B-10 shows an ST.ST message containing vocoder data from participant #5 to #1+#4, as transmitted from ST-A to Ga. The data is coded according to the NVP-data-protocol as described in the NVP-II document. A similar message has to be transmitted to Gb, for#2. It is shown in figure B-11. Note that except the BM these two messages are identical to each other. Obviously, if all of these participants were on the same broadcast network no such duplication of messages is ever needed. When it the time for the participant A to leave his NVP sends a USER-IS-OUT token, together with a BYE token, to the AC and to all the other participants. The mesage to the AC is sent by IP.ST, as shown in figure B-12. The messages to the other participants are sent by ST.ST. The message for #1+#4, via Ga, is shown in figure B-13. After then, with or without asking for NVP-level acknowledgements (the ECHO token) NVP tells ST to close all the connections associated with this conference. ST issues a separate DISCONNECT message, for each connection, using ST.DG. The DISCONNECT message from ST-A to Ga, for ST-1, is shown in figure B-14.

50 IP-version 4 IHL=5 (32bit) Type Of Service IP 1 Total IP-message Length, in octets 88. IP 2 IP-message IDentification IP 3 0 : 0 : 0 Fragment Offset IP 4 Time To Live Protocol = ST = 5 IP 5 IP Header Checksum IP 6 IP +--- IP-address of the Sender (Aaddr) IP 8 IP +--- IP-address of the Receiver (ACaddr) IP 10 Protocol=IP.ST=1 ST-version Length in octets 70. ST 11 ST +--- Sender extension (Ax) ST 13 ST +--- Receiver extension (ACx=122) ST 15 Token Checksum NVP 16 Token = I-WANT-TO-JOIN 33. Token Data.Length (words) 0 NVP Token = CONFERENCE-ID 34. Token Data.Length (words) 5 NVP 18 NVP +--- IP-address of the originator (Gaddr) NVP 20 NVP +--- Originator extension (Gx) NVP 23 The conference ID number 666 NVP (continued on the next page)

51 Token=CONFERENCE-PASSWORD 36. Token Data.Length (words) 4 NVP 25 " C " " O " NVP 26 " N " " F " NVP 26 " 1 " " 2 " NVP 27 " 3 " null NVP Token = USER-ADDRESS 17. Token Data.Length (words) 5 NVP 29 USER-ID = me 0 NVP 30 NVP +--- My IP-address (Aaddr) NVP 32 NVP +--- My extension (Ax) NVP Token = ALTERNTE-ADDRESS 18. Token Data.Length (words) 5 NVP 35 USER-ID = me 0 NVP 36 NVP +--- My alternate IP-address (Aaddr ) NVP 38 NVP +--- My alternate extension (Ax) NVP Token = NICKNAME 19. Token Data.Length (words) 3 NVP 41 USER-ID = me 0 NVP 42 " J " " O " NVP 43 " E " null NVP Figure B-1: NVP-A=>AC (IP.ST/NVP): I want to join a conference.

52 IP-version 4 IHL=5 (32bit) Type Of Service IP 1 Total IP-message Length, in octets 64. IP 2 IP-message IDentification IP 3 0 : 0 : 0 Fragment Offset IP 4 Time To Live Protocol = ST = 5 IP 5 IP Header Checksum IP 6 IP +--- IP-address of the Sender (ACaddr) IP 8 IP +--- IP-address of the Receiver (Aaddr) IP 10 Protocol=IP.ST=1 ST-version Length in octets 46. ST 11 ST +--- Sender extension (ACx=122) ST 13 ST +--- Receiver extension (Ax) ST 15 Token Checksum NVP 16 Token = CONFERENCE-ID 34. Token Data.Length (words) 5 NVP 17 NVP +--- IP-address of the originator (Gaddr) NVP 19 NVP +--- Originator extension (Gx) NVP 21 The conference ID number 666 NVP (continued on the next page) 48

53 Token = CONNECTION-ID 35. Token Data.Length (words) 1 NVP 23 The conference CID 777 NVP Token = CONFERENCE-STYLE 38. Token Data.Length (words) 1 NVP 25 F R E E S T Y L E 1 NVP Token = VOCODING-CODE 4 Token Data.Length (words) 1 NVP 27 L P C M 3 NVP Token = CONF-BIT-MAP 39. Token Data.Length (words) 3 NVP 29 Your U S E R - I D 5 NVP 30 N P (highest USER-ID) 5 NVP +#1-+#2-+#3-+#4-+you : 1 : 0 : 1 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 NVP Figure B-2: AC=>NVP-A (IP.ST/NVP): You are accepted.

54 IP-version 4 IHL=5 (32bit) Type Of Service IP 1 Total IP-message Length, in octets 46. IP 2 IP-message IDentification IP 3 0 : 0 : 0 Fragment Offset IP 4 Time To Live Protocol = ST = 5 IP 5 IP Header Checksum IP 6 IP +--- IP-address of the Sender (STaddr) IP 8 IP +--- IP-address of the Receiver (ACaddr) IP 10 Protocol=IP.ST=1 ST-version Length in octets 26. ST 11 ST +--- Sender extension (STx) ST 13 ST +--- Receiver extension (ACx=123) ST 15 ST-OP-CODE = TELL-ME 13. Length (words) 8 body 16 Checksum of this body body 17 My hop/hop reference 753 body 18 The conference CID 777 body TELL-ME-param = PART-NUM 10. Length (words) 4 body 20 A USER-ID for information request 1 body 21 A USER-ID for information request 2 body 22 A USER-ID for information request 4 body Figure B-3: ST-A=>AC (IP.ST/ST): Asking about #1+#2+#4.

55 51

56 IP-version 4 IHL=5 (32bit) Type Of Service IP 1 Total IP-message Length, in octets 72. IP 2 IP-message IDentification IP 3 0 : 0 : 0 Fragment Offset IP 4 Time To Live Protocol = ST = 5 IP 5 IP Header Checksum IP 6 IP +--- IP-address of the Sender (ACaddr) IP 8 IP +--- IP-address of the Receiver (STaddr) IP 10 Protocol=IP.ST=1 ST-version Length in octets 52. ST 11 ST +--- Sender extension (ACx=123) ST 13 ST +--- Receiver extension (STx) ST 15 ST-OP-CODE = INFO 14. Length (words) 21. ST 16 Checksum of this body ST 17 Your hop/hop reference 753 ST 18 The conference CID 777 ST (continued on the next page)

57 INFO-param = PART-LIST 13. Length (words) 17. ST 20 N P (highest USER-ID) 5 ST U S E R - I D = 1 ST 22 ST +--- IP-address for participant # ST 24 ST +--- The extension of participant # ST U S E R - I D = 2 ST 27 ST +--- IP-address for participant # ST 29 ST +--- The extension of participant # ST U S E R - I D = 4 ST 32 ST +--- IP-address for participant # ST 34 ST +--- The extension of participant # ST Figure B-4: AC=>ST-A (IP.ST/ST): Info about #1+#2+#4.

58 Protocol=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 26. hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 8 hdr 5 ST-OP-CODE = CONNECT.CONF 9 Length (words) 8 body 6 Checksum of this body body 7 body +--- IP-Address of Sender (Baddr) body 9 My hop/hop reference 452 body 10 The conference CID 777 body 11 USER-ID of the user who issues this CONNECT 5 body 12 USER-ID of the user to whom this CONNECT is issued 1 body Figure B-5: ST-A=>Ga (ST.DG): CONNECT to #1.

59 Protocol=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 26. hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 8 hdr 5 ST-OP-CODE = CONNECT.CONF 9 Length (words) 8 body 6 Checksum of this body body 7 body +--- IP-Address of Sender (Baddr) body 9 My hop/hop reference 454 body 10 The conference CID 777 body 11 USER-ID of the user who issues this CONNECT 5 body 12 USER-ID of the user to whom this CONNECT is issued 2 body Figure B-6: ST-A=>Gb (ST.DG): CONNECT to #2.

60 Protocol=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 20. hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 5. hdr 5 ST-OP-CODE = ACK 1. Length (words) 5. body 6 Checksum of this body body 7 body +--- IP-Address of Sender (Baddr) body 9 Your hop/hop reference 452 body Figure B-7: Ga=>ST-A (ST.DG): ACK of the CONNECT to # Protocol=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 20. hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 5. hdr 5 ST-OP-CODE = ACK 1. Length (words) 5. body 6 Checksum of this body body 7 body +--- IP-Address of Sender (Baddr) body 9 Your hop/hop reference 454 body Figure B-8: Gb=>ST-A (ST.DG): ACK of the CONNECT to #2.

61 Protocol=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 26. hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 8 hdr 5 ST-OP-CODE = ACCEPT.CONF 10. Length (words) 8 body 6 Checksum of this body body 7 body +--- IP-Address of Sender (Baddr) body 9 My hop/hop reference 666 body 10 The conference CID 777 body 11 USER-ID of the user who issues this ACCEPT 1 body 12 USER-ID of the user to whom this ACCEPT is issued 5 body Figure B-9: ST-1=>ST-A (ST.DG): ACCEPTing your CONNECT.

62 Protocol=ST=5 ST-version Length of ST-header (words) 7 hdr 1 Total Length in octets 44. hdr 2 ST-header checksum hdr 3 The conference CID 777 hdr CONF+STRM : 0 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 14. hdr 5 0 : 0 : 0 : 0 : 0 FBML = 0 USER-ID of the sender 5 hdr +-#1+-#2+-#3+-#4+-me : 0 : 0 : 1 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 hdr 7 SEQUENCE-NUMBER TIME=STAMP, in vocoder frames body 8 Header Check sum Token Length (Words) 0 body 9 Vocoder Data word 1 body 10 Vocoder Data word 2 body 11 Vocoder Data word 3 body 12 Vocoder Data word 4 body 13 Vocoder Data word 5 body 14 Vocoder Data word 6 body 15 Vocoder Data word 7 body 16 Vocoder Data word 8 body 17 Vocoder Data word 9 body 18 Vocoder Data word 10 body 19 Vocoder Data word 11 body 20 Vocoder Data word 12 body 21 Vocoder Data word 13 body Figure B-10: ST-5=>Ga (ST.ST): Speech data for #1+#4.

63 Protocol=ST=5 ST-version Length of ST-header (words) 7 hdr 1 Total Length in octets 44. hdr 2 ST-header checksum hdr 3 The conference CID 777 hdr CONF+STRM : 0 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 14. hdr 5 0 : 0 : 0 : 0 : 0 FBML = 0 USER-ID of the sender 5 hdr +-#1+-#2+-#3+-#4+-me : 1 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 hdr 7 SEQUENCE-NUMBER TIME=STAMP, in vocoder frames body 8 Header Check sum Token Length (Words) 0 bdy1 9 Vocoder Data word 1 body 10 Vocoder Data word 2 body 11 Vocoder Data word 3 body 12 Vocoder Data word 4 body 13 Vocoder Data word 5 body 14 Vocoder Data word 6 body 15 Vocoder Data word 7 body 16 Vocoder Data word 8 body 17 Vocoder Data word 9 body 18 Vocoder Data word 10 body 19 Vocoder Data word 11 body 20 Vocoder Data word 12 body 21 Vocoder Data word 13 body Figure B-11: ST-5=>Gb (ST.ST): Speech data for #2.

64 IP-version 4 IHL=5 (32bit) Type Of Service IP 1 Total IP-message Length, in octets 44. IP 2 IP-message IDentification IP 3 0 : 0 : 0 Fragment Offset IP 4 Time To Live Protocol = ST = 5 IP 5 IP Header Checksum IP 6 IP +--- IP-address of the Sender (Aaddr) IP 8 IP +--- IP-address of the Receiver (ACaddr) IP 10 Protocol=IP.ST=1 ST-version Length in octets 26. ST 11 ST +--- Sender extension (Ax) ST 13 ST +--- Receiver extension (ACx=122) ST 15 Token Checksum NVP 16 Token = CONNECTION-ID 35. Token Data.Length (words) 1 NVP 17 The conference CID 777 NVP Token = USER-IS-OUT 41. Token Data.Length (words) 1 NVP My U S E R - I D 5 NVP Token = B Y E 2 Token Data.Length (words) 1 NVP 21 R E A S O N = normal termination 1 NVP Figure B-12: NVP-A=>AC (IP.ST/NVP): OUT + BYE.

65 Protocol=ST=5 ST-version Length of ST-header (words) 7 hdr 1 Total Length in octets 28. hdr 2 ST-header checksum hdr 3 The conference CID 777 hdr CONF+STRM : 0 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 7 hdr 5 0 : 0 : 0 : 0 : 0 FBML = 0 USER-ID of the sender 5 hdr +-#1+-#2+-#3+-#4+-me : 0 : 0 : 1 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 : 0 hdr 7 SEQUENCE-NUMBER TIME=STAMP, in vocoder frames body 8 Header Check sum Token Length (Words) 5 body 9 Token Checksum body 10 Token = USER-IS-OUT 41. Token Data.Length (words) 1 body My U S E R - I D 5 body Token = B Y E 2 Token Data.Length (words) 1 body 13 R E A S O N = normal termination 1 body Figure B-13: ST-5=>Ga (ST.ST): OUT+BYE for #1+#4.

66 Protocol=ST=5 ST-version Length of ST-header (words) 5 hdr 1 Total Length in octets 26. hdr 2 ST-header checksum hdr 3 CID = 0 (a well known connection) hdr +PTP+DGM : 1 : 0 : 0 : 0 : 0 : 0 : 0 Body Length.Data (words) 8 hdr 5 ST-OP-CODE=DISCONNECT.CONF 12. Length (words) 8 body 6 Checksum of this body body 7 body +--- IP-Address of Sender (Baddr) body 9 My hop/hop reference 452 body 10 The conference CID 777 body 11 USER-ID of the user who issues this DISCONNECT 5 body 12 USER-ID of the user to whom this DISCONNECT is issued 1 body Figure B-14: ST-A=>Ga (ST.DG): CONNECT to #1.

67 63 (C) SAMPLE SCENARIOS PTP communication between A and B, originated by A. The TERMINATOR tokens are not shown here. Numbers which are arbitrarily chosen have always (here) 3 digits. <1> PTP A: CONC-ID<Aaddr,Ax,772>, VOCODER<lpcm>, I-AM-READY, PLS-ECHO<700> B: CONC-ID<Aaddr,Ax,772>, I-AM-RINGING, ECHO-REPLY<700> A opens a FDX-ST-data connection, which B accepts. A: CONC-ID<Aaddr,Ax,772> B: CONC-ID<Aaddr,Ax,772>, I-AM-RINGING B: CONC-ID<Aaddr,Ax,772>, I-AM-READY The speech exchange starts now. It is very likely that A and B can talk now to each other. However, B may discover only now that A is the wrong person or that he speaks only Greek. A: CONC-ID<Aaddr,Ax,772>, BYE<REASON = 1, everything said> A issues a DISCONNECT to ST. B: CONC-ID<Aaddr,Ax,772>, BYE<REASON = 0, meaning: none> B issues a REFUSE to ST. <2> PTP A: CONC-ID<Aaddr,Ax,773>, VOCODER<lpcm>, I-AM-READY, PLS-ECHO<701> B: CONC-ID<Aaddr,Ax,773>, ECHO-REPLY<701>, BYE<Reason=No Authorization>, TEXT<"AUTHORIZATION REQUIRED"> A: CONC-ID<Aaddr,Ax,773>, BYE<REASON=0, none> No data connection is opened

68 64 <3> PTP A: CONC-ID<Aaddr,Ax,774>, VOCODER<lpcm>, I-AM-READY, PLS-ECHO<702> B: CONC-ID<Aaddr,Ax,774>, ECHO-REPLY<702>, BYE<Reason=Incompatibility>, VOCODER<cvpd> A: CONC-ID<Aaddr,Ax,775>, VOCODER<cvsd>, I-AM-READY, PLS-ECHO<703> B: CONC-ID<Aaddr,Ax,775>, ECHO-REPLY<703>, ALT-ADDR<B >, NICKNAME<"Bob">, I-AM-RINGING A opens FDX-ST-data connection, which B accepts. A: CONC-ID<Aaddr,Ax,775> B: CONC-ID<Aaddr,Ax,775>, I-AM-RINGING B: CONC-ID<Aaddr,Ax,775>, I-AM-READY The speech exchange starts now. It is very likely that A and B can happily talk now. However, B may discover only now that A speaks only Greek. B: CONC-ID<Aaddr,Ax,775>, BYE<REASON = 1, everything said> B issues a REFUSE to ST A: CONC-ID<Aaddr,Ax,775>, BYE<REASON = 1, normal termination> A issues a DISCONNECT to ST <4> PTP A: CONC-ID<Aaddr,Ax,444>, VOCODER<variable CVSD,8,32>, PRECEDENCE<7>, I-AM-READY, PLS-ECHO<666> B: CONC-ID<Aaddr,Ax,444>, I-AM-READY, ECHO-REPLY<666>, TEXT<"This is a recording device"> Since B is a recording device, no RINGING is necessary. A opens an ST FDX-connection to B A: CONC-ID<Aaddr,Ax,444>, BYE<REASON = 1, everything said> A issues a DISCONNECT to ST B: CONC-ID<Aaddr,Ax,444>, BYE<REASON = 1, everything said> B issues a REFUSE to ST.

69 65 In all the above scenarios ST-FDX-data connections were opened by the initiating participants. This occurs by the CM of A asking the local ST to open a ST.ST FDX data connection to B. This request carries the connection parameters such as precedence, delay, bandwidth and the like. The local ST acknowledges to the CM the reception of this request, and turns around to the next ST module (in a gateway, for example) and asks to open the requested connection. This ST modules also acknowledges the reception of the requests and forwards it in the general direction toward the destination. Finally this request is received by the destination CM which accepts it (hopefully), and notifies the "last" ST module that it is accepted. The acceptance is propagated backward until it finally reaches the originating CM through all the ST modules which are involved. If any ST module along the way cannot handle the request (for lack of bandwidth, for example) it propagates this problem backward. An "earlier" ST module may try an alternate route for accommodating this request. If the destination cannot handle the request it issues the refusal message and no ST module ever tries an alternate route. More details about this process may be found in the ST document [Jim Forgie s IEN-119].

70 66 (D) MORE NVP-II/ST SCENARIOS The following is a description of a sample scenario discussion NVP-II communication between several users in several remote sites, communicating by using NVP-II over several packet switching networks. This description has to be considered as a continuation of the documentation of both ST and NVP-II. Suppose that the participating sites, in alphabetic order, are: BBN Ft. CABER ISI LL SRI being connected only to the ARPANet; being connected only to the ARPANet, using the CABERNet as a local net; being connected to both the ARPANet and the WBCNet, using the STN for local connections; being connected to both the ARPANet and the WBCNet, using the LEXNET as a local network; being connected to both the ARPANet and the WBCNet, using the PRNet as a local network. More about these participants is given below, on the following map. Let the participants in each site be identified by Xi where X is the first letter of the site name. The participants are: At SRI all the participants are on the PRNet, which is connected to both the WBCNet and the ARPANet via two different gateways. The gateway to the ARPANet is called PAG for PRNet-ARPANet-Gateway, and the gateway to the WBCNet is called PWG. Both of these gateways have ST modules implemented in them. Each participant has his own NVP and ST inside his terminal. Each participant is identified by a unique PRNet-address, hence by a unique IP-address, Si. ISI has no gateway. However, the ISI machine is a host on both the WBCNet and the ARPANet. Therefore it has two distinct IP-addresses, IA and IW. All the participants at ISI have the same IPaddress(es) but they have different EXTENSION numbers. Hence the (two) addresses of the ISI participants are IAXi or IWXi. All these connections at ISI are connected directly to the ISI host, either by direct lines or by the Switched Telephone Network (STN). All these participants share the same NVP and the same ST. At Lincoln Laboratory there is a 3-way gateway connecting the LEXNET to both the WBCNet and the ARPANet. Each of the participants there has a unique LEXNET address, hence a unique IP-address, Li. Each participant has both NVP and ST in his terminal. In addition, the Lincoln gateway, LG, has an ST module in it. At BBN there is only one participant with NVP and ST, connected only to the ARPANet. His IP-address is derived from his ARPANet address.

71 67 At Ft. Caber, California, there is a local net, the CABERNet, which is connected via a gateway (CAG) to the ARPANet. All the users there, like in Lincoln are connected via the local net. However, some of the hosts on this network may have more than one extension. We denote by CkXj the jth extension on the CABERNet host Ck. Each of the CABERNet hosts has both NVP and ST modules. The CABERNet- ARPANet-gateway, CAG, also has an ST module. The access controller of conferences (AC) is implemented as a process at Lincoln on the same machine which is the 3-way gateway.

72 B1 LPC(fps) NVP ST IMP ---O (BBN 11/40) <--ARPANet LG: L/W/A g way (11/44) HAP PSAT --O L1 AC --- LNET ST IMP ---O Li* VT NVP ST LNET <--LEXNet Li* STN PCM NVP ST LNET PWG PR ST HAP PSAT --O (SRI PNVTs) <--PRNet PR/WBC g way Si* LPC(chi) NVP ST PR --+ PAG WBCNet--> +-- PR ST IMP ---O PR/AN g way IG: ISI s W/A g way (11/45) (11/44)+----+IW HAP PSAT --O IX1 LPC(fps) NVP ST ST IA IMP ---O IXi* STN PCM NVP ST PCM or CVSD <-ARPANet AN/CB g way CAG: CBNET ST IMP ---O Ci* LPC NVP ST CBNET -O <--CABERNet Ck* NVP ST CBNET -O CkXj* LPC -O +---+

73 69 Following are some sample scenarios: D.1. A PTP call <1> a PTP call from Sam (S2) on the PRNet to Lynn (L3) on the LEXNET. NVP-S2 sends an initial call message to NVP-L3. Since no ST connection exists yet the message is sent by IP.ST. This happens by ST using the the standard IP protocol. Since the ST protocol introduces an extension field, this message is addressed to L3-X1 from S2-X1. L3 is the address of the "callee" on the LEXNET, hence it is his IP-address. This message is: To: From: Msg: L3-X1 S2-X1 CONC-ID<S2,X1,111>, I-AM-READY, NICKNAME<me,"Sam Shaw">, VOCODER<cvsd> ST-S2 recognizes that this message is addressed outside of the PRNet, hence it forwards it to either gateway, say the PAG. No one has to remember anything about this message. <1.1> Upon receiving this message NVP-L3 notices that it cannot handle CVSD and sends back, via IP.ST, the following datagram: To: From: Msg: S2-X1 L3-X1 CONC-ID<S2,X1,111>, BYE<REASON = incompatibility> S2, lacking any other vocoders, gives up and figures an alternate strategy for communicating with L3. <1.2> Upon receiving this message NVP-L3 notices that it can handle CVSD and that it is OK to communicate with S2. It rings a bell and displays a short message saying "Sam Shaw is on the line". In addition it sends the following datagram to S2: To: From: Msg: S2-X1 L3-X1 CONC-ID<S2,X1,111>, I-AM-RINGING every couple of seconds S2 repeats the datagram: To: From: Msg: L3-X1 S2-X1 CONC-ID<S2,X1,111>, I-AM-READY and L3 repeats the RINGING message. This exchange continues until

74 70 <1.2.1> Sam gives up, causing S2 to cease sending the READY messages which will in turn make L3 stop ringing after a short timeout period, OR <1.2.2> Lynn picks up the handset. At that point L3 sends: To: From: Msg: S2-X1 L3-X1 CONC-ID<S2,X1,111>, I-AM-READY, NICKNAME<me,"Lynn Lear"> Now NVP-S2 tries to open a FDX-ST-connection to NVP-L3. NVP-S2 asks ST-S2 to open this connection for a (say) 16Kbps data. ST-S2 assigns a CID for this connection, and asks ST-PWG to accept it. ST-PWG returns an ACK to ST-S2 and opens an ST connection to ST-LG through the WBCNet, with the same parameters and probably different CIDs. ST-LG ACKs this request back to ST-PWG, and forwards the request for connection to the destination ST, which is ST-L3. Upon consulting with NVP-L3 the requested connection is granted. ST-L3 tells ST-LG about it. ST-LG tells ST-PWG which tells ST-S2 which finally tells the originating NVP-S2 that the connection is accepted and successfully open. Now L3-X1 and S2-X1 can exchange speech data. During the life of this connection the following ST modules actively participate in the communication: ST-S2, ST-PWG, ST-LG and ST-L3. Each has to remember the CIDs of the connections, the anticipated rate, and the like. If at any time during the connection the availability of communication capacity (e.g., bandwidth) drops below the requested capabilities the STs either take the connection down and send REFUSE/DISCONNECT to both S2 and L3 by way of all the participating STs, or switch to a lower rate if so specified in the FLOW-SPEC. D.2. Another PTP call <2> a PTP call from Lynn (L3) on the LEXNET to Ike (IW-X4) at ISI. As noticed on the map ISI does not have a local network and does not have a gateway. Since ISI is connected to both the WBCNet and to the ARPANet it has two distinct addresses, IW on the WBCNet side and IA on the ARPANet side. Since the WBCNet is the better way to communicate speech IW is the preferred address. Hence when L3-X1 initiates the call the first message which is sent is:

75 71 To: From: Msg: IW-X4 L3-X1 CONC-ID<L3,X1,222>, I-AM-READY, VOCODER<lpc>, NICKNAME<me,"Lynn Lear"> This message travels as a datagram over the WBCNet. Upon arrival, NVP-ISI makes sure that X4 indeed has an LPC vocoder, that there are no authorization problems, no higher precedence call is in progress and so on. After approving the communication NVP-ISI rings X4 and returns a datagram to L3-X1. However, ST-ISI, being not unintelligent, probably sends this datagram to L3 over the ARPANet. Even though NVP-ISI anticipates this route it "signs" the return message as coming from "IW" in spite of the possibility that it is actually being transmitted by IA. To: From: Msg: L3-X1 IW-X4 CONC-ID<L3,X1,222>, I-AM-RINGING Note that this is similar to the use of the "FROM:" field of ARPANet messages which is not necessarily the same as the "SENDER:" field. Later, when the call is answered by Ike, the following message is sent, probably over the ARPANet, again To: From: Msg: L3-X1 IW-X4 CONC-ID<L3,X1,222>, I-AM-READY, NICKNAME<me,"Ike Ibe">, ALT-ADDR<me,IA-X4> If NVP-L3 is as smart as NVP-ISI gives it credit for, this "dual homing" information is stored and is used for reconnection, if ever found necessary. Suppose that sometime later WESTAR gets into some trouble maybe an encounter with some part of SKYLAB or just a simple channel pre-emption by a higher precedence call. ST-ISI discovers a lost connection to ST-L3 and tries to re-route via the ARPANet, which luckily for this example is capable of supporting the low rate required by the particular dialect of LPC which is used here. However, ST-L3 cannot use a similar simple re-routing strategy since it believes that IW is the target, and IW is not accessible in any way. Upon reporting this connection failure to NVP-L3 the solution may be found. Somewhere in its memory L3 discovers that IA-X4 is an alternate address to Ike, and asks ST-L3 to try this connection, which hopefully succeeds. The entire re-connection issue has to be discussed further. NVP, may support reconnection even though ST may not have this notion at all.