[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 rfc2871                                     
Internet Engineering Task Force                                 iptel wg
Internet Draft                                 J.Rosenberg,H.Schulzrinne
draft-ietf-iptel-gwloc-framework-02.txt            Bell Labs/Columbia U.
February 11, 1999
Expires: August 1999


              A Framework for a Gateway Location Protocol

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as work in progress.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1 Abstract

   This document serves as a framework for a protocol for locating an IP
   telephony gateway. It defines terminology, specifies the various
   architectural elements and their functions, overviews the services
   provided by the protocol, and discusses how it fits into the broader
   context of Internet telephony.

2 Introduction

   As IP telephony gateways grow in terms of numbers and usage, managing
   their operation will become increasingly complex. One of the diffi-
   cult tasks is that of gateway location, also known as gateway selec-
   tion, path selection, gateway discovery, and gateway routing. The
   essence of the problem is that an ingress gateway or end user must
   select a server to which it should forward signaling messages des-
   tined for a particular PSTN destination. This server may actually be
   the gateway, or it may be a gatekeeper or SIP server with additional



J.Rosenberg,H.Schulzrinne                                     [Page 1]


Internet Draft               GLP framework             February 11, 1999


   call routing information. This server or gateway may lie in a remote
   administrative domain, and the selection of the gateway may be based
   on a number of criteria.

   To support discovery and location of gateways in remote administra-
   tive domains, a protocol is being developed, call the Gateway Loca-
   tion Protocol (GLP). This document serves as a framework for GLP. It
   defines terminology used in the specification, specifies the various
   architectural elements and their functions, overviews the services
   provided by the protocol, and discusses how it fits into the broader
   context of Internet telephony.

3 Terminology

   We define the following terms. Note that there are other definitions
   for these terms, outside of the context of gateway location. Our
   definitions aren't general, but refer to the specific meaning here:

        o Gateway: A device with some sort of PSTN connectivity and IP
          connectivity, capable of initiating and terminating IP
          telephony signaling protocols, and capable of initiating and
          terminating telephone network signaling protocols.

        o End User (EU): An entity with IP connectivity which wishes to
          place a call from an IP network to a user connected only via a
          telephone network. The end user can be an individual at a PC,
          an intelligent IP peripheral, or a local gateway for a phone
          to phone IP telephony call.

        o Gatekeeper: The H.323 gatekeeper element, defined in [1]

        o SIP Server: The Session Initiation Protocol proxy server,
          defined in [2].

        o Signaling Server: A signaling server is an entity which is
          capable of receiving signaling messages for some IP telephony
          signaling protocol, such as H.323 or SIP, and forwarding the
          signaling messages to another signaling server or gateway.
          Generally speaking, a gatekeeper or SIP server.

        o Location Server (LS): A logical entity with IP connectivity
          which has knowledge of gateways that can be used to terminate
          calls towards the PSTN. The LS is the main entity that parti-
          cipates in the gateway location protocol. The LS is generally
          a point of contact for end users for completing calls to the
          telephony network. An LS may also be responsible for propaga-
          tion of gateway information to other LS's. An LS may be
          coresident with an H.323 gatekeeper or SIP server, but this is



J.Rosenberg,H.Schulzrinne                                     [Page 2]


Internet Draft               GLP framework             February 11, 1999


          not required.

        o Administrative Domain: The set of gateways and Location
          Servers under the control of a single administrative author-
          ity. End users are customers of an administrative domain.

        o Location Server Policy: The set of rules which dictate how a
          location server processes information it receives via GLP.
          This includes rules for aggregating, propagating, generating,
          and accepting information.

        o End User Policy: Preferences that an end user has about how a
          call towards the PSTN should be routed.

4 Architecture

   Figure 1 gives the overall architectural perspective of the gateway
   location protocol.


              AD1                                AD2
         -----------------                ------------------
        |                  |             |                  |
        |  ----            |             |           ----   |
        | | GW |           |             |          | EU |  |
        |  ----    ----   |             |  ----  /  ----   |
        |          | LS | ---------------- | LS |           |
        |  ----     ----   |             /  ----    ----   |
        | | GW | /         |            /|          | EU |  |
        |  ----            |           / |           ----   |
        |                  |          /  |                  |
         ------------------          /    ------------------
                                    /
                                   /
                        --------- /----------
                       |         |           |
                       |        ----         |
                       |       | LS |        |
                       |     /  ----        |
                       |  ----   ||   ----   |
                       | | GW |  ||  | EU |  |
                       |  ----   ||   ----   |
                       |  ----   ||   ----   |
                       | | GW | /   | EU |  |
                       |  ----        ----   |
                       |                     |
                        ---------------------
                                 AD3



J.Rosenberg,H.Schulzrinne                                     [Page 3]


Internet Draft               GLP framework             February 11, 1999


                          Figure 1: GLP Architecture



   There are a number of administrative domains (AD's), each of which
   has at least one Location Server (LS). The LS's, through an out of
   band means, called the intra-domain protocol, learn about the gate-
   ways in their domain. The intra-domain protocol is represented by the
   lines between the GW and LS elements in AD1 in the Figure. The LS's
   have connections with other LS's, over which they exchange gateway
   information. These connections are established administratively, and
   are set up when the administrative domains have some kind of agree-
   ments in place regarding exchange of gateway information. In the fig-
   ure, the LS in AD1 is connected to the LS in AD2, which is in turn
   connected to the LS in AD3. Through the gateway location protocol
   (GLP), the LS in AD2 learns about the two gateways in AD1. This
   information is accessed by end users (EUs) in AD2 through the front-
   end. The front-end is a non-GLP protocol or mechanism by which EUs
   access the information. In AD3, there are both EUs and gateways. The
   LS in AD3 learns about the gateways in AD1 through a potentially
   aggregated advertisement from the LS in AD2.

   The GLP is similar in flavor to inter-domain routing protocols, such
   as BGP [3]. However, it differs in that the connectivity being
   expressed is not network level, but represents application level
   relationships. Furthermore, attributes play a more important role
   here than in BGP because the protocol is an application, not network,
   layer protocol.

5 Elements

   The system for gateway location consists of a number of elements.
   These include the administrative domain, end user, gateway, and loca-
   tion server.

5.1 Administrative Domain

   An administrative domain consists of zero or more gateways, at least
   one Location Server, and zero or more end users. The gateways and
   LS's are those which are under the administrative control of a single
   authority. This means that there is one authority responsible for
   dictating the policies and configuration of the gateways and LS's.

   An administrative domain may not be the same as an autonomous system.
   While an AS represents a set of physically connected networks, an
   administrative domain may consist of elements on disparate networks,
   and even within disparate autonomous systems.




J.Rosenberg,H.Schulzrinne                                     [Page 4]


Internet Draft               GLP framework             February 11, 1999


   The end users within an administrative domain are effectively the
   customers of that administrative domain. They are interested in com-
   pleting calls towards the telephone network, and thus need access to
   gateways. An end user may be a customer of one administrative domain
   for one call, and then a customer of a different one for the next
   call.

   An administrative domain may not have any gateways. In this case, its
   LS learns about gateways in other domains, and makes these available
   to the end users within its domain. In this case, the administrative
   domain is effectively a virtual IP telephony gateway provider. This
   is because it provides gateway service, but may not actually own or
   administer any gateways.

   An administrative domain may not have any end users. In this case, it
   provides "wholesale" gateway service, making its gateways available
   to customers in other administrative domains.

5.2 Gateway

   A gateway is a logical device which has both IP connectivity and con-
   nectivity to some other network, usually a public or private tele-
   phone network. The function of the gateway is to translate the media
   and signaling protocols from one network technology to the other,
   achieving a transparent connection for the users of the system.

   A gateway has a number of attributes which characterize the service
   it provides. Most fundamental among these are the range of phone
   numbers to which it is willing to provide service. This range may be
   broken into subranges, and associated with each, some cost metric or
   cost token. This token indicates some notion of cost or preference
   for completing calls for this set of the telephone number range.

   Question - can this actually be a "dollar" cost value? There are
   serious issues with trying to do this. Cost plans can be arbitrarily
   complex, and be based on many different currencies. Should we provide
   some simple cost structures (unit of currency per unit time and flat
   rate), or just use a preference, much like a weight metric associated
   with a route.

   A gateway has attributes which characterize the volume of service
   which it can provide. These include the number of ports it has (i.e.,
   the number of simultaneous phone calls it can support), and the
   access link speed. These two together represent some notion of the
   capacity of the gateway. The metric is useful for allowing Location
   Servers to decide to route calls to gateways in proportion to the
   value of the metric, thus achieving a simple form of load balancing.




J.Rosenberg,H.Schulzrinne                                     [Page 5]


Internet Draft               GLP framework             February 11, 1999


   A gateway also has attributes which characterize the type of service
   it provides. This includes, but is not limited to, signaling proto-
   cols supported, telephony features provided, speech codecs under-
   stood, and encryption algorithms which are implemented. These attri-
   butes may be important in selecting a gateway. In the absence of
   baseline required features across all gateways (an admirable, but
   difficult goal), such a set of attributes are required in order to
   select a gateway with which communications can be established. End
   users which have specific requirements for the call (such as a user
   requesting a business class call, in which case certain call features
   may need to be supported) may wish to make use of such information as
   well.

5.3 End Users

   An end user is an entity which wishes to complete a call through a
   gateway from an IP network to a terminal on a telephone network. An
   end user may be a user logged on at a PC with some Internet telephony
   software. The end user may also be a telephone gateway, dialed by a
   user from telephone handset. This is the case for the phone to phone
   service using the IP network for long distance transport.

   End users may, or may not be aware that there is a gateway location
   service running when they complete a call towards the telephone net-
   work. In cases where they are aware, end users may have preferences
   for how a call is completed. These preferences might include call
   features which must be supported, quality metrics, owner or adminis-
   trator, and cost preferences.

5.4 Location Server

   The Location Server (LS) is the main functional entity of the gateway
   location protocol. It is a logical device which has access to a data-
   base of gateways, and participates in the gateway location protocol.
   As a participant, its job is to receive information about gateways
   from other Location Servers, send information to other Location
   Servers about gateways it knows about, and to aggregate and forward
   information about gateways to other LS's.

   The database built up in the LS allows it to make decisions about IP
   telephony call routing. When a signaling message arrives at a signal-
   ing server, destined for a telephone network address, the LS's data-
   base can provide information which is useful for determining a gate-
   way or an additional signaling server to forward the signaling mes-
   sage to. For this reason, an LS may be coresident with a signaling
   server.

   An LS is a representative for an administrative domain. An



J.Rosenberg,H.Schulzrinne                                     [Page 6]


Internet Draft               GLP framework             February 11, 1999


   administrative domain must have at least one LS in order to partici-
   pate in the gateway location protocol. An administrative domain may
   have more than one LS, for purposes of load balancing, ease of
   management, or any other reason.

   One or more of the LS's in an administrative domain may have
   knowledge of the gateways run by the administrative domain. This
   knowledge may be configured statically, learned through other proto-
   cols, or acquired through GLP by placing an LS coresident with the
   gateway, allowing the gateway to participate in GLP.

   The information learned from other LS's may be used by an LS to aid
   in routing calls which originate or transit through the administra-
   tive domain.

   A LS may be coresident with an H.323 gatekeeper, SIP server, or MGCP
   call agent, but this need not be the case. When they are not
   coresident, some means of communication between the LS and the
   server, gatekeeper, or call agent is needed. This communication is
   not addressed by the GLP.

6 Element Interactions

6.1 Gateways and Location Servers

   Gateways must somehow propagate information about their characteris-
   tics to an LS within the same AD which will further propagate this
   information outside of the AD. That LS is called an originating LS
   for that gateway. When an LS is not coresident with the gateway, the
   means by which the information gets propagated is not within the
   scope of the gateway location protocol. The protocol used to accom-
   plish this is generally called an intra-domain protocol.

   One way in which the information can be propagated is with the Ser-
   vice Location Protocol (SLP) [4]. The gateway can contain a Service
   Agent (SA), and the LS can act as a Directory Agent (DA). SLP defines
   procedures by which service information is automatically propagated
   to DA's from SA's. In this fashion, an LS can learn about gateways in
   the administrative domain.

   An alternate mechanism for the intra-domain protocol is via the
   registration procedures of SIP or H.323. The registration procedures
   provide a means by which users inform a gatekeeper or SIP server
   about their address. Such a registration procedure could be extended
   to allow a gateway to effectively register as well.

   Other means exist as well. These might include LDAP [5], email, web
   page, or human based means, such as a phone call or letter. The



J.Rosenberg,H.Schulzrinne                                     [Page 7]


Internet Draft               GLP framework             February 11, 1999


   mechanism which is used may be different from administrative domain
   to administrative domain, and is a matter of local configuration. The
   only requirement for the gateway location protocol to operate effec-
   tively is that this mechanism exist in some form.

6.2 Location Server to Location Server

   The interaction between LS's in adjacent AD's is what is defined by
   the gateway location protocol. LS's within the same administrative
   domain may use the protocol as well, but its focus is on inter-domain
   LS communications.

   LS's communicate with each other through TCP connections. An LS may
   be connected to one or more other LS's. LS's need not be physically
   adjacent or part of the same autonomous system. The TCP connection
   between a pair of LS's is set up administratively. There is no auto-
   discovery procedure. Two LS's are configured to communicate with each
   other when their administrators have an agreement in place to
   exchange gateway information. The syntax and semantics of the mes-
   sages exchanged over this connection are dictated by the gateway
   location protocol. The protocol does not dictate the nature of the
   agreements which must be in place, nor does it dictate what informa-
   tion is actually exchanged. The GLP merely provides a transport means
   to exchange whatever information is deemed appropriate by the
   administrators of the system.

   The rules which govern which gateway information is generated, pro-
   pagated, and accepted by a gateway is called a location server pol-
   icy. The gateway location protocol does not dictate or mandate any
   specific policy.

   When an LS learns about a gateway within its AD through some means
   outside of the gateway location protocol, and then propagates this
   information to other LS's through the gateway location protocol, that
   LS is said to be an originating LS for that gateway. This means that
   the LS is responsible for determining when an update about the gate-
   way should be sent.

   Although GLP is an inter-domain protocol, it may be used between LS's
   within the same administrative domain.

6.2.1 Nature of Exchanged Information

   The information exchanged by the LS's is a set of routing objects.
   Each routing object minimally consists of a range of telephone
   numbers which are reachable, and an IP address which is the next hop
   towards a gateway which can reach that range. Routing objects are
   learned from the intra-domain protocol, or from LS's in remote AD's.



J.Rosenberg,H.Schulzrinne                                     [Page 8]


Internet Draft               GLP framework             February 11, 1999


   An LS may aggregate these routing objects together, merging ranges of
   telephone numbers, and replacing the IP address with its own IP
   address, or with the IP address of a signaling server with which the
   LS is communicating, and then propagate them to another LS. The deci-
   sion about which objects to propagate is known as a route selection
   operation. How the decision is made is at the discretion of the
   administrator, and is embodied in the LS policy. The decision can be
   made based on information learned through the GLP, or through any out
   of band means.

   Consider a simple example of two gateways, A and B, capable of reach-
   ing some set of telephone numbers, X and Y, respectively. C is an LS
   for the administrative domain in which A and B are resident. C learns
   of A and B through some other means. As it turns out, X and Y can be
   combined into a single address range, Z. C has several options. It
   can propagate just the advertisement for A, just the advertisement
   for B, propagate both, or combine them and propagate the aggregate
   advertisement. In this case C chooses the latter route, and sends a
   single routing object to one of its peers, D, containing address
   range Z and its own address, since it is also a signaling server. D
   is also a signaling server.

   Some client, E, wishes to place a phone call to telephone number T,
   which happens to be in the address range X. E is configured to use D
   as its default H.323 gatekeeper. So, E sends a call setup message to
   D, containing destination address T. D determines that the address T
   is within the range Z. As D had received a routing object from C con-
   taining address range Z, it forwards the call setup message to C. C,
   in turn, sees that T is within range X, and so it forwards the call
   setup to A, which terminates the call signaling and initiates a call
   towards the telephone network.

   A routing object may have additional information which characterizes
   the service at the gateway. These attributes include things like pro-
   tocols, features supported, capacity, and cost metrics. Greater
   numbers of attributes can provide useful information, however, they
   come at a cost. Aggregation becomes difficult with more and more
   information, impacting the scalability of the protocol. The GLP will
   need to strike a reasonable balance between utility of information
   and scalability.

6.2.2 Quality of Service

   One of the factors which is useful to consider when selecting a gate-
   way is "QoS" - will a call through this gateway suffer sufficiently
   low loss, delay, and jitter? The quality of a call depends on two
   components - the QoS on the path between the caller and gateway, and
   the capacity of the gateway itself (measured in terms of number of



J.Rosenberg,H.Schulzrinne                                     [Page 9]


Internet Draft               GLP framework             February 11, 1999


   circuits available, link capacity, DSP resources, etc.). Determina-
   tion of the latter requires intricate knowledge of underlying network
   topologies, and of where the caller is located. This is something
   handled by QoS routing protocols, and is outside the scope of GLP.

   However, gateway capacity is not dependent on the caller location or
   path characteristics. For this reason, a capacity metric of some form
   is supported by the GLP. LS's can use it as a means of load balancing
   of calls among gateways. However, the capacity metric can only be
   used for purposes of comparing the relative capacities of two gate-
   ways, and not for learning the absolute number of calls which may be
   routed to a gateway from the LS. This is because multiple LS's may
   receive this metric.

6.2.3 Cost Information

   Another useful attribute to propagate is cost metrics. These might
   represent the amount a particular gateway might charge for a call.
   Unfortunately, the set of cost structures is potentially unbounded,
   ranging from the simple (flat rate), to the arbitarily complex (time
   and caller dependent, past usage dependent, destination dependent,
   etc.). For this reason, the GLP does not attempt to define specific
   cost structures. Rather, it provides hooks that allow service provid-
   ers to use any cost structure they like.

6.2.4 Determining when to send an object

   An LS is free to send an updated routing object at its discretion.
   Normally, an update is sent if (1) the LS is an originating LS, and
   the attributes or state of the gateway has changed, (2) the LS has
   received an updated object, and wishes to propagate it or change
   other objects which it created as a result of aggregation, (3) the
   policy of the LS has changed.

6.3 End Users and Location Servers

   The interaction between the end users and location servers is also
   outside the scope of the gateway location protocol. This interaction
   is referred to as the front-end, as it provides the visible means by
   which the gateway location protocol services are exposed.

   A front end is required when an administrative domain has end users,
   and these end users wish to complete calls to a telephone network
   address. This can happen when a user sitting at a PC types a tele-
   phone number into their IP telephony software, or when an ingress
   gateway receives a call from a telephone wishing to complete a call
   to another telephone. In both cases, the end user must determine
   where to send its signaling messages in order to complete the call.



J.Rosenberg,H.Schulzrinne                                    [Page 10]


Internet Draft               GLP framework             February 11, 1999


   In some cases, the end user may have requirements about how they
   would like the call to be routed. These include preferences about
   cost, quality, administrator, or call services and protocols. These
   requirements are called the end user policy. This policy is distinct
   from the location server policy. The location server policy includes
   the providers preferences about which gateways to accept and make
   available to its customers: the end users in its administrative
   domain. The location server policy effectively takes the set of all
   available gateways, and distills them into a list which is acceptable
   to the provider. The end user policy may then be used to select among
   those gateways. When an end user policy is expressed, it is the dis-
   cretion of the administrator whether to use or modify this policy
   when selecting a gateway.

   There are two models for the front end. These are called direct and
   proxy modes.

6.3.1 Direct Mode

   In direct mode, the end user is aware that the call needs to ter-
   minate on the telephone network, and it directly queries one of the
   LS's within the administrative domain for the address of a gateway or
   signaling server which can route the call. This query can contain
   policy from the end user, or can just contain the telephone number
   which is desired. The LS receives the query, and after consulting its
   database, and any existing policy, returns zero or more addresses to
   the end user. The response to the end user may also contain parame-
   ters or attributes of the gateway if they are known.

   Many protocols may be used for direct mode access. The Service Loca-
   tion Protocol (SLP) is one example; its been designed to fit exactly
   this kind of need. The end user is an SLP UA, and the LS is an SLP
   DA. The Service Query is used to ask for a gateway with a particular
   set of attributes (i.e., policy).

   Other means exist. The web can be used, either through some kind of
   search engine running based on the data at the LS, or through dynamic
   web pages created from the LS database. This search could be
   automated or more interactive, as is normally done with web searches.

   Once a response is received, the end user can send its call setup
   message to the signaling server or gateway indicated in the response.

   The advantage of direct mode is that it gives the end user the abil-
   ity to specify call by call policy. The policy can be arbitrarily
   complex, depending on the services provided by the front end. The
   disadvantage is that it requires more intelligence in the end user.
   This may not be appropriate for embedded devices, for example.



J.Rosenberg,H.Schulzrinne                                    [Page 11]


Internet Draft               GLP framework             February 11, 1999


6.3.2 Proxy Mode

   In proxy mode, the end user doesn't worry about selecting or querying
   for a gateway. The call setup message is sent to a proxy, either the
   location server, or a signaling server which has access to the data-
   base maintained by the LS. The LS or signaling server receives the
   setup message, sees that it is to a gateway, and consults the data-
   base to find the appropriate next hop signaling server or gateway to
   terminate the call. This procedure happens transparently to the end
   user.

   As part of the selection process, the LS or signaling server may
   access a policy database containing preferences specified by the end
   user ahead of time. For example, a PC user may tell the administra-
   tors that they would like calls towards the PSTN to be routed to
   gateways run by provider X, or that calls should use the cheapest
   gateway. When the LS or signaling server receives the call setup mes-
   sage, this information can be taken into account when selecting a
   next hop.

   Additionally, the signaling messages may themselves contain end user
   preferences about call routing.

   The proxy mode front end is appropriate for thin clients, which can-
   not express policy requirements on their own. It is also appropriate
   when the administrator wants complete control over gateway selection.
   It also has the advantage of making the fact that the call is a gate-
   way call transparent to the end user.

7 Security Considerations

   There are a number of security requirements. First and foremost is
   mutual authentication between LS's which are connected. This may be
   through either public key or shared secret. Additionally, message
   integrity of all exchanges is required. Encryption of messages is
   also supported.

   As routing objects can be passed via one LS to another, there is a
   need for some sort of end to end authentication as well. However,
   aggregation will cause the routing objects to be modified, and there-
   fore authentication can only take place from the point of last aggre-
   gation to the receiving LS's.

8 Conclusion

   This document has provided a framework for a gateway location proto-
   col. The major elements, and the relationships and protocols between
   them, have been described.



J.Rosenberg,H.Schulzrinne                                    [Page 12]


Internet Draft               GLP framework             February 11, 1999


9 Bibliography

   [1] International Telecommunication Union, "Visual telephone systems
   and equipment for local area networks which provide a non-guaranteed
   quality of service," Recommendation H.323, Telecommunication Stan-
   dardization Sector of ITU, Geneva, Switzerland, May 1996.

   [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Internet Draft, Internet Engineering
   Task Force, Nov. 1998.  Work in progress.

   [3] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4),"
   Request for Comments (Draft Standard) 1771, Internet Engineering Task
   Force, Mar. 1995.  (Obsoletes RFC1654).

   [4] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, "Service
   location protocol," Request for Comments (Proposed Standard) 2165,
   Internet Engineering Task Force, June 1997.

   [5] W. Yeong, T. Howes, and S. Kille, "Lightweight directory access
   protocol," Request for Comments (Draft Standard) 1777, Internet
   Engineering Task Force, Mar. 1995.  (Obsoletes RFC1487).

10 Authors Addresses


   Jonathan Rosenberg
   Lucent Technologies, Bell Laboratories
   101 Crawfords Corner Rd.
   Holmdel, NJ 07733
   Rm. 4C-526
   email: jdrosen@bell-labs.com

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: schulzrinne@cs.columbia.edu












J.Rosenberg,H.Schulzrinne                                    [Page 13]