A Network Voice Protocol NVP-II
|
|
- Prudence Hicks
- 8 years ago
- Views:
Transcription
1 ISI / RR A Network Voice Protocol NVP-II by Danny Cohen Stephen Casner James W. Forgie U S C / I S I 4676 Admiralty Way Marina del Rey, California Lincoln Laboratory Massachusetts Institute of Technology 244 Wood Street Lexington, MA April 1st, 1981
2 N V P - II NVP-II was born after a very long pregnancy. Longer than elephants. It was born out of an uncountable number of discussions (and even rare arguments) between the NVP-II staff of ISI, Lincoln Laboratory and SRI (in alphabetic order). Many proposals were made in several papers, in various presentations and in many discussions. We feel that all of these efforts contributed to the ideas and the shape of this protocol. All these participants deserve a share in any credit ever given to this protocol. All the blame should be directed to me for not listening, not understanding or not recognizing better ideas when they were presented. I hope the pregnancy is over, and that the newborn is not a dinosaur. The intent of this document is to provide a complete specification of some self-contained and extensible protocol. Therefore an effort was made to provide a set of primitives which allow the beginning of implementations which would have the capability to be expanded later to support future requirements. We expect this specification to be somewhere above the minimum set which is required for a reasonable operation under the expected conditions. If this is not so every effort must be made as soon as possible, to mend this situation. On the other hand, we are sure that this specification is well below the maximum set which may be required for ALL the problems and ALL the conditions which we are capable of imagining. NVP-II does not intend to solve all the problems associated with packet voice communication, point-topoint (PTP) or conferencing. It is designed to supply tools which may be used for solving a large class of problems in this area, with the hope that most of the interesting problems in this area are in this class. NVP-II intends to provide a quick and efficient method for establishing the routine transactions with an escape mechanism for performing more complicated and less frequent transactions.
3 i Table of Contents (A) GENERAL 2 (B) THE MODEL 3 (C) THE CONFERENCE MODEL 5 (D) CONTROL MESSAGES 7 (E) THE CONTROL TOKENS 8 (F) DEFINITION OF THE CONTROL TOKENS 9 (G) DEFINITION OF THE CONTROL TOKENS, FOR CONFERENCING 16 (H) THE NVP-II DATA PROTOCOL 21 (I) APPENDIX 23 I.1. CHARACTER PARITY 23 I.2. CHARACTER ORDER IN STRINGS 23 (A) AN ANNOTATED EXAMPLE FOR PTP COMMUNICATION 27 (B) AN ANNOTATED EXAMPLE FOR CONFERENCE COMMUNICATION 43 (C) SAMPLE SCENARIOS 63 (D) MORE NVP-II/ST SCENARIOS 66 D.1. A PTP call 69 D.2. Another PTP call 70
4 ii List of Figures Figure A-1: NVP-A=>NVP-B (IP.ST/NVP): An initial call. 31 Figure A-2: NVP-B=>NVP-A (IP.ST/NVP): Accepting the call. 33 Figure A-3: ST-A=>ST-B (ST.DG): a CONNECT message. 34 Figure A-4: ST-X=>ST-A (ST.DG): An ACK message to ST-A. 35 Figure A-5: ST-B=>ST-A (ST.DG): An ACCEPT message. 36 Figure A-6: NVP-A=>NVP-B (IP.ST/NVP): Please keep ringing. 37 Figure A-7: NVP-B=>NVP-A (IP.ST/NVP): We keep ringing. 38 Figure A-8: NVP-B=>NVP-A (IP.ST/NVP): Ready For data. 39 Figure A-9: ST-A=>ST-B (ST.ST): Data, (note the aggregation). 40 Figure A-10: NVP-B=>NVP-A (ST.DG): Normal call termination. 41 Figure A-11: ST-B=>ST-A (ST.DG): a REFUSE message. 41 Figure A-12: ST-A=>ST-B (ST.DG): a DISCONNECT message. 42 Figure B-1: NVP-A=>AC (IP.ST/NVP): I want to join a conference. 47 Figure B-2: AC=>NVP-A (IP.ST/NVP): You are accepted. 49 Figure B-3: ST-A=>AC (IP.ST/ST): Asking about #1+#2+#4. 50 Figure B-4: AC=>ST-A (IP.ST/ST): Info about #1+#2+#4. 53 Figure B-5: ST-A=>Ga (ST.DG): CONNECT to #1. 54 Figure B-6: ST-A=>Gb (ST.DG): CONNECT to #2. 55 Figure B-7: Ga=>ST-A (ST.DG): ACK of the CONNECT to #1. 56 Figure B-8: Gb=>ST-A (ST.DG): ACK of the CONNECT to #2. 56 Figure B-9: ST-1=>ST-A (ST.DG): ACCEPTing your CONNECT. 57 Figure B-10: ST-5=>Ga (ST.ST): Speech data for #1+#4. 58 Figure B-11: ST-5=>Gb (ST.ST): Speech data for #2. 59 Figure B-12: NVP-A=>AC (IP.ST/NVP): OUT + BYE. 60 Figure B-13: ST-5=>Ga (ST.ST): OUT+BYE for #1+#4. 61 Figure B-14: ST-A=>Ga (ST.DG): CONNECT to #1. 62
5 1 N O T E This document is based on ST. It does not specify the NVP/ST interface. The interface between ST and NVP is considered to be a "local implementation issue" which may be implemented in various ways at different sites without affecting the total system inter operability. It is possible to have a relatively "smarter" ST with a simpler NVP on top of it, or a simpler ST and a smarter NVP. In order to understand the proposed NVP and ST it is recommended to read the following documents: The ST document by Jim Forgie (IEN 119 and subsequent revisions). The NVP document (this one). Sample ST/NVP scenarios (included in this document). The user interface is also considered a "local implementation issue". The user voice terminal may range from "dumb" as in a dial telephone to as "intelligent" as one might wish to design. For example NVP II can communicate that a terminal is ringing, but it is beyond the scope of the protocol as to how ringing is implemented or how ringing is indicated on the calling terminal. Throughout this document: WORD means a 16 bit word; BYTE means an 8 bit byte; FIRST means "in the most significant position"; Numbers are decimal.
6 2 (A) GENERAL NVP-II is designed to be an improved version of the first NVP which has been operational since Its main improvements over NVP-I are in the following areas: Operation in the ARPA internetwork environment. Improved conference facilities. Providing the "handles" which are necessary in order to achieve high efficiency of intermediate networks and utilization of special features like stream-setup, when necessary, and broadcasting. More flexible control to allow future extensions like the support of multi-media communication. NVP-II, like NVP-I, is divided into a Control Protocol (CP) and Voice Data Protocol (VP). The control protocol is the main topic of this document. The module which implements the control protocol is called the CM. Its main objectives are (i) establishing and monitoring the communication paths, and (ii) supporting a convenient user interface. The control functions are performed by exchanging "control- instructions" between the participating CMs. These instructions are referred to as control-tokens. The voice data protocol is basically as defined for NVP-I, and is not expected to be intrinsically changed. As a matter of fact, all the forthcoming acoustic improvements of any algorithm (e.g., LPC and CVSD) should apply equally to both protocols. However, NVP-II packages the voice-data in a different way than NVP-I does. NVP-II, unlike NVP-I, is symmetric in the sense that in a two-party call, the distinction between the CALLER and the CALLEE does not exist, and in conference there is no information regarding whether a participant called the conference or vice versa. On the other hand, the supporting communication protocol, ST, is based on asymmetric full-duplex connections with the notion of "direction" (i.e., CALLER and CALLEE) which is maintained throughout the entire life of the connection. NVP-II supports two main communication modes: (i) Point-to-Point (PTP) full-duplex, two-party communication, and (ii) Multi-Destination "Half-Duplex" (MDHD) communication (conference).
7 3 (B) THE MODEL NVP-II supports communication between users, where each user is a process with some capabilities somewhere in the internetwork environment, capable of using both IP datagrams and the internet stream protocol (ST) [FORGIE]. A user is defined by a 32-bit internetwork address and an extension designator. In addition, a user may also have a "NICKNAME" represented by a string of ASCII characters, oriented for human consumption. The format of the IP-address is specified in the IP-4 document [POSTEL], and the format of the extension designator and the NICKNAME are specified in this document. The user s address, which consists both of the IP-address and the extension designator (and sometimes also a dialing sequence) is expected to be associated with the particular voice-terminal ("telephone"), whereas the nickname is associated with the current user, which is typically a particular person, like "EARL CRAIGHILL", or a function like "BOOKKEEPING". Ideally all these nicknames are globally unique, hence they are names. It is expected that in some implementations there will be many IP-addresses with only a few extensions, whereas in other IP-addresses there will be many extensions. The communication tool used by NVP-II is ST, which is used in one of three main modes: IP.ST which is single-destination datagrams without (probably: before) establishing an ST-connection, ST.DG which is single- destination datagrams using an existing ST-connection and ST.ST which is multi-destination streams. Here "multi" means one or more. Being a user of ST, NVP-II has the responsibility to manage the proper use of the resources offered by ST. IP.ST is IP-datagrams in the ST protocol format. ST messages are designated by an IP version number of five. ST.DG and ST.ST messages are distinguished by a Datagram/Stream bit. Before establishing an ST-connection, only control information may be communicated. This is done by the IP.ST mechanism. After establishing the ST-connection, data (with or without control) is communicated by the ST.ST mechanism, but control with no data may also be communicated by the ST.DG mechanism. For more details please refer to the example in the "Sample NVP/ST Scenarios" documents and to the ST document [FORGIE]. In case of any difference of parameter preferences between participants NVP-I had the notion that the negotiation master (which is the CALLEE by default unless otherwise was negotiated) has always the last word and is therefore responsible to terminate the negotiation phase. NVP-II with its symmetric approach does not have this notion. Negotiation (shall we call them "arguments"?) may be trivially short and terminate when either of the parties offers an acceptable solution, or loop for ever if both implementations are equally stubborn (and dumb). As a matter of fact not only dumb-stubbornness may cause infinite loops so may dumb-politeness. Suppose that both A and B may use either options V1 and V2, and that each has a different preference. Suppose further that at the same time (up to communication propagation delays) A suggests V1 and B suggests V2. A while later A would politely accept B s proposal and offer V2, just when B offers V1, a while later A offers V1 and B offers V2... NVP-II does not specify how this possible loop terminates. In any case it is recommended that implementations limit the length of this negotiation phase. It is encouraged that NVP-II implementations allow a cut-off user to reconnect without necessarily advising the other parties to this incident if it was trivially short.
8 NVP (IP.IP) ST / (IP.ST) / <- IP Version = 5 = ST IP (ST.DG) If Datagram/Stream Bit = 1 IP Version = 4 -> (ST.ST) If Datagram/Stream Bit = 0 (IP Datagrams) Local Net Protocol If when A believes he is in communication with B, a message arrives from B requesting to establish a connection, A would reconnect to this new communication. The new B is recognized to be the same as the old one by having the same address (IP-address plus extension) and the same nickname or having only the same non-null nickname (but different IP-address and extension) provided that the old address is not "alive" any longer. If A calls B when B calls A simultaneously then "by definition" both parties seem to be BUSY, just like in the telephone systems. It is hoped the randomness which is part of human behavior would help in keeping this situation from looping forever.
9 5 (C) THE CONFERENCE MODEL Following are some of the many issues which have to be addressed in the discussion of conferencing. * What is the model of a conference? Which roles are played in it? How tight/loose is its control? What is its access scheme? Etc. * Is a conference always chaired? If so - how? By whom? * What is the extent of the parameters negotiation? When is it performed? By whom? * What is the status of a conference? Who knows it? How can one inquire about it? In our module a conference has the following kinds of players: Initiator Access Controller (AC) Floor Controller (FC) and Scheduler Participants Each conference has a unique ID. It is the Access Controller s role to control the participants set, the Floor Controller s role is to sequence the speakers properly. The Initiator is the process who informs the AC about the conference, its starting time, its ID, its access scheme and the like. The access scheme may be a restricted participants list, anyone who knows the password, anyone who is approved online by some process (probably with a person in the loop), anyone who wants to, etc. The Access Controller (AC) is the process responsible for controlling the participation in the conference by approving or disapproving requests from participants to join a conference. The AC also assign globally unique CIDs (Connection-ID numbers) which are very important for efficient operation in networks with broadcasting capabilities. The Floor Controller (FC) arbitrates (schedules) the "use of the floor", i.e., who talks when. This function is defined here communication-wise only. It is quite conceivable that the FC and the person who "chairs" the conference are different. Conceivable, but not necessarily recommended.
10 6 Conferences may be performed in many styles (regimes) which vary from free-style (free-floor) to a tightly controlled conference. The algorithm to determine who speaks when is the SCHEDULER of the conference, and the mechanism to enforce it is the FC of the conference. Note that both the scheduler and the FC may involve people in the loop or may be fully automated, they may be centralized, distributed or duplicated. For all practical purposes the scheduler may be considered as an integral part of the FC. NVP-I and NVCP supported only a tightly controlled conferencing regime with a centralized scheduler and chairman (FC) which were usually implemented as automatic programs with a manual override. NVP-II does not restrict the style of conferences. It treats the style as one of the configuration parameters of a conference. The first style which is supported by NVP-II is the free-style one. The control tokens needed for supporting it are defined in this document. It is expected that additional styles will be added to NVP-II in the near future. By design a 2-party conversation (PTP) is a full duplex communication which cannot be expanded to include additional participants. Also, a conference with 2 participants only is not equivalent to the PTP conversation. PTP communication requires a simpler mechanism than conferences do. Since most PTP calls do not evolve to conferences we argue that it is better to take advantage of the simplicity which exists in the PTP case for efficiency reasons. It is assumed that conferences are arranged prior to their beginning. These arrangements include the notification of some people that they are expected to participate in a certain conference, at a certain time, using a certain language and a certain vocoder, to discuss a certain subject, under a certain conferencing style, etc. It is not expected that these arrangements are made within the conference. We believe once the conference starts it is too late to make these pre-arrangements. Therefore, no provisions are made within the conference framework to made such pre-arrangements.
11 7 (D) CONTROL MESSAGES Control tokens are preceded by a 16 bit checksum. The checksum value is computed according to the scheme of computing the checksum for ST, as defined in the ST-document [FORGIE]. Each of the NVP-II control tokens (instructions) consists of (up to) 3 fields, the first is an "op-code" byte, followed by a Data.Length (N) byte followed by N data words. N obviously may vary between 0 and 255. The op-code and the Data.Length are packed in a single word, with the op-code in the first (most significant) byte. Hence, a single zero word is a token complying with this format specification, having zero op-code and no data. Several control tokens may be packed (aggregated) together. It is possible to communicate these control tokens in several ways (e.g., by IP.ST, by ST-datagrams or with ST-data-streams). Once these control tokens arrive the destination is required to treat them in the same way, regardless of the scheme used for communicating them. In particular, when acting upon a control token which requests a response it is not expected that the same transport mechanism which was used by the sender of the request is necessarily used by the answerer. The receiving Control Module (CM) is expected to process these tokens in the same order in which they are communicated, i.e., first token first. It is always expected that control tokens which are not understood are discarded by the receiver. The meaning of the data fields in these tokens depends on the "op-code", obviously. Some op-code may have alphanumeric character strings as their data. Each character is represented by 7-bit ASCII code, right justified in an 8-bit byte, the high-order bit of the byte is zero. A null character (ASCII 0) is always appended at the end of a string. If then the number of these characters is odd, another null character is appended at the end of the string, as a filler. Note that the number of characters is 2N, including the filler(s). Hence, the null string is represented by a single zero word. In each word used for sending strings the character which is in the most significant byte precedes the one which is in the least significant byte. Hence, "ABC" is sent as "AB", "C-null", and "ABCD" as "AB", "CD", "null-null" (where "null-null" is a zero word). Please note the discussions on characters-parity and on the order of characters in string, which are in the Appendix. Using the terminology of "On Holy Wars" Big-Endians style is used. The exact format of the control messages, their headers, checksums and the like is specified later in this document. Please note again that the value of Data.Length in NVP is defined not to include the Data.Length field, unlike the notion of LENGTH in ST and IP, which includes itself.
12 8 (E) THE CONTROL TOKENS [ 0] UNUSED AT THIS TIME [ 1] [I-AM-READY] [ 2] [BYE] <REASON> [ 3] [I-AM-RINGING] [ 4] [VOCODING] <VOCODER-CODE> [ 5] [PRECEDENCE] <VALUE> [ 6] [PLEASE-ECHO] <REFERENCE> [ 7] [ECHO-REPLY] <REFERENCE> [ 8] [CONNECTION-NAME] <NAME> [16] [TELL-ABOUT-USER] <USER-ID> <USER-ID>...<USER-ID> [17] [USER-ADDRESS] <USER-ID> <IP-ADDRESS> <EXTENSION> [18] [ALTERNATIVE-ADDRESS] <USER-ID> <IP-ADDRESS> <EXTENSION> [19] [NICKNAME] <USER-ID> <NICKNAME> [20] [ARBITRARY-TEXT] <STRING> [21] [ARBITRARY-CODE] <VALUE> <VALUE>... <VALUE> [22] [WHAT-ARE-YOUR-CAPABILITIES?] [23] [PLEASE-SEND-YOUR-COMMUNICATION-STATISTICS] [24] [HERE-IS-MY-STATISTICS] <DATA> [25] [PLEASE-DIAL] <DIALING SEQUENCE> [32] [PLEASE-JOIN-A-CONFERENCE] [33] [I-WANT-TO-JOIN-THE-CONFERENCE] [34] [CONFERENCE-ID] <CONF-ID> [35] [CONFERENCE-CONNECTION-NAME] <CID> [36] [CONFERENCE-PASSWORD] <PW> [37] [CONFERENCE-ACCESS] <INFO-FOR-AC> [38] [CONFERENCE-STYLE] <STYLE> [39] [CONFERENCE-BIT-MAP] <USER-ID> <NP> <BM> [40] [PLEASE-GIVE-ME-THE-CONFERENCE-STATUS] [41] [USER-IS-OUT] <USER-ID> [48] [I-AM-TALKING-NOW] [49] [I-AM-DONE] [50] [NET-MEASUREMENT-TIMESTAMP] <VALUE> <HOST> <EXT>
13 9 (F) DEFINITION OF THE CONTROL TOKENS The control messages are composed of control tokens. The grouping of tokens into messages is not explicitly defined herein. Applications should group tokens into messages in such a way that the information which is required by receiver, at that state, is available. The exact format of many parameters is not defined yet. All the formats will be specified together with the format of message headers, checksums and the like. >>> [1] = [I-AM-READY] This token expresses that the CM is happy, believing that there are neither communication nor compatibility problems, and is ready to receive speech data. It implies that the handset (or equivalent) is online (aka "offhook"), and that some person is ready to hear the the speech data, or that a recording device is ready to accept the data to be recorded after going through all the file specification and access steps, as needed. For symmetry this token should also be sent by the call initiator. >>> [2] = [BYE] <REASON> This token expresses the inability to communicate. It may mean anything from a slight compatibility problem to a total rejection due to being engaged in another communication (aka BUSY) or lack of access rights. It is considered polite to (i) send this token rather than ignoring completely the calling party, and (ii) to provide a reason code. The following reason codes are defined herein: 0 = Other than the following. 1 = Normal call termination. We hang up. Have a nice day! 2 = I am engaged now, please try later (BUSY). 3 = The call is not authorized (access control problem). 4 = I give up, you are probably down. 5 = Parameters incompatibility. Let s work it out (off line). 6 = I have problems on my side. Sorry about that. 7 = We don t have such an extension 8 = Incorrect address (e.g., missing dialing sequence) 9 = We don t dial this sequence. 10 = Missing a necessary parameter.
14 10 >>> [3] = [I-AM-RINGING] This token means that the sender of this token would be READY (as defined above) as soon as it is switched to the online (offhook) state. The I-AM-RINGING may be terminated if the receiver does not get any message from the sender for a certain period (say 3 seconds). >>> [4] = [VOCODING] <VOCODER-CODE> The following vocoding codes are defined herein: 1 = LPC-I (fixed rate) 2 = LPC-II (variable rate) 3 = LPCM (multiple rate) 4 = CVSD (variable rate) 5 = CVSD (multiple rate) 6 = Belgard (fixed rate) more later... DEFINITION: a variable-rate vocoder is one with rate which may be deduced from the data. This is different than a multiple-rate vocoder which may use any one of several (few) rates (e.g., 8,12,16 Kbps) according to a selection which is external to the data stream. The rate data may follow the vocoder code, if needed. Hence, for a multiple rate it may be the list of all rates, for a variable rate the minimum and the maximum, and for fixed-rate the single rate value. Note that it is not really needed to specify rate(s) for either fixed or variable rates vocoders because these rates are known in advance for each type of these vocoders. Hence, the inclusion of the rate is optional only. >>> [5] = [PRECEDENCE] <VALUE> This token is used to announce the precedence level which the sender assigns to this communication. This is not the place to discuss who is authorize to announce which level of precedence, and the range of values which this precedence may assume.
15 11 >>> [6] = [PLEASE-ECHO] <REFERENCE> This token asks the receive to echo back a response with the reference number specified in this request. This exchange of request and echo may be used either for round trip time measurement, for verifying the operability of the receiver (e.g., when talking to a recording device), for the familiar acknowledgment, for keeping the receiver ringing, and more. The echo may be interpreted as an acknowledgment that ALL the control tokens which were sent together with the request actually arrived, and no retransmission is needed to insure their arrival. It does not mean by any way a functional approval or acceptance of any of the associated requests. The <REFERENCE> is a single arbitrary word. >>> [7] = [ECHO-REPLY] <REFERENCE> This token is the response to the PLEASE-ECHO token. The <REFERENCE> here is copied from the one specified there. >>> [8] = [CONNECTION-NAME] <NAME> The purpose of this token is to provide a cross-reference identification of a PTP-connection, between ST and NVP. This token should be used whenever any ambiguity may occur, regarding the identification of the connection. The NAME is defined as the IP-address of the initiator of the call, followed by his extension, followed by the connection number. The call initiator assigns the connection number which is an arbitrary 16-bit word. Since both the IP-address and the extension fields consists of 2 words each, a NAME is a 5 words sequence. NOTE: ONLY THE ABOVE TOKENS ARE COMPULSORY FOR ANY PTP COMMUNICATION. However, for a smooth operation it is recommended that the following control tokens be implemented too.
16 12 >>> [16] = [TELL-ABOUT-USER] <USER-ID> <USER-ID>...<USER-ID> This token is used by a participant who wants to get information about some other participants in a conference. The USER-ID is typically, in a conference, the position of that user in the conference BIT-MAP (See the CONFERENCE-BIT-MAP token). However, a zero ID may be used to indicate the sender or the receiver of the token (depending on the token type). In a PTP communication the USER-ID should always be set to zero. In particular, a zero USER-ID with [TELL-ABOUT-USER], means that the receiver is asked to tell about itself. In return to this token it is expected to receive the USER-ADDRESS all the ALTERNATIVE-ADDRESS,if any, and the NICKNAME tokens which are known for this user.
17 13 >>> [17] = [USER-ADDRESS] <USER-ID> <IP-ADDRESS> <EXTENSION> This token is used for sending information about participants, either in a PTP or in a conference communication. Typically this token is sent in response to the [TELL-ABOUT-USER] token. The first word, the USER-ID, identifies the user whose address is defined in this token. When a user identifies himself, a zero USER-ID may be used, especially in a PTP communication. In conferences users are identified by their serial number in the conference bit-map, as discussed above. The <IP-address> is the 32-bit internet address. The <extension> is the 32-bit local extension. The IP-address and the extension together form the address of this user. This address is associated with the hardware station, whereas the NICKNAME is associated with a certain person. It is expected that people are more mobile than the hardware, and that the nickname of the same station may change between calls, as people move around. If this user has several addresses they are communicated by the ALTERNATIVE-ADDRESS tokens, which are repeated in a decreasing order of preference. In conference, this token may be used for communicating information about several participants, by repeating the body of the token as many times as needed. This body consists of 5 words (per user): 1 for USER-ID, 2 for IP-address and 2 for the extension. If there is no information regarding a user about which information was requested, or if that user is not active any more, this is signaled by setting the first word after the USER-ID to zero. That word is usually the first word of the IP-address which contains the NET-ID, and therefore cannot assume the zero value. Hence, a zero in that word may be used as an "escape-code" without causing any ambiguity. If no information is known about that user, the next word is set to 1. If it is known that this user is no longer an active member of the conference, that word is set to 2. The value of the following two words is ignored. >>> [18] = [ALTERNATIVE-ADDRESS] <USER-ID> <IP-ADDRESS> <EXTENSION> The purpose of this token is to provide alternate addresses which may be used to reach the same user. This is done in anticipation of network problems. If no alternative address exists, this token is never sent. If more than one exists then such a token is repeated for each address in a decreasing order of preference. The format of this token is the same as of the USER-ADDRESS.
18 14 >>> [19] = [NICKNAME] <USER-ID> <NICKNAME> This token is used for communicating a text string which is associated with the identified user. It is expected that people are more mobile than the hardware units, hence, the same hardware unit (identified by IP-address and extension) may be used by different individuals. Systems with text display capabilities are expected to benefit from this token. The first arrangement of this token, the <USER-ID>, is as defined for the USER-ADDRESS token. This is followed by a text-string which is the nickname itself. >>> [20] = [ARBITRARY-TEXT] <STRING> This token is used to communicate a character string which is only for human consumption and carries no information which the CM has to understand, hence it is called "arbitrary". CMs may display this string to the user in any of many ways. >>> [21] = [ARBITRARY-CODE] <VALUE> <VALUE>... <VALUE> This token is an escape mechanism to support either a runtime assigned values of codes which may be used for certain interrupts, voting and the like, or as a simple way to implement a "private protocol" within this framework. Each value is a single word. >>> [22] = [WHAT-ARE-YOUR-CAPABILITIES?] This is a solicitation of information about the parameters (as defined above) of another user. It is expected that in response to this token the receiver will send VOCODER, PRECEDENCE, USER- ADDRESS, NICKNAME, and maybe more parameters if they are of any consequence. This token may be answered even when the CM is BUSY. >>> [23] = [PLEASE-SEND-YOUR-COMMUNICATION-STATISTICS] This is a solicitation of communication statistics which may be useful for some flow control scheme. The format of the data will be specified later.
19 15 >>> [24] = [HERE-IS-MY-STATISTICS] <data> This is the exposition of the communication statistics. This token may be sent whenever the CM "thinks" that someone is interested to get it. It may be in response to the request for it, or not. The format of the data will be specified later. >>> [25] = [PLEASE-DIAL] <dialing sequence> This is a specification of a dialing sequence for an auto-dialer, if such a device is installed on this extension. A dialing sequence is specified to be a character string, with the digits (1 through 9 and 0) and the symbols "A", "B", "C", "D", "*" and "#" used for the DTMF (Dual Tone Multi Frequency) signals. Any other character is ignored, except "+" which means a waiting period of a few seconds, usually for the dial-tone of the next level. An example string is "LL= " which may cause an ISI phone to get first an "outside-line", wait for a dial-tone, and then call Lincoln via Ma Bell. Note that since the above string has an odd number of characters a single null character has to be appended to it.
20 16 (G) DEFINITION OF THE CONTROL TOKENS, FOR CONFERENCING All the tokens which are defined for PTP connections are valid also for conferencing. However, more control token are needed for handling the additional issues which are required for conferencing. As mentioned before it is assumed that the pre-arrangements which are necessary for a proper performance of the conference have already been made, and that the anticipated participants know when they are expected to join the conference and which vocoder to use. The process of joining a conference involves also a control communication (i.e., tokens exchange) between CMs and ACs. Some of the tokens may be transmitted only from CMs to ACs and some only from ACs to CMs. This is unlike the PTP communication where any token may be transmitted in any direction. This document does NOT specify how the AC is told by the Conference Initiator about the conference parameters, its name, style, vocoder, access, time, and the like. The conferencing tokens are defined herein: >>> [32] = [PLEASE-JOIN-A-CONFERENCE] This token is used to invite a user to join a conference. It is expected that it is followed by other tokens specifying parameters like the conference-id and other access control information. In addition it may include an arbitrary text. The fact that a certain user was invited to join the conference is not a part of any status, and bears no additional privileges to this user.
Computer Networks. Chapter 5 Transport Protocols
Computer Networks Chapter 5 Transport Protocols Transport Protocol Provides end-to-end transport Hides the network details Transport protocol or service (TS) offers: Different types of services QoS Data
More informationModule 7 Internet And Internet Protocol Suite
Module 7 Internet And Internet Protocol Suite Lesson 21 Internet and IPv4 LESSON OBJECTIVE General The lesson will discuss a popular network layer protocol, i.e. the Internet Protocol Specific The focus
More informationAppendix B RCS11 Remote Communications
Appendix B RCS11 Remote Communications B.1 Host Computer Remote Communications Control and status messages are conveyed between the RCS11 and the host computer using packetized message blocks in accordance
More informationTransport Layer Protocols
Transport Layer Protocols Version. Transport layer performs two main tasks for the application layer by using the network layer. It provides end to end communication between two applications, and implements
More informationPRODUCT MANUAL SKX OPEN SKX ADVANCE ZN1RX-SKXOPEN. Edition 2 Version 1.1
PRODUCT MANUAL SKX OPEN SKX ADVANCE ZN1RX-SKXOPEN Edition 2 Version 1.1 INDEX 1. Introduction... 3 1.1. SKX Interface... 3 1.2. SKX Installation... 5 1.3. SKX Advance: Application Program... 5 1.3.1. SKX
More information(Refer Slide Time: 02:17)
Internet Technology Prof. Indranil Sengupta Department of Computer Science and Engineering Indian Institute of Technology, Kharagpur Lecture No #06 IP Subnetting and Addressing (Not audible: (00:46)) Now,
More informationLecture 15. IP address space managed by Internet Assigned Numbers Authority (IANA)
Lecture 15 IP Address Each host and router on the Internet has an IP address, which consist of a combination of network number and host number. The combination is unique; no two machines have the same
More information(Refer Slide Time: 6:17)
Digital Video and Picture Communication Prof. S. Sengupta Department of Electronics and Communication Engineering Indian Institute of Technology, Kharagpur Lecture - 39 Video Conferencing: SIP Protocol
More informationIP - The Internet Protocol
Orientation IP - The Internet Protocol IP (Internet Protocol) is a Network Layer Protocol. IP s current version is Version 4 (IPv4). It is specified in RFC 891. TCP UDP Transport Layer ICMP IP IGMP Network
More informationNETWORK LAYER/INTERNET PROTOCOLS
CHAPTER 3 NETWORK LAYER/INTERNET PROTOCOLS You will learn about the following in this chapter: IP operation, fields and functions ICMP messages and meanings Fragmentation and reassembly of datagrams IP
More information1. The subnet must prevent additional packets from entering the congested region until those already present can be processed.
Congestion Control When one part of the subnet (e.g. one or more routers in an area) becomes overloaded, congestion results. Because routers are receiving packets faster than they can forward them, one
More informationBroadband Networks. Prof. Dr. Abhay Karandikar. Electrical Engineering Department. Indian Institute of Technology, Bombay. Lecture - 29.
Broadband Networks Prof. Dr. Abhay Karandikar Electrical Engineering Department Indian Institute of Technology, Bombay Lecture - 29 Voice over IP So, today we will discuss about voice over IP and internet
More informationCommunications and Computer Networks
SFWR 4C03: Computer Networks and Computer Security January 5-8 2004 Lecturer: Kartik Krishnan Lectures 1-3 Communications and Computer Networks The fundamental purpose of a communication system is the
More informationNetwork Working Group Request for Comments: 840 April 1983. Official Protocols
Network Working Group Request for Comments: 840 J. Postel ISI April 1983 This RFC identifies the documents specifying the official protocols used in the Internet. Annotations identify any revisions or
More informationInternet Architecture and Philosophy
Internet Architecture and Philosophy Conceptually, TCP/IP provides three sets of services to the user: Application Services Reliable Transport Service Connectionless Packet Delivery Service The underlying
More informationApplied Data Communication Lecture 14
Applied Data Communication Lecture 14 Character oriented Data Link Character-oriented data link control Asynchronous Synchronous Kristjan Sillmann reaalajasüsteemide õppetool TTÜ automaatikainstituut character-oriented
More informationACHILLES CERTIFICATION. SIS Module SLS 1508
ACHILLES CERTIFICATION PUBLIC REPORT Final DeltaV Report SIS Module SLS 1508 Disclaimer Wurldtech Security Inc. retains the right to change information in this report without notice. Wurldtech Security
More informationUnderstanding TCP/IP. Introduction. What is an Architectural Model? APPENDIX
APPENDIX A Introduction Understanding TCP/IP To fully understand the architecture of Cisco Centri Firewall, you need to understand the TCP/IP architecture on which the Internet is based. This appendix
More informationSVMi-4 & SVM-400. Voice Mail System. System Administration Manual
SVMi-4 & SVM-400 Voice Mail System System Administration Manual Contents About this Book 3 How to use this online manual 4 How to print this online manual 5 Feature Descriptions 6 SYSTEM FEATURES 6 AUTO
More informationSession Initiation Protocol (SIP) The Emerging System in IP Telephony
Session Initiation Protocol (SIP) The Emerging System in IP Telephony Introduction Session Initiation Protocol (SIP) is an application layer control protocol that can establish, modify and terminate multimedia
More informationComputer Network. Interconnected collection of autonomous computers that are able to exchange information
Introduction Computer Network. Interconnected collection of autonomous computers that are able to exchange information No master/slave relationship between the computers in the network Data Communications.
More informationAn Introduction to VoIP Protocols
An Introduction to VoIP Protocols www.netqos.com Voice over IP (VoIP) offers the vision of a converged network carrying multiple types of traffic (voice, video, and data, to name a few). To carry out this
More informationHow To Use Allworx On A Pc Or Mac Or Ipod Or Ipo Or Ipode Or Ipro Or Iporode Or Mac (For A Mac) Or Ipore Or Ipos Or Ipob Or Ipocode (
Allworx User s Guide (Release 7.2.3.x) No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopy, recording,
More informationEthernet. Ethernet. Network Devices
Ethernet Babak Kia Adjunct Professor Boston University College of Engineering ENG SC757 - Advanced Microprocessor Design Ethernet Ethernet is a term used to refer to a diverse set of frame based networking
More informationProtocols and Architecture. Protocol Architecture.
Protocols and Architecture Protocol Architecture. Layered structure of hardware and software to support exchange of data between systems/distributed applications Set of rules for transmission of data between
More informationPART OF THE PICTURE: The TCP/IP Communications Architecture
PART OF THE PICTURE: The / Communications Architecture 1 PART OF THE PICTURE: The / Communications Architecture BY WILLIAM STALLINGS The key to the success of distributed applications is that all the terminals
More informationICOM 5026-090: Computer Networks Chapter 6: The Transport Layer. By Dr Yi Qian Department of Electronic and Computer Engineering Fall 2006 UPRM
ICOM 5026-090: Computer Networks Chapter 6: The Transport Layer By Dr Yi Qian Department of Electronic and Computer Engineering Fall 2006 Outline The transport service Elements of transport protocols A
More informationSingle channel data transceiver module WIZ2-434
Single channel data transceiver module WIZ2-434 Available models: WIZ2-434-RS: data input by RS232 (±12V) logic, 9-15V supply WIZ2-434-RSB: same as above, but in a plastic shell. The WIZ2-434-x modules
More informationBest Practices for Role Based Video Streams (RBVS) in SIP. IMTC SIP Parity Group. Version 33. July 13, 2011
Best Practices for Role Based Video Streams (RBVS) in SIP IMTC SIP Parity Group Version 33 July 13, 2011 Table of Contents 1. Overview... 3 2. Role Based Video Stream (RBVS) Best Practices Profile... 4
More informationNetworking Overview. (as usual, thanks to Dave Wagner and Vern Paxson)
Networking Overview (as usual, thanks to Dave Wagner and Vern Paxson) Focus For This Lecture Sufficient background in networking to then explore security issues in next few lectures Networking = the Internet
More informationBluetooth voice and data performance in 802.11 DS WLAN environment
1 (1) Bluetooth voice and data performance in 802.11 DS WLAN environment Abstract In this document, the impact of a 20dBm 802.11 Direct-Sequence WLAN system on a 0dBm Bluetooth link is studied. A typical
More informationIndian Institute of Technology Kharagpur. TCP/IP Part I. Prof Indranil Sengupta Computer Science and Engineering Indian Institute of Technology
Indian Institute of Technology Kharagpur TCP/IP Part I Prof Indranil Sengupta Computer Science and Engineering Indian Institute of Technology Kharagpur Lecture 3: TCP/IP Part I On completion, the student
More information)454 6. SERIES V: DATA COMMUNICATION OVER THE TELEPHONE NETWORK Interfaces and voiceband modems. ITU-T Recommendation V.25
INTERNATIONAL TELECOMMUNICATION UNION )454 6 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (10/96) SERIES V: DATA COMMUNICATION OVER THE TELEPHONE NETWORK Interfaces and voiceband modems!utomatic ANSWERING
More informationRequirements of Voice in an IP Internetwork
Requirements of Voice in an IP Internetwork Real-Time Voice in a Best-Effort IP Internetwork This topic lists problems associated with implementation of real-time voice traffic in a best-effort IP internetwork.
More information4. H.323 Components. VOIP, Version 1.6e T.O.P. BusinessInteractive GmbH Page 1 of 19
4. H.323 Components VOIP, Version 1.6e T.O.P. BusinessInteractive GmbH Page 1 of 19 4.1 H.323 Terminals (1/2)...3 4.1 H.323 Terminals (2/2)...4 4.1.1 The software IP phone (1/2)...5 4.1.1 The software
More informationTable of Contents: Protocol Overview. Components H.225 Q.931 H.245. H.235v2 (Security) H.323 & FireWalls. Sample SIP Session.
Table of Contents: I. H.323 Protocol Overview Components H.225 RAS Q.931 H.245 H.235v2 (Security) H.323 & FireWalls II. /Skinny III. RTP and RTCP IV. SIP Sample SIP Session Request Methods Request Headers
More informationVoice Over IP Per Call Bandwidth Consumption
Over IP Per Call Bandwidth Consumption Interactive: This document offers customized voice bandwidth calculations with the TAC Bandwidth Calculator ( registered customers only) tool. Introduction Before
More informationRARP: Reverse Address Resolution Protocol
SFWR 4C03: Computer Networks and Computer Security January 19-22 2004 Lecturer: Kartik Krishnan Lectures 7-9 RARP: Reverse Address Resolution Protocol When a system with a local disk is bootstrapped it
More informationData Link Layer(1) Principal service: Transferring data from the network layer of the source machine to the one of the destination machine
Data Link Layer(1) Principal service: Transferring data from the network layer of the source machine to the one of the destination machine Virtual communication versus actual communication: Specific functions
More informationChapter 3. TCP/IP Networks. 3.1 Internet Protocol version 4 (IPv4)
Chapter 3 TCP/IP Networks 3.1 Internet Protocol version 4 (IPv4) Internet Protocol version 4 is the fourth iteration of the Internet Protocol (IP) and it is the first version of the protocol to be widely
More informationComputer Networks. Data Link Layer
Computer Networks The Data Link Layer 1 Data Link Layer Application Transport Network DLL PHY 2 What does it do? What functions it performs? Typically: Handling transmission errors, a.k.a., error control.
More informationIP Network Layer. Datagram ID FLAG Fragment Offset. IP Datagrams. IP Addresses. IP Addresses. CSCE 515: Computer Network Programming TCP/IP
CSCE 515: Computer Network Programming TCP/IP IP Network Layer Wenyuan Xu Department of Computer Science and Engineering University of South Carolina IP Datagrams IP is the network layer packet delivery
More informationHow To Understand The Concept Of Circuit Switching
Module 2 Communication Switching Lesson 2 Circuit Switching INSTRUCTIONAL OBJECTIVES GENERAL This lesson is aimed at developing the concept and application of circuit switching which is a very important
More informationVoice over IP. Demonstration 1: VoIP Protocols. Network Environment
Voice over IP Demonstration 1: VoIP Protocols Network Environment We use two Windows workstations from the production network, both with OpenPhone application (figure 1). The OpenH.323 project has developed
More informationHigh-Level Data Link Control
High-Level Data Link Control This class of data link layer protocols includes High-level Data Link Control (HDLC), Link Access Procedure Balanced (LAPB) for X.25, Link Access Procedure for D-channel (LAPD)
More informationUser Guide. Version 3.0 April 2006
User Guide Version 3.0 April 2006 2006 Obvious Solutions Inc. All rights reserved. Dabra and Dabra Network are trademarks of Obvious Solutions Inc. All other trademarks owned by their respective trademark
More informationSubnetting,Supernetting, VLSM & CIDR
Subnetting,Supernetting, VLSM & CIDR WHAT - IP Address Unique 32 or 128 bit Binary, used to identify a system on a Network or Internet. Network Portion Host Portion CLASSFULL ADDRESSING IP address space
More informationLab Exercise 802.11. Objective. Requirements. Step 1: Fetch a Trace
Lab Exercise 802.11 Objective To explore the physical layer, link layer, and management functions of 802.11. It is widely used to wireless connect mobile devices to the Internet, and covered in 4.4 of
More information(Refer Slide Time: 4:45)
Digital Voice and Picture Communication Prof. S. Sengupta Department of Electronics and Communication Engineering Indian Institute of Technology, Kharagpur Lecture - 38 ISDN Video Conferencing Today we
More informationGuideline for setting up a functional VPN
Guideline for setting up a functional VPN Why do I want a VPN? VPN by definition creates a private, trusted network across an untrusted medium. It allows you to connect offices and people from around the
More informationEKSAMEN / EXAM TTM4100 18 05 2007
1.1 1.1.1...... 1.1.2...... 1.1.3...... 1.1.4...... 1.1.5...... 1.1.6...... 1.1.7...... 1.1.8...... 1.1.9...... 1.1.10.... 1.1.11... 1.1.16.... 1.1.12... 1.1.17.... 1.1.13... 1.1.18.... 1.1.14... 1.1.19....
More informationThis service allows you to talk to the 3rd party before transferring the original called party to them. To use Attended Call transfer:
Calling Features Attend Call Transfer Auto Redial Anonymous Call Rejection Call Blocking Call Forward Busy Line Call Forward Don't Answer Call Forwarding Remote Access Call Forwarding Universal Call Holding
More informationNetwork Layer IPv4. Dr. Sanjay P. Ahuja, Ph.D. Fidelity National Financial Distinguished Professor of CIS. School of Computing, UNF
Network Layer IPv4 Dr. Sanjay P. Ahuja, Ph.D. Fidelity National Financial Distinguished Professor of CIS School of Computing, UNF IPv4 Internet Protocol (IP) is the glue that holds the Internet together.
More informationGuide to TCP/IP, Third Edition. Chapter 3: Data Link and Network Layer TCP/IP Protocols
Guide to TCP/IP, Third Edition Chapter 3: Data Link and Network Layer TCP/IP Protocols Objectives Understand the role that data link protocols, such as SLIP and PPP, play for TCP/IP Distinguish among various
More information04 Internet Protocol (IP)
SE 4C03 Winter 2007 04 Internet Protocol (IP) William M. Farmer Department of Computing and Software McMaster University 29 January 2007 Internet Protocol (IP) IP provides a connectionless packet delivery
More informationQuality of Service (QoS) on Netgear switches
Quality of Service (QoS) on Netgear switches Section 1 Principles and Practice of QoS on IP networks Introduction to QoS Why? In a typical modern IT environment, a wide variety of devices are connected
More informationPHONE USER 1 GUIDE. Morristown (MUS) Local Customer Calling FROM: Morristown (Area Code 423): 307, 317, 318, 522, 581, 585, 586, 587
PHONE USER 1 GUIDE Local Calling Area Windstream has defined the following local calling area. All calls to these areas are included in your local monthly charge. Calls outside of this area will be billed
More informationTo activate Anonymous Call Rejection: 1. Lift the receiver and listen for dial tone. 2. Dial *77. 3. Listen for confirmation tone, hang up.
Anonymous Call Rejection Anonymous Call Rejection allows a customer to deny any calls from ringing the line if the calling party has blocked the identification number. The calling party receives a message
More informationLocal Area Networks transmission system private speedy and secure kilometres shared transmission medium hardware & software
Local Area What s a LAN? A transmission system, usually private owned, very speedy and secure, covering a geographical area in the range of kilometres, comprising a shared transmission medium and a set
More informationModule 7. Routing and Congestion Control. Version 2 CSE IIT, Kharagpur
Module 7 Routing and Congestion Control Lesson 4 Border Gateway Protocol (BGP) Specific Instructional Objectives On completion of this lesson, the students will be able to: Explain the operation of the
More informationApplication Protocols for TCP/IP Administration
Application Protocols for TCP/IP Administration BootP, TFTP, DHCP Agenda BootP TFTP DHCP BootP, TFTP, DHCP, v4.4 2 Page 60-1 BootP (RFC 951, 1542, 2132) BootP was developed to replace RARP capabilities
More information1 Getting Started. Before you can connect to a network
1 Getting Started This chapter contains the information you need to install either the Apple Remote Access Client or Apple Remote Access Personal Server version of Apple Remote Access 3.0. Use Apple Remote
More informationProcess Control and Automation using Modbus Protocol
Process Control and Automation using Modbus Protocol Modbus is the fundamental network protocol used in most industrial applications today. It is universal, open and an easy to use protocol. Modbus has
More informationRequest For Comments: 1350 STD: 33 July 1992 Obsoletes: RFC 783
Network Working Group K. Sollins Request For Comments: 1350 MIT STD: 33 July 1992 Obsoletes: RFC 783 Status of this Memo THE TFTP PROTOCOL (REVISION 2) This RFC specifies an IAB standards track protocol
More informationAll Rights Reserved. Copyright 2009
IMPORTANT NOTICE CONCERNING EMERGENCY 911 SERVICES Your service provider, not the manufacturer of the equipment, is responsible for the provision of phone services through this equipment. Any services
More informationImproving the Performance of TCP Using Window Adjustment Procedure and Bandwidth Estimation
Improving the Performance of TCP Using Window Adjustment Procedure and Bandwidth Estimation R.Navaneethakrishnan Assistant Professor (SG) Bharathiyar College of Engineering and Technology, Karaikal, India.
More informationUM8000 MAIL USER GUIDE
UM8000 MAIL USER GUIDE INT-2076 (UNIV) Issue 1.0 INTRODUCTION Welcome to UM8000 Mail User Guide. The UM8000 Mail is a simple yet powerful voice messaging system that can greet your callers and record your
More informationCentrex CustoPAK USER GUIDE. Telephone Number. Verizon Telephone Number. Switch Type: 1A 5E DMS 100 EWSD DMS 10
Centrex CustoPAK USER GUIDE Telephone Number Verizon Telephone Number Switch Type: 1A 5E DMS 100 EWSD DMS 10 Table of Contents Introduction to This Guide... 3 Overview of Your CustoPAK System... 5 Terms
More informationSystem Requirements. Hiro H50113
1 Hiro H50113 System Requirements Hiro H50113 Computer with Pentium 200 MMX or higher processor. Windows 2000, Windows XP Home / Professional, XP Professional x64 Edition, Vista 32 / 64 Families, Windows
More informationESSENTIALS. Understanding Ethernet Switches and Routers. April 2011 VOLUME 3 ISSUE 1 A TECHNICAL SUPPLEMENT TO CONTROL NETWORK
VOLUME 3 ISSUE 1 A TECHNICAL SUPPLEMENT TO CONTROL NETWORK Contemporary Control Systems, Inc. Understanding Ethernet Switches and Routers This extended article was based on a two-part article that was
More informationELEC3030 (EL336) Computer Networks. How Networks Differ. Differences that can occur at network layer, which makes internetworking difficult:
How Networks Differ Differences that can occur at network layer, which makes internetworking difficult: It is impossible to resolve all differences, and the solution is to take a simple approach (as in
More informationQoS Parameters. Quality of Service in the Internet. Traffic Shaping: Congestion Control. Keeping the QoS
Quality of Service in the Internet Problem today: IP is packet switched, therefore no guarantees on a transmission is given (throughput, transmission delay, ): the Internet transmits data Best Effort But:
More informationNetwork Layer. Introduction Datagrams and Virtual Circuits Routing Traffic Control. Data delivery from source to destination.
Layer Introduction Datagrams and Virtual ircuits Routing Traffic ontrol Main Objective Data delivery from source to destination Node (Router) Application Presentation Session Transport Data Link Data Link
More informationCall Waiting. Cancel Call Waiting
PhoneFeatures 1 Call Waiting Cancel Call Waiting 2 Three-Way Calling Personal Ringing 3 Speed Calling Call Transfer 4 Call Hold Call Forwarding 5 Call Forwarding Don t Answer Call Forwarding Busy Line
More informationIP Addressing A Simplified Tutorial
Application Note IP Addressing A Simplified Tutorial July 2002 COMPAS ID 92962 Avaya Labs 1 All information in this document is subject to change without notice. Although the information is believed to
More informationTransport Layer. Chapter 3.4. Think about
Chapter 3.4 La 4 Transport La 1 Think about 2 How do MAC addresses differ from that of the network la? What is flat and what is hierarchical addressing? Who defines the IP Address of a device? What is
More informationFEATURE & INFORMATION GUIDE
FEATURE & INFORMATION GUIDE LOCAL PHONE Windstream is a registered service mark of Windstream Corporation. 2007 WindstreamCorporation WS F&I ENG 07/07 001519 English_F&I_Guide.indd 1-2 7/23/07 4:31:53
More informationUser Guide Verizon Centrex CustoPAK
User Guide Verizon Centrex CustoPAK Telephone Number Verizon Telephone Number Switch Type: 1A 0 EWSD 2008 Verizon. All Rights Reserved. 3001-0708 Table of Contents Introduction to This Guide... 3 Overview
More informationwww.metrocast.com/business
www.metrocast.com/business All Rights Reserved The use, disclosure, modification, transfer or transmittal of this work for any purpose, in any form, or by any means, without the written permission from
More informationThree Network Technologies
Three Network Technologies Network The largest worldwide computer network, specialized for voice ing technique: Circuit-switching Internet The global public information infrastructure for data ing technique:
More informationImplementing and testing tftp
CSE123 Spring 2013 Term Project Implementing and testing tftp Project Description Checkpoint: May 10, 2013 Due: May 29, 2013 For this project you will program a client/server network application in C on
More informationEmpowered by Innovation. User s Guide. P/N 1770082 July 2006 Printed in U.S.A.
Empowered by Innovation User s Guide P/N 1770082 July 2006 Printed in U.S.A. This manual has been developed by NEC Unified Solutions, Inc. It is intended for the use of its customers and service personnel,
More informationEmerald ICE Digital Key Telephone System
This manual is provided to you by ElectSys; a certified dealer that installs and supports Tadiran systems. Call us at 717-665-2141 or visit www.electsys.biz TM Emerald ICE Digital Key Telephone System
More informationVoice mail Play messages Activate Deactivate. Voice mail. Activate? Voice mail. Play messages Activate Deactivate. Set ring time.
Regarding Use of This Guide This guide is intended for users of DOCOMO mobile phones with a DOCOMO UIM Card (or otherwise a FOMA Card or DOCOMO mini UIM Card. Hereinafter the same applies). If the SIM
More informationMicrosoft Office Communicator 2007 Getting Started Guide. Published: July 2007
Microsoft Office Communicator 2007 Getting Started Guide Published: July 2007 Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless
More informationRing Local Area Network. Ring LANs
Ring Local Area Network Ring interface (1-bit buffer) Ring interface To station From station Ring LANs The ring is a series of bit repeaters, each connected by a unidirectional transmission link All arriving
More informationThe Problem with Faxing over VoIP Channels
The Problem with Faxing over VoIP Channels Lower your phone bill! is one of many slogans used today by popular Voice over IP (VoIP) providers. Indeed, you may certainly save money by leveraging an existing
More informationCALLING FEATURE USER GUIDE
Quick Start CALLING FEATURE USER GUIDE FEATURE ACTIVATE CANCEL Call Waiting hookswitch (or flash) 3- Way Calling hookswitch (or flash) *69 Call Return (Automatic Recall) *69 *89 Cancel Call Waiting *70
More informationHow To Understand Bg
Table of Contents BGP Case Studies...1 BGP4 Case Studies Section 1...3 Contents...3 Introduction...3 How Does BGP Work?...3 ebgp and ibgp...3 Enabling BGP Routing...4 Forming BGP Neighbors...4 BGP and
More informationHow To Use Fairpoint.Com On A Cell Phone On A Pc Or Landline Phone On An Iphone Or Ipad Or Ipa Or Ipo Or Cell Phone (For A Cell) On A Landline Or Cellphone On A
Definition FairPoint Communications Hosted PBX is easy to use and manage. Hosted PBX is packed with a wide variety of useful standard, advanced and business group calling features, including voicemail.
More informationHosted PBX Calling Features and Voice Mail Guide
Definition FairPoint Communications Hosted PBX is easy to use and manage. Hosted PBX is packed with a wide variety of useful standard, advanced and business group calling features, including voicemail.
More informationVoice Messaging. Reference Guide
Voice Messaging Reference Guide Table of Contents Voice Messaging 1 Getting Started 3 To Play a Message 4 To Answer a Message 5 To Make a Message 6 To Give a Message 7 Message Addressing Options 8 User
More informationNetwork administrators must be aware that delay exists, and then design their network to bring end-to-end delay within acceptable limits.
Delay Need for a Delay Budget The end-to-end delay in a VoIP network is known as the delay budget. Network administrators must design a network to operate within an acceptable delay budget. This topic
More informationEncoding Text with a Small Alphabet
Chapter 2 Encoding Text with a Small Alphabet Given the nature of the Internet, we can break the process of understanding how information is transmitted into two components. First, we have to figure out
More informationVoice Over Internet Protocol(VoIP)
Voice Over Internet Protocol(VoIP) By Asad Niazi Last Revised on: March 29 th, 2004 SFWR 4C03 Major Project Instructor: Dr. Kartik Krishnan 1. Introduction The telecommunications companies around the world
More informationNAT TCP SIP ALG Support
The feature allows embedded messages of the Session Initiation Protocol (SIP) passing through a device that is configured with Network Address Translation (NAT) to be translated and encoded back to the
More informationPolycom SoundPoint IP 650
Polycom SoundPoint IP 650 User Guide For training/documentation, please visit us @ http://customertraining.verizonbusiness.com or call 1 800 662 1049 2009 Verizon. All Rights Reserved. The Verizon and
More informationAnonymous Call Rejection
Anonymous Call Rejection Don t waste time taking calls you don t want. Anonymous Call Rejection (ACR) allows you to block incoming calls from people who use *67 to block their phone number as well as calls
More informationRFC 821 SIMPLE MAIL TRANSFER PROTOCOL. Jonathan B. Postel. August 1982
RFC 821 SIMPLE MAIL TRANSFER PROTOCOL Jonathan B. August 1982 Information Sciences Institute University of Southern California 4676 Admiralty Way Marina del Rey, California 90291 (213) 822-1511 RFC 821
More informationTCP Session Management (SesM) Protocol Specification
TCP Session Management (SesM) Protocol Specification Revision Date: 08/13/2015 Version: 1.1e Copyright 2015 Miami International Securities Exchange, LLC. All rights reserved. This constitutes information
More information