A Network Voice Protocol NVP-II

ISI / RR-81-90 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 90292 Lincoln Laboratory Massachusetts Institute of Technology 244 Wood Street Lexington, MA 02420-9108 April 1st, 1981

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.

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

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

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.

2 (A) GENERAL NVP-II is designed to be an improved version of the first NVP which has been operational since 1974. 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).

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.

4 +--------------+ NVP-2 +-+----------+-+ +-+----+ (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.

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.

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.

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.

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>

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.

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.

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.

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.

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.

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.

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=9+1-617-862-5500" 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.

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.