Tech-invite   World Map
3GPPspecs     Glossaries     IETF     RFCs     Groups     SIP     ABNFs

RFC 2458


Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations

Part 3 of 3, p. 43 to 60
Prev RFC Part


prevText      Top      Up      ToC       Page 43 
7. Session Initiation Protocol--An Emerging Standard

7.1 Overview

   SIP, the Session Initiation Protocol, is a simple signaling protocol
   for Internet conferencing and telephony. It is currently under
   development within the IETF MMUSIC (Multiparty Multimedia Session
   Control) Working Group.

   SIP provides the necessary mechanisms to support the following

   - call forwarding, including the equivalent of 700-, 800- and 900-
     type calls;
   - call-forwarding no answer;

Top      Up      ToC       Page 44 
   - call-forwarding busy;
   - call-forwarding unconditional;
   - other address-translation services;
   - callee and calling "numbers" delivery, where the numbers can be of
     any (preferably unique) naming scheme;
   - personal mobility, i.e., the ability to reach a called party under
     a single, location-independent address, even when the user changes
   - terminal-type negotiation and selection: a caller can be given a
     choice of how to reach a party, e.g., via Internet telephony,
     mobile, phone, and an answering service;
   - caller and callee authentication;
   - blind and supervised call transfer;
   - user location; and
   - invitation to multicast conferences.

   Extensions of SIP to allow third-party signaling (e.g., for click-
   to-dial-back services, fully meshed conferences and connections to
   Multipoint Control Units (MCUs), as well as mixed modes and the
   transition between those) have been specified.

   SIP addresses (URLs) can be embedded in Web pages. SIP is
   addressing-neutral, with addresses expressed as URLs of various types
   such as SIP, H.323 or telephone (E.164). A purely representational
   example of a SIP URL might be, where is the host serving as a gateway into the PSTN.

   SIP is independent of the packet layer and only requires an
   unreliable datagram service, as it provides its own reliability
   mechanism. While SIP typically is used over UDP or TCP, it could,
   without technical changes, be run over IPX, or carrier pigeons, ATM
   AAL5 or X.25, in rough order of desirability.

   SIP can set up calls "out-of-band". For example, while the SIP
   protocol exchanges use IP, plus UDP or TCP, the actual data transport
   can take place via the PSTN. This feature makes it possible to use
   SIP to control a PBX or send requests to a Service Control Point. The
   PINT services make use of this flexibility.

7.2 SIP Protocol

   SIP is a textual client-server protocol, similar in syntax to HTTP
   and RTSP.  Requests consist of a method (INVITE, BYE, ACK, or
   REGISTER), a list of parameter-value pairs describing the request and
   an optional request body. Parameters include the origin and
   destination of the call and a unique call identifier. They may
   indicate the caller's organization as well as the call's subject and
   priority. The request body contains a description of the call to be

Top      Up      ToC       Page 45 
   established or the conference to be joined. The description format is
   not prescribed by SIP; SDP is one possibility being standardized
   within the IETF. For the purposes of providing PINT services, an
   additional phone number address format is to be added to SDP.

   Responses indicate whether a request is still being processed, was
   successful, can possibly be satisfied by another node or failed. When
   a call is redirected, the response indicates the name of the node to
   be tried. Unsuccessful calls may also return a better time to try

   In a typical successful call, the caller sends an INVITE request to
   the callee. The callee accepts the call by returning a response code
   to the callee, which then confirms the receipt of that acceptance
   with an ACK request. Either side can terminate the call by sending a
   BYE request.

   Requests can be authenticated using standard HTTP password and
   challenge-response mechanisms. Requests and responses may also be
   signed and encrypted.

7.3 SIP entities

   SIP distinguishes three kinds of entities:

   User agents receive and initiate calls and may forward the call.

   A proxy server is an intermediary program that acts as both a server
   and a client for the purpose of making requests on behalf of other
   clients. Requests are serviced internally or by passing them on,
   possibly after translation, to other servers. A proxy must interpret,
   and, if necessary, rewrite a request message before forwarding it. A
   proxy server may, for example, locate a user and then attempt one or
   more possible network addresses.

   Redirect server accepts a SIP request, maps the address into zero or
   more new addresses and returns these addresses to the client. Unlike
   a proxy server, it does not initiate its own SIP request. Unlike a
   user agent server, it does not accept calls.

   Proxy and redirect servers may make use of location servers that
   determine the current likely location of the callee.

   A PSTN gateway initiates phone calls between two parties. This may be
   a server that sends requests to an SCP in an IN environment or it may
   be a CTI-controlled PBX.

   A SIP call may traverse one or more proxy servers.

Top      Up      ToC       Page 46 
   The servers that control a PBX or an SCP act as user agents. A Web
   server may also act as a SIP user agent.

7.4 Providing Call Control Functionality

   The SIP for PINT specification provides details on how to use SIP to
   initiate phone calls between two PSTN end points. (SIP can also
   initiate calls between Internet end points and between an Internet
   and PSTN end point, but this is beyond the scope of this document.)

   It should be noted that the SIP client for initiating such phone
   calls can be either at the user's location (his/her workstation) or
   can be a Web server that calls up a SIP client via a CGI program.
   There is no difference in operation or functionality, except that the
   owner of the Web server may be legally responsible for the calls

   A SIP client needs to convey two addresses to the PSTN gateway:  the
   party making the call and the party to be called. (The party to be
   billed also needs to be identified; this can either be done by a SIP
   header or by having the server look up the appropriate party based on
   the two parties. This aspect is for further study.)

   Described below are three ways these addresses can be conveyed in
   SIP. In the example, the address of party A is +1-212-555-1234 and
   that of party B is +1-415-555-1200. (The URL types in this and other
   examples are representational; they may but do not have to exist.)

   (1) The two PSTN addresses are contained in the To header (and
   request-URI) and an Also header. For example:

     INVITE SIP/2.0
     To: phone:1-212-555-1234
     Content-type: application/sdp
     Also: phone:+1-415-555-1200

     o=user1 53655765 2353687637 IN IP4
     c=PSTN E.164 +1-415-555-1200
     t=0 0
     m=audio 0 RTP/AVP 0

   In that case, the gateway first connects to party A and then party B,
   but without waiting for A to accept the call before calling B.

Top      Up      ToC       Page 47 
   (2) Parties A and B are indicated by separate invitations. This
   allows the gateway to make sure that party A is indeed available
   before calling party B.  After calling party A, the gateway could
   play an announcement indicating that the call is being connected
   using, for example, RTSP with appropriate Conference header
   indicating the call.

     INVITE SIP/2.0
     To: phone:1-212-555-1234
     Content-type: application/sdp
     INVITE SIP/2.0
     To: phone:+1-415-555-1200
     Content-type: application/sdp

   (3) The two PSTN addresses are conveyed in the To header of the SIP
   request and the address in the SDP media description. Thus, a request
   may look as follows:

     INVITE SIP/2.0
     To: phone:1-212-555-1234
     Content-type: application/sdp

     o=user1 53655765 2353687637 IN IP4
     c=PSTN E.164 +1-415-555-1200
     t=0 0
     m=audio 0 RTP/AVP 0

   Here, is the name of the PSTN gateway; the call will
   be established between 1-212-555-1234 and +1-415-555-1200.

   Users can be added to an existing call by method (1) or (2).

8. Overall Security Considerations

   Inter-networking of the Internet and PSTN necessitates the
   introduction of new interfaces (e.g., the A, B and E interfaces in
   Figure 6). To ensure that their use does not put the networks, in
   particular the PSTN, at additional security risk, these interfaces
   need to be designed with proper security considerations. Sections

Top      Up      ToC       Page 48 
   5.1.5 and describe how two of the pre-PINT implementations,
   the Lucent and Siemens systems, handle the security aspect,

   Worth noting are the security requirements suggested by pre-PINT
   experiences. They are:

   +Peer entity authentication to allow a communicating entity to prove
   its identity to another in the network (e.g., the requesting IP-host
   to the PINT gateway, and the PINT gateway to the PSTN node providing
   the service control function).

   +Authorization and access control to verify if a network entity
   (e.g., the requesting IP-host) is allowed to use a network resource
   (e.g., requesting services from the PINT gateway).

   +Non-repudiation to account for all operations in case of doubt or

   +Confidentiality to avoid disclosure of information (e.g., the end
   user profile information and data) without the permission of its

   In the course of the PINT interface development, additional
   requirements are likely to arise. It is imperative that the resultant
   interfaces include specific means to meet all the security

9. Conclusion

   This document has provided the information relevant to the
   development of inter-networking interfaces between the PSTN and
   Internet for supporting PINT services. Specifically, it addressed
   technologies, architectures, and several existing pre-PINT
   implementations of the arrangements through which Internet
   applications can request and enrich PSTN telecommunications services.
   One key observation is that the pre-PINT implementations, being
   developed independently, do not inter-operate. It is a task of the
   PINT Working Group to define the inter-networking interfaces that
   will support inter-operation of the future implementations of PINT

10. Acknowledgments

   The authors would like to acknowledge Scott Bradner, Igor Faynberg,
   Dave Oran, Scott Petrack, Allyn Romanow for their insightful comments
   presented to the discussions in the PINT Working Group that lead to
   the creation of this document.

Top      Up      ToC       Page 49 
11. Appendix

11.1 PSTN/IN 101

11.1.1 Public Switched Telephone Network

   What is normally considered as "the Telephone Network" consists of a
   set of interconnected networks. Potentially, each of these networks
   could be owned by a different Network Operator. The official name for
   such a network is Public Switched Telecommunications Network (PSTN).
   A simple PSTN consists of a set of Switches (called Central Offices
   or Telephone Exchanges) with links interconnecting them to make up
   the network, along with a set of access connections by which
   terminals are attached. The PSTN is used to deliver calls between
   terminals connected to itself or to other PSTNs with which it is
   interconnected. Calls on the PSTN are circuit switched; that is, a
   bi-directional connection is made between the calling and called
   terminals for the duration of the call. In  PSTNs the connection is
   usually carried through the network in digital format occupying a
   fixed bandwidth; this is usually 56 or 64 Kbps. The overall
   configuration of the PSTN is shown in Figure 16.

    /__\   \       .................................
            \      !             !                 !           /--\
     __      \   [-!-]         [-!-]               !          ()/\()
     \ \      \__[CO ]=========[CO ]==\\           !        ___/__\
    [Fax]________[---]         [---]   \\        [-!-]     /   __
                                        \\=======[CO ]____/    \ \
   Key: ___   Access Lines
        ===   Trunk Links (inter-CO user data links)
        ...   Inter-CO signaling network links

                               Figure 16

   Messages are sent between the Switches to make and dissolve
   connections through the network on demand and to indicate the status
   of terminals involved in a call; these "signaling" messages are
   carried over a separate (resilient) data network dedicated to this
   purpose. This signaling network is also known as the Common Channel
   Signaling (CCS) or Signaling System Number 7 (or SS7) network after
   the names of the signaling protocol suite used.

   As yet, the majority of access connections to a PSTN carry analogue
   signals, with simple (analogue) telephones or Facsimile machines as
   terminals. Call requests are indicated to the Central Office to which

Top      Up      ToC       Page 50 
   a telephone is connected either by a sequence of pulses or tone pairs
   being sent. Notifications on the status of the request are sent back
   to the telephone in the form of tones.  Indication from a Central
   Office that a call is being offered to a telephone is arranged by
   sending an alternating voltage down the access connection which in
   turn causes the ringer in the telephone to sound. These access lines
   have a unique address associated with them and can support a single

   However, with analogue or digital multi-line connections, or
   Integrated Service Digital Network (ISDN) Basic or Primary Rate
   Interfaces (BRI or PRI), several concurrent calls are possible and a
   set of addresses are associated with them. The new ISDN access
   connections are designed so that data exchanged with the network is
   in multiplexed digital form, and there is an individual channel for
   each of the potential connections, together with a separate channel
   dedicated to sending and receiving call request and call alert data
   as well as carrying packet switched user data. These call request and
   call alert messages act as the equivalent of the pulses or tones that
   are sent when dialing, and the ringing signal that is sent to a
   telephone when a call is being made to it.

   The operation of the call request is fairly simple in most cases and
   is shown in Figure 17.

   ()  ()
    /++\   \       .................................           /--\
   /----\   \      ^             v                 !          ()  ()
      A      \   [-!-]         [-!-]               !            --
              \->[CO ]=========[CO ]==\\           v        ->-/  \
                 [---]         [---]   \\        [-!-]     /  /----\
                                        \\=======[CO ]____/     B
   Key: ___   Access Lines
        ===   Trunk Links (inter-CO user data links)
        ...   Inter-CO signaling network links
        CO    Central Office (Telephone Exchange)

                               Figure 17

   The user presses a sequence of numbers on a telephone handset
   (labeled A), and the telephone passes a sequence of digits (either as
   pulses or tone pairs) to the Central Office via the access line. The
   Central Office contains a processor that will be notified that the
   user has made a request and the digit string that is the sole
   parameter of the request. This digit string is taken to be the unique

Top      Up      ToC       Page 51 
   address of an access line connected either to itself or to another
   Central Office. There is a hierarchical addressing scheme, so that
   the digit string can be parsed easily. A call request to a terminal
   (labeled B) connected to a remote Central Office can be routed by
   examining the digit string passed; the Central Office will extract
   the part of the passed address that corresponds to the remote Central
   Office in question, and can route the request onward, forming an
   inter-Switch call request and passing it via the signaling network.
   At the same time it will allocate one of its available transmission
   channels towards the remote Central Office.

11.1.2 Intelligent Network

   This scheme has been used since the 1950s, and suffices for the
   majority of calls. However, there are a range of other services that
   can be (and have been) provided, enhancing this basic call
   processing. Freephone or Premium Rate services (1-800 or 1-900
   services) are good examples of the supplementary services that have
   been introduced. Apart from the important feature that the cost of
   these calls is varied so that the caller does not pay for a free-
   phone call, or pays an extra charge for a premium rate call, they
   have the similarity that the number dialed must be translated to
   arrive at the "real" address of the destination terminal. They are
   known as number translation services, and make up the bulk of all
   supplementary services delivered today.

   These were originally programmed into each Central Office, but the
   complexity of maintaining the data tables on each processor grew
   cumbersome, so a more general solution was sought. After a
   considerable gestation period, the eventual solution was the
   Intelligent Network. This takes the separation of Central Offices and
   the network links interconnecting them a stage further.

   The Central Offices are considered to provide the Call Control
   Function (CCF).  In addition, the Service Switching Function (SSF) is
   provided to "enhance" the operation of these Switches by detecting
   when a particular request has been made (such as by dialing 1-800).
   If this pattern is detected, the equipment implementing the SSF will
   send a specialized request message over the signaling network to a
   separate computer that implements the Service Control Function (SCF).
   This entity is responsible for querying service specific data (held
   in a unit providing the Service Data Function, or SDF), performing
   any digit translations necessary, and sending the details of how to
   proceed back to the SSF, where they are obeyed and the call is put
   through to the "real" destination. In many implementations, the SDF
   is closely coupled to the SCF.  This configuration is shown in Figure

Top      Up      ToC       Page 52 
                 [---]           [---]  [---]
    /--\         [SRF]           [SCF]  [SDF]
   ()/\()__      [|-!]           [-!-]  [-!-]
    /__\   \     ||  \.............!......!........
            \    ||  /           !                !          /--\
     __      \   [|-!]         [-!-]              !         ()/\()
     \ \      \__[SSF]         [CCF]              !       ___/__\
    [Fax]________[CCF]=========[---]==\\         [!--]   /   __
                                       \\========[CCF]__/    \ \
   Key: ___   access relationship
        ===   trunk relationship
        ...   signaling relationship

                               Figure 18

   The advantage is that there can be a much smaller number of physical
   units dedicated to the SCF, and as they are connected to the
   signaling network they can be contacted by, and can send instructions
   back to, all of the units providing the SSF and thus the CCF.

   In another enhancement, a separate entity called the Special Resource
   Function (SRF) was defined. Equipment implementing this function
   includes announcement units to play recorded messages (for example,
   prompts to enter digits) to callers. It will also include the tone
   decoders needed to capture any digits pressed by the caller in
   response to the prompts. It is connected to the rest of the PSTN
   usually via trunk data links. It will also include a signaling
   connection (directly or indirectly) back to the SCF, via the PSTN's
   core signaling network.

   As an example of the way that these different functional entities
   interact, the SCF can ask an SSF handling a call to route the caller
   temporarily through to an SRF. In response to instructions sent to it
   from the SCF over the signaling network, the SRF can play
   announcements and can collect digits that the user presses on their
   terminal in response to prompts they are played.  Once these digits
   have been collected they can be passed on to the SCF via a signaling
   message for further processing. In normal operation, the SCF would
   then ask the SSF to dissolve the temporary connection between the
   user's terminal and the SRF. This allows the collection of account
   numbers or passwords (or PINs) and forms the heart of many "Calling
   Card" services.

Top      Up      ToC       Page 53 
   This pattern of user interaction is also used in a wide variety of
   other services where extra account information and PINs are needed.
   They are collected as just described and can be checked against the
   correct values stored in the service database prior to allowing the
   call to proceed.

   The Intelligent Network functional entities can be realized as
   physical units in a number of different combinations. A common
   configuration is shown in Figure 19.

                 [---]           [---] [---]     [---]
    /--\         [I.P]           [SCP] [SDP]     [SN ]
   ()/\()__      [|-!]           [-!-] [-!-]     [--|]
    /__\   \     ||  \.............!.....!.....     |
            \    ||  /           !             \    |        /--\
     __      \   [|-!]         [-!-]            \   |       ()/\()
     \ \      \__[SSP]=========[CO ]==\\         \  |     ___/__\
    [Fax]________[---]         [---]   \\        [!-|]   /   __
                                        \\=======[CO ]__/    \ \

   Key: ___   Access Lines
        ===   Trunk Links (inter-CO user data links)
        ...   Inter-CO signaling network links
        SSP   Service Switching Point - a unit that implements the
              Service Switching Function
        CCP   Call Control Point - a unit that performs call control
              This is normally a kind of Central Office (shown as CO
        SCP   Service Control Point - a unit implementing the Service
              Control Function. NOTE that this is connected to the SS7
              Network and uses this connection for all of its
        I.P   Intelligent Peripheral - a unit that contains specialized
              resources (like announcement units, tone decoders).
              In effect, it implements Special Resource Functions.
        SN    Service Node

                               Figure 19

   This diagram also shows a unit called a Service Node, or SN. This
   contains components that realize all of the operational Intelligent
   Network functions (SSF, SCF, SDF, and SRF). It is sometimes more
   convenient to have all of these elements in one node (for example,
   for operations and maintenance reasons), particularly within smaller
   PSTNs or where there is a relatively low level of requests for

Top      Up      ToC       Page 54 
   particular services. Another difference is that, as they are all co-
   located, proprietary protocols can be used for internal
   communication, rather than the full Intelligent Network Application
   Part (INAP) protocol used over the core signaling network between
   discrete units. It also differs from the "unbundled" approach in that
   it is connected to the COs within a PSTN as a peripheral, having only
   an access connection to a Central Office; there is no connection to
   the core signaling network. Other than this, it operates in a similar
   way, and can provide the same kinds of services. Information on the
   specification of the Intelligent Network can be found in the ITU
   recommendations [1], while two books ([2] and [3]) describe the
   system, its history, operation, and the philosophy behind it.

11.2 Call Center Features

   A Call Center is a system that allows a company to be organized with
   a group of similar individuals (agents), all of whom can either make
   calls to, or take calls from, customers. The system distributes
   incoming calls to the agents based on their availability and
   automates the placement of outgoing calls, selecting an agent to
   handle the call and routing the call to them only once the call
   request has been made of the PSTN.

   The incoming call distribution feature ("automatic call
   distribution", or ACD) is usually coupled with a call queuing scheme.
   In this scheme, the callers are connected temporarily with an
   announcement unit that normally plays music. The calls are treated in
   sequence so that (once the caller is at the front of the queue) the
   ACD system selects the next available agent and routes the call
   through to them.

   Another feature connects a customer making an incoming call to a unit
   that asks them for some information on the purpose of their call,
   selecting the agent to handle the call based on the particular area
   of expertise needed; to do this, the agents are further categorized
   by their knowledge (or "Skill Set"). If this skill set categorization
   is used then by implication there will be separate queues for each of
   the skill sets. This user selection scheme can be used independently
   of the others. For example these so-called "voice navigation systems"
   can be used to select a particular department extension number, based
   on the function required by the customer; as such, they can automate
   the job of company telephone receptionist in routing incoming calls.

   Where possible, the information gleaned from the customer can be
   provided to the selected agent, usually via a separate networked
   computer connection.  Similarly, if an outgoing call is being made to
   one of a list of customers, information on the customer and the
   purpose of the call can be provided to the agent selected to handle

Top      Up      ToC       Page 55 
   the call. Such configurations are generally called "Computer
   Telephony Integration" or CTI systems. Strictly, a CTI system can be
   arranged to handle routing of incoming calls and automation of
   outgoing calls only (also known as computer integrated telephony
   features), without the agents having access to a network of
   computers. However, the business case for combining the telephony
   functions of the call center with provision to the agents of
   computers with customer information can be compelling.

   This is often further combined with a company's order and service
   processing computer system. In this case, a call is treated as part
   of a business transaction, with the information to be exchanged
   captured as fields of a computer form. While such a computer system
   is not, strictly, part of a call center, integrating the company
   computer system with the call center is very common. This allows the
   details of the call to be stored on a centralized database, allowing
   further automated order processing, for example. It also allows the
   call to be transferred from one agent to another where needed,
   ensuring that the new agent has the information already captured.
   This might be useful if someone with a different area of expertise
   were to be needed to handle the customer's requirements.

   Traditionally, Call Centers have been used to support teams of agents
   working at a single site (or a small number of sites, with private
   telephony trunks interconnecting them). The site Private Automatic
   Branch eXchange (PABX) was integrated with a computer system to
   provide these features to people at that site. There can be a
   business case for provision of such features to distributed teams of
   workers as well. In particular, the possibility of providing support
   for people working from home has been seen as important. Some of the
   Call Center features have been incorporated into public telephone
   exchanges or Central Offices (COs) from many manufacturers as part of
   their "Centrex" service offerings.

   There are practical limitations in providing such features on COs.
   Apart from the procedures needed to configure these features for any
   telephone line that is to use them, the basic requirement that every
   agent must have a connection to the supporting CO can limit its
   usefulness. Another approach is to provide Call Center features via
   the Intelligent Network. The features might thus be provided over a
   Telephone Operator's entire network, and would mean that the Call
   Center could be configured centrally while still allowing agents to
   be located anywhere within the telephone network. It also means that
   the supported company can pay for the Call Center features "as they
   go" rather than having a high "up front" cost.

Top      Up      ToC       Page 56 
12. References

   [1] ITU-T Q.12xx Recommendation Series, Geneva, 1995.

   [2] I. Faynberg, L. R. Gabuzda, M. P. Kaplan, and N. J. Shah, "The
       Intelligent Network Standards, their Application to Services",
       McGraw-Hill, 1996.

   [3] T. Magedanz and R. Popesku-Zeletin, "Intelligent Networks: Basic
       Technology, Standards and Evolution", Intl. Thomson Computer
       Press, 1996.

   [4] Information processing systems - Open Systems Interconnection -
       Specification of Abstract Syntax Notation One (ASN.1),
       International Organization for Standardization, International
       Standard 8824, December, 1987.

   [5] McCloghrie, K., Editor, "Structure of Management Information for
       Version 2 of the Simple Network Management Protocol (SNMPv2)",
       RFC 1902, January 1996.

   [6] Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
       RFC 2109, February 1997.

   [7] Zimmerman, D., "The Finger User Information Protocol", RFC 1288
       December 1991.

Top      Up      ToC       Page 57 
Authors' Addresses

   Steve Bellovin
   AT&T Labs
   Room E-215
   180 Park Ave. Bldg. 103
   Florham Park, NJ 07932-0000

   Phone: +1 973 360 8656
   Fax: +1 973 360 8077

   Fred M. Burg
   AT&T Labs
   Room 1N-117
   307 Middletown Lincroft Road
   Lincroft, NJ 07738

   Phone: +1 732 576 4322
   Fax: +1 732 576 4317

   Lawrence Conroy
   Roke Manor Research Limited
   IT&N-INIA Group
   Roke Manor, Old Salisbury Lane,
   Romsey, Hampshire    SO51 0ZN

   Phone: +44 1794 833666
   Fax: +44 1794 833434

   Paul Davidson
   P.O.Box 3511 Station "C"
   Mail Stop 242
   Ottawa, Ontario, Canada K1Y 4H7

   Phone: +1 613 763 4234

Top      Up      ToC       Page 58 
   A. DeSimone
   Lucent Technologies
   Room 6H510
   600-700 Mountain Avenue
   Murray Hill, NJ  07974-0636

   Phone: +1 908 582 2382
   Fax: +1 908 582 1086

   Murali Krishnaswamy
   Bell Laboratories
   Lucent Technologies
   Room 2G-527a
   101 Crawfords Corner Road
   Holmdel, NJ 07733-3030

   Phone: +1 732 949 3611
   Fax: +1 732 949 3210

   Hui-Lan Lu
   Bell Laboratories
   Lucent Technologies
   Room 4K-309
   101 Crawfords Corner Road
   Holmdel, NJ 07733-3030

   Phone: +1 732 949 0321
   Fax: +1 732 949 1196

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   New York, NY 10027

   Phone: +1 212 939 7042 (@Bell Labs: 732 949 8344)
   Fax: +1 212 666 0140

Top      Up      ToC       Page 59 
   Kamlesh T. Tewani
   AT&T Labs
   Room 1K-334
   101, Crawfords Corner Rd.
   Holmdel, NJ 07733

   Phone: +1 732 949 5369
   Fax: +1 732 949 8569

   Kumar Vishwanathan

Top      Up      ToC       Page 60 
Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an