Internet DRAFT - draft-dcsgroup-sipping-arch

draft-dcsgroup-sipping-arch




SIPPING Working Group                           W. Marshall 
Internet Draft                                  AT&T 
Document: <draft-dcsgroup-sipping-arch-01.txt>   
Category: Informational                         M. Osman 
                                                CableLabs 
                                                 
                                                F. Andreasen 
                                                Cisco 
                                                 
                                                D. Evans 
                                                ARRIS 
                                                 
                                                January 15, 2003 
    
    
    Architectural Considerations for Providing Carrier Class Telephony 
        Services Utilizing Session Initiation Protocol (SIP)-based 
                    Distributed Call Control Mechanisms 
    
    
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. 
    
Abstract 
    
   This document provides an overview of a SIP-based Distributed Call 
   Signaling (DCS) architecture to support carrier class packet-based 
   voice, video, and other real time multimedia services.  Companion 
   documents address a specific set of SIP 2.0 protocol extensions and 
   usage rules that are necessary to implement the DCS architecture in 
   an interoperable fashion. 
    
   The DCS architecture takes advantage of endpoint intelligence in 
   supporting telephony services without sacrificing the network's 
   ability to provide value through mechanisms such as resource 
   management, lookup of directory information and translation 
   databases, routing services, security, and privacy enforcement.  At 
   the same time, the architecture provides flexibility to allow 
  
DCS Group   Category: Informational - Expiration 04/30/03           1 

                           DCS Architecture               October 2002 
 
 
   evolution in the services that may be provided by endpoints and the 
   network. 
    
   DCS also takes into account the need to manage access to network 
   resources and account for resource usage.  The SIP usage rules 
   defined in the accompanying IDs specifically address the 
   coordination between Distributed Call Signaling and dynamic quality 
   of service control mechanisms for managing resources over the access 
   network.  In addition, the DCS architecture defines the interaction 
   needed between network provided call controllers, known as a "DCS-
   proxy" for supporting these services. 
    
Table of Contents 
    
   Status of this Memo................................................1 
   Abstract...........................................................1 
   Table of Contents..................................................2 
   1. Introduction....................................................2 
   2. Background and Motivation.......................................3 
   2.1 Requirements And Design Principles.............................4 
   2.2 Distributed Call Signaling Architecture........................6 
   2.3 Trust Boundary.................................................9 
   2.4 Basic Call Flow................................................9 
   3. Resource Management............................................12 
   4. Distributed Call State.........................................13 
   5. DCS Proxy - DCS Proxy Communications...........................15 
   6. Privacy........................................................16 
   7. Security Considerations........................................18 
   8. Notice Regarding Intellectual Property Rights..................18 
   9. Informative References.........................................18 
   10. Acknowledgements..............................................19 
   11. Author's Addresses............................................19 
   Full Copyright Statement..........................................21 
   Acknowledgement...................................................21 
    
1. Introduction 
    
   This document provides an overview of a SIP[6]-based Distributed 
   Call Signaling (DCS) architecture to support carrier class packet-
   based voice, video, and other real time multimedia services.  The 
   DCS architecture and the corresponding SIP protocol enhancements 
   (described in companion documents) are being developed as part of 
   the cable industry's PacketCable initiative, managed out of 
   CableLabs (see www.cablelabs.com). PacketCable is defining a series 
   of interface specifications that will enable vendors to develop 
   interoperable products for providing internet telephony and other 
   multimedia services over DOCSIS-enabled cable data networks.   
   The DCS architecture described herein has its roots in the DOSA work 
   performed by AT&T Laboratories ["Distributed Open Signaling 
   Architecture"; Kalmanek, Marshall, Mishra, Nortz, Ramakrishnan, et 
   al.; October, 1998]. A relatively large group of vendors have 
   cooperated in an intensive effort to develop the DCS architecture 
   and SIP protocol extensions described here and in the accompanying 
  
DCS Group   Category: Informational - Expiration 04/30/03           2 

                           DCS Architecture               October 2002 
 
 
   protocol drafts.  Although DCS was originally designed with cable 
   access networks in mind, the SIP signaling enhancements have general 
   applicability to carrier class Voice over IP (VoIP) services running 
   over Quality of Service (QoS) enabled IP networks. 
    
   The authors have submitted this document to the IETF in order to 
   provide general information regarding the DCS architecture and to 
   convey the motivation behind the SIP enhancements recommended in the 
   accompanying protocol drafts.  We believe that providing SIP 
   extensions for the concepts and mechanisms described in this set of 
   drafts will significantly enhance SIP's ability to function as a 
   carrier-class signaling protocol.  Such an enhancement to SIP would 
   undoubtedly aid in its widespread acceptance and deployment. We have 
   incorporated several useful comments received from the IETF SIP and 
   SIPPING Working groups on earlier versions of this and the other DCS 
   related drafts.  
    
   The PacketCable Draft Specification for DCS is available from the 
   CableLabs website at: 
        
       ftp://ftp.cablelabs.com/pub/pkt-sp-dcs-d03-000428.pdf 
    
2. Background and Motivation 
 
   The design of the Distributed Call Signaling (DCS) architecture 
   recognizes the trend towards use of packet networks as the 
   underlying framework for communications.  These networks will 
   provide a broad range of services, including traditional best-effort 
   data service as well as enhanced, value-added services, such as 
   telephony. At the same time, improvements in silicon will reinforce 
   the trend towards increased functionality in endpoints.  These 
   intelligent endpoints will take advantage of the widespread 
   availability of packet networks to enable a rich set of applications 
   and services for users.  
    
   However, when the network is used for real-time telephony 
   applications, it is essential to have service differentiation at the 
   IP layer.  The ability to control and monitor usage is needed for 
   the provider to be able to provide service differentiation and to 
   derive revenue from the enhanced services.  At the same time, the 
   availability of best effort communications and the migration of 
   functionality to the endpoints pose a challenge to the provider to 
   find incentives for users to use or pay for enhanced services.    
    
   We see three key functions that a provider can offer, as incentives 
   to use enhanced services.  First, the network service provider has 
   the unique ability to manage and provide network layer quality of 
   service.  When users depend on the quality of the service, as with 
   telephony, there is a strong incentive to use the enhanced service, 
   rather than a best effort service.  Second, the network service 
   provider can play an important role as a trusted intermediary.  This 
   includes ensuring the integrity of call routing, as well as ensuring 
   both the accuracy and the privacy of information that is exchanged.   
  
DCS Group   Category: Informational - Expiration 04/30/03           3 

                           DCS Architecture               October 2002 
 
 
   The service provider can also add value by ensuring that services 
   are provided consistently and reliably, even when an endpoint is 
   unavailable.  Finally, there are a number of services that may be 
   offered more efficiently by the network service provider rather than 
   in endpoints.  For example, conference bridging may be more cost 
   effective to implement in a multi-point bridge rather than in every 
   endpoint attached to the network.  
    
   A key contribution of the DCS architecture is a recognition of the 
   need for coordination between call signaling, which controls access 
   to telephony specific services, and resource management, which 
   controls access to network-layer resources. This coordination is 
   designed to meet the user expectations and human factors associated 
   with telephony.   For example, the called party should not be 
   alerted until the resources necessary to complete the call are 
   available.  If resources were not available when the called party 
   picked up, the user would experience a call defect.   In addition, 
   users expect to be charged for service only after the called party 
   answers the phone.  As a result, usage accounting starts only after 
   the called party picks up.  Coordination between call signaling and 
   resource management is also needed to prevent fraud and theft of 
   service.  The coordination between DCS and Dynamic QoS protocols 
   ensures that users are authenticated and authorized before receiving 
   access to the enhanced QoS associated with the telephony service. 
    
   It is important to be able to deploy a residential telephone service 
   at very large scale, cost-effectively.   To achieve this, DCS 
   minimizes the messaging overhead on network call servers, and does 
   not require these servers to maintain call state for active calls.   
   Once a call is established, call state is maintained only where it 
   is needed, in keeping (informally) with the principle of "fate-
   sharing" at the endpoints that are involved in the call, and at the 
   Edge Routers in the bearer path that are providing differentiated 
   service to the media flow.  This allows the network call servers to 
   scale to support more users, and imposes less stringent reliability 
   requirements on those servers.   
    
   DCS is also designed so that calling users receive consistent 
   service even when a called endpoint is unavailable.  For example, 
   when an endpoint is unavailable, service logic in a network call 
   server can forward telephone calls to a voice mailbox.  
    
2.1 Requirements And Design Principles 
 
   In this section, we briefly describe the application requirements 
   that led to a set of DCS signaling design principles.  In its most 
   basic implementation, DCS supports a residential telephone service 
   comparable to the local telephone services offered today.  In 
   addition to the commonly used service features that need to be 
   supported, there are important requirements in the areas of 
   reliability, performance, and scalability that influence the 
   signaling architecture. Supporting an IP telephony service 

  
DCS Group   Category: Informational - Expiration 04/30/03           4 

                           DCS Architecture               October 2002 
 
 
   comparable to the telephony service offered today requires enhanced 
   bearer channel and signaling performance, including: 
    
   . Low delay - end-to-end packet delay must be small enough that it 
     does not interfere with normal voice conversations. The ITU 
     recommends no greater than 300 ms roundtrip delay for telephony 
     service.  
    
   . Low packet loss - packet loss must be small enough to not 
     perceptibly impede voice quality or performance of fax and voice 
     band modems. 
    
   . Short post-dial delay - the delay between the user dialing the 
     last digit and receiving positive confirmation from the network 
     must be short enough that users do not perceive a difference with 
     post-dial delay in the circuit switched network or believe that 
     the network has failed. 
    
   . Short post pickup delay - the delay between a user picking up a 
     ringing phone and the voice path being cut through must be short 
     enough so that the "hello" from either the initiator or the 
     receiver of the call is not clipped. 
 
   We identify a number of key design principles that arise from the 
   requirements and philosophy outlined above:  
    
   1. It is essential to provide differentiated network-layer quality of 
     service, while allowing the provider to derive revenues from the 
     use of such differentiated services. 
    
   2. The architecture should allow, and even encourage, implementation 
     of services and features in the intelligent endpoints, where 
     economically feasible, while still retaining value in the network 
     and network-based services. 
    
   3. The architecture must ensure that the network is protected from 
     fraud and theft of service. The service provider must be able to 
     authenticate users requesting service and ensure that only those 
     authorized to receive a particular service be able to obtain it. 
    
   4. The architecture must enable the service provider to add value by 
     supporting the functions of a trusted intermediary. This includes 
     protecting the privacy of calling and called party information, 
     and ensuring the accuracy of the information that is provided in 
     messages from the network. 
    
   5. The architecture must enable the service provider to give a 
     consistent view of basic services and features even when customer 
     premise equipment is unavailable, and allow users to take 
     advantage of functionality that is provided in the network, when 
     it is cost-effective and easy to use. 
    

  
DCS Group   Category: Informational - Expiration 04/30/03           5 

                           DCS Architecture               October 2002 
 
 
   6. The architecture must be implementable, cost-effectively, at very 
     large scale. 
    
2.2 Distributed Call Signaling Architecture 
 
   The Distributed Call Signaling Architecture follows the principles 
   outlined above to support a robust telephony service. Figure 1 
   introduces the key components in the architecture.   
    
   The architecture assumes a broad range of DCS-compliant endpoints 
   that provide telephony service to the user including Media Terminal 
   Adapters (MTAs) that may be integrated with a Cable Modem or is a 
   standalone device, as well as other endpoints such as personal 
   computers. The access network interfaces to an IP backbone through a 
   system we refer to as the Edge Router (ER). The ER is the first 
   trusted element within the provider's network and is considered to 
   be the edge of the network for providing access to differentiated 
   quality of service. We believe that the access network is likely to 
   manage resources on a per-flow basis, with associated signaling 
   mechanisms (such as RSVP). The ER performs resource management, acts 
   as a policy enforcement point and as a source of billing 
   information. 
    
   DCS-proxies (DPs) process call signaling messages and support number 
   translation, call routing, feature support and admission control.  
   In the context of SIP, a DCS-proxy is a SIP proxy that is involved 
   in processing and forwarding of SIP requests. DPs act as trusted 
   decision points for controlling when resources are committed to 
   particular users. Media servers represent network-based components 
   that operate on media flows to support the service. Media servers 
   perform audio bridging, play terminating announcements, provide 
   interactive voice response services, etc. Finally, PSTN gateways 
   interface to the Public Switched Telephone Network. 
 
 
 
 
 
 
 
 
 
 










  
DCS Group   Category: Informational - Expiration 04/30/03           6 

                           DCS Architecture               October 2002 
 
 
                 +-----+ 
                 | MTA |                MTA: media terminal adapter 
                 +-----+ 
                    |                   ER: Edge Router 
    Access Network  |  
                    | 
                 +----+ 
                 | ER | 
                 +----+ 
                    |    +-----------+ 
                    |----| DCS Proxy | 
                    |    +-----------+ 
                    | 
                    |    +------------+    
  Backbone Network  |----|Media Server| 
                    |    +------------+  
                    | 
                    |    +------------+    
                    |----|PSTN Gateway| 
                    |    +------------+  
                 +----+ 
                 | ER | 
                 +----+ 
                    | 
    Access Network  |  
                    | 
                 +-----+ 
                 | MTA | 
                 +-----+ 
         Figure 1: A Simple view of Components of an IP Telephony 
               Architecture used in a HFC Cable Environment. 
                                      
   Telephony endpoints are considered to be "clients" of the telephony 
   service. Consistent with the design principles, the architecture 
   allows a range of services to be implemented by intelligent 
   endpoints. They collect dialed digits, participate in signaling and 
   contain the service logic required for basic call setup and feature 
   support. Endpoints also participate in end-to-end capability 
   negotiation. However, endpoints are not trusted to provide accurate 
   information to the network or to keep information that is received 
   private, except when it is in the endpoint's best interests to do 
   so.  
    
   Access to network resources on a differentiated basis is likely to 
   be controlled by the service provider. The ER receives resource 
   management requests from endpoints, and is responsible for ensuring 
   that packets are provided the QoS they are authorized to receive 
   (either through packet marking, or through routing and queuing the 
   packets as a specific QoS assured flow).  The ER requires 
   authorization from a network entity (on a call-by-call basis for the 
   telephony service) before providing access to enhanced QoS for an 
   end-to-end IP flow. The obvious point where this policy and control 
   function resides is the DCS-proxy (also called a gate-controller, 
  
DCS Group   Category: Informational - Expiration 04/30/03           7 

                           DCS Architecture               October 2002 
 
 
   because of this responsibility for managing access to enhanced QoS). 
   Thus, the ER is able to ensure that enhanced QoS is only provided 
   for end-to-end flows that have been authorized and for which usage 
   accounting is being done. Since the ER knows about the resource 
   usage associated with individual IP flows, it generates the usage 
   events that allow a user to be charged for service.  
    
   We introduce the concept of a "gate" in the ER, which manages access 
   to enhanced quality of service. The gate is a packet classifier and 
   policer that ensures that only those IP flows that have been 
   authorized by the DCS-proxy are granted access to enhanced QoS in 
   the access and backbone networks. Gates are "opened" selectively for 
   a flow. For the telephony service, they are opened for individual 
   calls. Opening a gate involves an admission control check that is 
   performed when a resource management request is received from the 
   endpoint for an individual call, and it may involve resource 
   reservation in the network for the call if necessary. The packet 
   filter in the gate allows a flow of packets to receive enhanced QoS 
   for a call from a specific IP source address and port number to a 
   specific IP destination address and port number.  
    
   The DCS-proxy, in addition to implementing many of the call control 
   functions, is responsible for the policy decision regarding whether 
   the gate should be opened. DCS sets up a gate in advance of a 
   resource management message. This allows the policy function, which 
   is at the DCS-proxy, to be "stateless" in that it does not need to 
   know the state of calls that are already in progress.  
    
   DCS-proxies are typically organized in domains. A DCS-proxy is 
   responsible for a set of endpoints and the associated ERs. While 
   endpoints are not trusted, there is a trust relationship between the 
   ER and its associated DCS-proxy, since the DCS-proxy plays a role as 
   a policy server controlling when the ER can provide enhanced QoS 
   service. There is also a trust relationship among DCS-proxies. 
   Details of the security model are outside the scope of this draft. 
    
   The DCS-proxy is designed as a simple transaction server, so that 
   the failure of a DCS-proxy does not affect calls in progress. A 
   domain will likely have a primary and one or more secondary DCS-
   proxies. If the primary DCS-proxy fails, only calls in a transient 
   state are affected. The endpoints involved in those calls will time 
   out and retry. All active calls are unaffected. This is possible 
   because the DCS-proxy retains no call state for stable calls. We 
   believe this design makes the DCS-proxy efficient and highly 
   scalable, and keeps the reliability requirements manageable. 
    
   DCS supports inter-working with the circuit switched telephone 
   network through PSTN gateways. A PSTN gateway may be realized as a 
   combination of a media gateway controller, media gateway, and a 
   signaling gateway. A media gateway acts as the IP peer of an 
   endpoint for media packets, converting between the data format used 
   over the IP network and the PCM format required for transmission 
   over the PSTN. The media gateway controller or the signaling gateway 
  
DCS Group   Category: Informational - Expiration 04/30/03           8 

                           DCS Architecture               October 2002 
 
 
   acts as the IP peer of an endpoint for signaling packets, providing 
   signaling inter-working between DCS and conventional telephony 
   signaling protocols such as ISUP/SS7. When the media gateway 
   controller is the peer, it communicates with the signaling gateway. 
   A media gateway control protocol is used to control the operation of 
   the media gateway from the media gateway controller. 
    
   There are additional system elements that may be involved in 
   providing the telephony service. For example, the DCS-proxy may 
   interface with other servers that implement the authorization or 
   translation functions. Similarly, three way calling may be supported 
   using media servers in the network. 
    
2.3 Trust Boundary 
    
   The DCS architecture defines a trust boundary around the various 
   systems and servers that are owned, operated by, and/or controlled 
   by the service provider. These trusted systems include the proxies 
   and various servers such as bridge servers, voicemail servers, 
   announcement servers, etc. Outside of the trust boundary lie the 
   customer premises equipment, and various media servers operated by 
   third-party service providers. 
    
   Certain subscriber-specific information, such as billing and 
   accounting information, stays within the trust boundary. Other 
   subscriber-specific information, such as endpoint identity, may be 
   presented to untrusted endpoints or may be withheld based on 
   subscriber profiles. 
    
   The SIP User Agent (UA) may be either within the trust boundary 
   (e.g. PSTN gateway) or outside the trust boundary (e.g. MTA), 
   depending on exactly what function is being performed and exactly 
   how it is being performed.  Accordingly, the procedures followed by 
   a User Agent, as contained in the accompanying drafts, are different 
   depending on whether the UA is within the trust boundary or outside 
   the trust boundary. A trusted user agent is, in almost all cases, 
   equivalent to the combination of an untrusted user agent and a 
   proxy. 
    
2.4 Basic Call Flow 
    
   Figure 2 presents a high-level overview of a basic MTA-to-MTA call 
   flow in DCS. Each MTA is associated with a DCS-proxy, which acts as 
   a SIP proxy. When a user goes off-hook and dials a telephone number, 
   the originating MTA (MTA-o) collects the dialed digits and sends the 
   initial INVITE message in SIP, to the "originating" DCS-proxy (DP-
   o). This INVITE contains SDP proposing a set of codecs that are 
   acceptable to MTA-o (and their implied bandwidth requirements), and 
   an indication of the (mandatory) QoS preconditions [7] needed for 
   the session. DP-o verifies that MTA-o is a valid subscriber of the 
   telephony service (using authentication information in the INVITE 
   message) and determines whether this subscriber is authorized to 
   place this call. DP-o then translates the dialed number into the 
  
DCS Group   Category: Informational - Expiration 04/30/03           9 

                           DCS Architecture               October 2002 
 
 
   address of a "terminating" DCS-proxy (DP-t) and forwards the INVITE 
   message to it.    
    
   We assume that the originating and terminating DCS-proxies trust 
   each other. DP-o augments the INVITE message that it forwards with 
   additional information, such as billing information containing the 
   account number of the caller. DP-t then translates the dialed number 
   into the address of the terminating MTA (MTA-t) and forwards the 
   INVITE message to MTA-t to notify it about the incoming call.   
    
   The initial INVITE message may invoke call feature handling at the 
   terminating MTA, such as call-forwarding. Assuming that the call is 
   not forwarded, MTA-t negotiates the coding style and bandwidth 
   requirements for the media streams. A reliable provisional 1xx 
   response to the initial INVITE is sent back through the DCS-proxies.  






































  
DCS Group   Category: Informational - Expiration 04/30/03          10 

                           DCS Architecture               October 2002 
 
 
   MTA-o      ER-o       DP-o       DP-t       ER-t      MTA-t 
    
    | INVITE   |          |          |          |          | 
    |----------|--------->| INVITE   |          |          | 
    |          |          |--------->|          |          | 
    |          |          |          |  INVITE  |          | 
    |          |          |          |----------|--------->| 
    |          |          |          |          |  183 SDP | 
    |          |          |          |<---------|----------| 
    |          |          |          |          |          | 
    |          |  Gate    |  183 SDP |Gate Setup|          | 
    |          |  Setup   |<---------|--------->|          | 
    |          |<---------|          |          |          | 
    |  183 SDP |          |          |          |          | 
    |<---------|----------|          |          |          | 
    |          |          | PRACK    |          |          | 
    |----------|----------|----------|----------|--------->| 
    |          |   200 OK (acknowledging PRACK) |          | 
    |<---------|----------|----------|----------|----------| 
    |          |          |          |          |          |  
    |<---------|--------Reserve Resources-------|--------->| 
    |          |          |          |          |          | 
    |          |             UPDATE             |          | 
    |----------|--------- |----------|----------|--------->| 
    |               200 OK (acknowledging UPDATE)          | 
    |<---------|----------|----------|----------|----------| 
    |          |          |          |          | 180 Ring | 
    |          |          | 180 Ring |<---------|----------| 
    |          | 180 Ring |<---------|          |          | 
    |<---------|----------|          |          |          | 
    |          |          | PRACK    |          |          | 
    |----------|----------|----------|----------|--------->| 
    |          |   200 OK (acknowledging PRACK) |          | 
    |<---------|----------|----------|----------|----------| 
    |          |          |          |          |          | User 
    |          |          |          |          |  200 OK  | Answers 
    |          |          |  200 OK  |<---------|----------| 
    |          |  200 OK  |<---------|          |          | 
    |<---------|----------|          |          |          | 
    |   ACK    |          |          |          |          | 
    |----------|----------|----------|----------|--------->| 
    |          |          |          |          |          | 
    |<---------|----------Active  Call----------|--------->| 
    |          |          |          |          |          | User 
    |          |          |          |          |   BYE    | Hangs Up 
    |<---------|----------|----------|----------|----------| 
    |          |          |          |          |  200 OK  | 
    |----------|----------|----------|----------|--------->| 
   Figure 2: A Basic Call Flow, including Resource Management functions 
    
   In the figure, MTA-t sends a 183 SDP message to DP-t. The 183 SDP 
   contains a subset of the capabilities in the INVITE message that are 
   acceptable to MTA-t. The SDP also carries the QoS preconditions from 
  
DCS Group   Category: Informational - Expiration 04/30/03          11 

                           DCS Architecture               October 2002 
 
 
   the INVITE. DP-t sends a GATE-SETUP message to the terminating ER 
   (ER-t), conveying policy instructions allowing ER-t to open a gate 
   for the IP flow associated with this phone call. The GATE_SETUP 
   message contains billing information containing the account number 
   of the subscriber that will pay for the call. 
 
   DP-t forwards the 183 SDP to DP-o. DP-o sends a GATE-SETUP message 
   to the originating ER (ER-o) to indicate that it can open a gate for 
   the IP flow associated with the phone call. Finally, DP-o forwards 
   200 OK to MTA-o. The initial INVITE request and 183 SDP response 
   contain a SIP Contact header to indicate the IP address of the 
   remote MTA to be used for subsequent end-to-end SIP signaling 
   exchanges. MTA-o acknowledges the 183 SDP by sending a PRACK [5] 
   directly to MTA-t.  
    
   Once the initial INVITE/183/PRACK exchange has completed, both MTAs 
   reserve the resources that will be needed for the media streams. 
   Once MTA-o has successfully made its reservation, it sends an UPDATE 
   message [7] to MTA-t, which is immediately acknowledged by MTA-t 
   with a 200-OK. MTA-o uses the UPDATE message to communicate the fact 
   that the desired pre-conditions necessary for the session as 
   perceived by MTA-o are satisfied (e.g., successful reservation of 
   resources, as perceived by MTA-o). MTA-t acknowledges the UPDATE 
   message with a 200 OK final response directly to MTA-o. However, 
   resource reservation from MTA-t's perspective may not be completed 
   yet. Thus, the 200 OK acknowledging the UPDATE message does not 
   indicate successful resource reservation. Once MTA-t successfully 
   reserves the resources needed for the call and starts alerting the 
   called user, it sends a 180 Ringing through the proxies to indicate 
   that the phone is ringing, and that the calling party should be 
   given a ringback call progress tone. We have not described, in 
   detail, the messaging involved in resource reservation here, as we 
   believe that it is appropriate to allow for a variety of resource 
   management mechanisms. Thus, the MTA may use the resource management 
   mechanism that is most suitable to the network segment that it is 
   attached to. When the called party answers by going off-hook, MTA-t 
   sends a 200 OK final response through the proxies, which MTA-o 
   acknowledges with an end-to-end ACK. At this point the resources 
   that were previously reserved are committed to this conversation, 
   and the call is "cut through." 
    
   Either party can terminate the call. An MTA that detects an on-hook 
   sends a SIP BYE message to the remote MTA, which is acknowledged. 
       
3. Resource Management 
 
   DCS's resource management protocols distinguish between two phases: 
   a "Reserve" phase and a "Commit" phase. During the Reserve phase, 
   resources are reserved but are not yet made available to the 
   endpoint. This ensures that resources are available before ringing 
   the far-end telephone. The Commit phase, which commits the resources 
   associated with the flow, is initiated after ringing the far-end 
   telephone and after the called party picks up. At this point, the 
  
DCS Group   Category: Informational - Expiration 04/30/03          12 

                           DCS Architecture               October 2002 
 
 
   resources are made available to the endpoint, and usage recording is 
   started so that the user can be billed for usage. The use of a two-
   phase approach is essential because of the unique requirements 
   associated with human communication, such as telephony. Recognition 
   of the need for a two phase resource management approach is a 
   significant motivation for the call flow adopted in the previous 
   section. 
      
   Although we believe that issues of billing ought not to be the 
   primary consideration in the design of the protocol, the protocol 
   design should not preclude the possibility of usage sensitive 
   billing. Therefore, in addition to ensuring that resources are 
   available before ringing the phone, the two-phase resource 
   management protocol also allows us to preserve the semantics of 
   billing that users are accustomed to, whereby usage recording is not 
   started until the called party picks up the phone. Backbone 
   resources are reserved and allocated in the first phase of the two-
   phase resource reservation protocol.  This is important in order to 
   limit the impact of backbone resource management on post-pickup 
   delay (this minimizes the likelihood of clipping the first few 
   syllables of the conversation).  
    
4. Distributed Call State 
    
   In order to provide enhanced services to millions of endpoints, we 
   need an architecture that can be implemented cost-effectively at 
   very large scale. Just as we enable flexibility by exploiting 
   intelligence at the endpoints, services can be provided in a 
   scaleable manner by storing the state associated with applications 
   at the endpoints, rather than in network servers. Especially with 
   telephony, endpoints are directly involved in handling calls and 
   therefore need to maintain and use call state. In contrast, while 
   network servers may need to be involved when setting up a call to 
   gain access to enhanced QoS, there is no fundamental need for those 
   servers to be involved throughout the lifetime of the call. 
   Maintaining state for every call at network servers, while 
   achievable, increases the reliability requirements and load on the 
   servers. The less state kept in the network, the better. 
    
   As a result, the DCS-proxies in DCS are designed to be Call 
   stateless transaction servers. The proxy maintains SIP transaction 
   state. So, when a DCS-proxy processes a service request from an 
   endpoint, it maintains state until the transaction is complete, but 
   does not maintain any per-call state about active calls in the 
   network. There are two major advantages to this design. First the 
   reliability of the service does not depend on the reliability of an 
   individual DCS-proxy. A DCS-proxy can fail without affecting calls 
   that are currently in progress. Second, it removes many complex 
   synchronization problems where two (or more) entities need to have 
   simultaneously accurate information. Since interactions with the 
   DCS-proxies are simple stateless transactions, it is not necessary 
   for consecutive calls to be processed by the same DCS-proxy. DCS-
   proxy crashes affect only the transient calls (the calls that are in 
  
DCS Group   Category: Informational - Expiration 04/30/03          13 

                           DCS Architecture               October 2002 
 
 
   the process of being set up), and not stable conversations.  
   Further, it is likely that most calls in a transient state can be 
   recovered and successfully established through a backup or spare 
   DCS-proxy using endpoint retransmission, with no explicit 
   synchronization protocol required between the DCS-proxies. We 
   believe this design principle will enable us to operate in very 
   large scale, cost effectively. Furthermore it places the function of 
   managing the state of a call where it belongs - at the endpoint. An 
   existing call can only be affected by failures along the path or by 
   failure of the endpoints: there are no unnecessary elements involved 
   in a call. 
    
   We note that there are many services that involve the use of servers 
   or proxy endpoints that communicate directly with clients. Since 
   these endpoints are directly involved in providing service, it is 
   necessary and appropriate for them to maintain state. Examples of 
   proxy endpoints include application layer firewalls, caching 
   servers, transcoders, network-based conference bridges, interactive 
   voice response systems, and PSTN gateways. The DCS architecture 
   models these as end-points, that maintain appropriate call state.  
    
   We now turn to the mechanisms that allow us to avoid state in the 
   DCS-proxies. A number of examples of the need for distributed state 
   arise in the implementation of telephony features. These give rise 
   to two types of information that a DCS-proxy may present to an 
   endpoint that may subsequently be given back to the proxy by the 
   endpoint. The first type of information is Remote endpoint 
   identification, contained in the "P-Asserted-Identity" header. The 
   second type of information is associated with an active session that 
   an endpoint is participating in. This latter information, stored in 
   the "State" header[3], is information that a service provider or 
   proxy may need for methods that are invoked by an endpoint related 
   to that session. Thus, a DCS-proxy stores the state information 
   about the calls at an endpoint in two new headers, "State" and "P-
   Asserted-Identity". The State header is both encrypted and signed by 
   the proxy to ensure the privacy and the integrity of the information 
   contained in the header. The information that may be contained in 
   State includes resource information (such as Gate information) and 
   billing information (such as a billing id). The P-Asserted-Identity 
   is only encrypted when privacy is requested by the endpoint (covered 
   in detail in the Section 6 below.) 
    
   When needed, the endpoint provides the State to the DCS-proxy that 
   generated it, which can use the information to provide additional 
   functionality. Because the State header is encrypted and signed by 
   the DCS-proxy, the information it contains is trusted by the network 
   even though the endpoint itself is not trusted. In addition, DCS-
   proxies store service-specific opaque data associated with a call at 
   the edge router. Since charging for telephony services may be tied 
   to the use of resources, this information is best stored at the edge 
   router, where knowledge of resource usage exists. 
    

  
DCS Group   Category: Informational - Expiration 04/30/03          14 

                           DCS Architecture               October 2002 
 
 
   The endpoint returns the state (possibly both State and P-Asserted-
   Identity) information to the DCS-proxy when it is needed to 
   implement specific features. The endpoint cannot interpret the 
   information in the encrypted and signed State header (and P-
   Asserted-Identity if it is also encrypted), and any attempt to 
   tamper with it can be detected by the DCS-proxy.  
    
   An example of use of the State information is one where a change in 
   coding method in the middle of a call (e.g., upon detection of a fax 
   tone) may require the proxies to authorize additional resources. 
   Services such as call-transfer and three-way-calling require the 
   proxy to be involved in authorizing resources for packet flows to 
   the new destination(s).  
 
5. DCS Proxy - DCS Proxy Communications 
 
   DCS-proxies implement a set of service-specific control functions 
   required to support the telephony service: 
    
   . Authentication and authorization: Since services are only provided 
     to authorized subscribers, DCS-proxies authenticate signaling 
     messages and authorize requests for service on a call-by-call 
     basis. 
    
   . Name/number translation and call routing: DCS-proxies translate 
     dialed E.164 numbers, or names, to a terminating IP address based 
     on call routing logic to support a wide range of call features.   
    
   . Service-specific admission control: DCS-proxies can implement a 
     broad range of admission control policies for the telephony 
     service.  For example, DCS-proxies may provide precedence for 
     particular calls (e.g., 911 calls). Admission control may also be 
     used to implement overload control mechanisms, e.g. to restrict 
     the number of calls to a particular location or to restrict the 
     frequency of call setup to avoid signaling overload.  
    
   . Signaling and service feature support: While many service features 
     are implemented by endpoints, the DCS-proxy also plays a role in 
     feature support. DCS signaling provides a set of service 
     primitives to end-points that are mediated by the DCS-proxy. The 
     DCS-proxy is involved in implementing service features that depend 
     on the privacy of calling information, e.g., caller-ID blocking.  
     It also plays a role in supporting service features that require 
     users to receive a consistent view of feature operation even when 
     an endpoint is down. For example, while an endpoint may normally 
     participate in call forwarding, the DCS-proxy can control call 
     forwarding on behalf of an endpoint when the endpoint is 
     unavailable. 
 
   Endpoints MTA-o and MTA-t communicate through the DCS-Proxies DP-o 
   and DP-t, as shown in Figure 2. The interface of concern in this 
   section is the one between the DCS-Proxies DP-o and DP-t. In 
   contrast to a true stateless SIP proxy, the DCS-Proxy maintains 
  
DCS Group   Category: Informational - Expiration 04/30/03          15 

                           DCS Architecture               October 2002 
 
 
   transaction state. During the interval that a call is being setup, a 
   DCS-Proxy keeps state related to a request until a response is 
   received.  
    
   For each call made to a phone number, DP-o may need to perform the 
   functions needed for Local Number Portability (LNP). If a LNP 
   database lookup is performed and the resulting dialed string is 
   modified, DP-o must modify the Request-URI to include the result of 
   the LNP lookup. The originating proxy DP-o generates and stores the 
   State header. This information is intended to be sent to endpoint 
   MTA-o and included with the first response that is returned to MTA-
   o. The originating DCS-Proxy, DP-o, may then use the call state 
   information provided to it in the State header to manipulate call-
   legs when requested by MTA-o.  
    
   As with conventional SIP proxies, DP-o adds its address to the top 
   of the Via: header list when forwarding the request. In addition, to 
   support billing functions for a carrier, DP-o appends opaque billing 
   information in the form of P-DCS-Billing-Info. In addition, to 
   support the resource management functions (such as manipulating 
   Gates for resource management in concert with call-leg 
   manipulation), a P-DCS-Gate: header[2] is included. This allows for 
   the subsequent generation of requests for access network QoS by the 
   end-points. 
    
   We also depend on originating DCS-Proxy, DP-o to be responsible for 
   manipulating call legs. For instance, when a call is being 
   forwarded, information about the new destination that the call is 
   being forwarded to is provided by DP-t to DP-o. The new INVITE is 
   then issued from DP-o. The information exchanged between the DCS-
   proxies enables such a function to be performed.  
    
6. Privacy 
 
   Many conventional telephony systems have the ability to provide 
   information about the identity of the calling party to the called 
   party before the latter accepts the call (such a capability is 
   typically termed "Caller-ID"). Systems that support Caller-ID 
   usually provide a mechanism that allows the calling party to 
   instruct the network to refrain from delivering this information to 
   the destination.  
    
   In order for an IP-based network to provide a caller with a similar 
   capability, a new SIP header is needed to signal the desire for 
   anonymity to the network elements that would otherwise provide the 
   caller's identity to the destination party. If a caller desires to 
   remain anonymous, several additional changes to standard SIP are 
   necessary. 
    
   The triplet {From:, To:, Call-ID:} is used to (at least in RFC 2543-
   based implementations) identify a call leg in both endpoints and in 
   proxies. Because call state information is pushed to the edge of the 

  
DCS Group   Category: Informational - Expiration 04/30/03          16 

                           DCS Architecture               October 2002 
 
 
   network, this information must be delivered unchanged to the 
   destination endpoint.  
    
   The SIP From: header normally contains information that identifies 
   the caller. In order to hide the identity of the caller, the From: 
   header information is provided as anonymous.  
    
   Normally, the SIP Call-ID: header also contains information about 
   the caller. In the DCS architecture, to support privacy the value of 
   the Call-ID: header is a cryptographic hash string that contains no 
   information about the user. 
    
   Since all the normally available mechanisms for passing information 
   about the caller are no longer available, a new SIP header, P-
   Asserted-Identity[1], is used to pass the caller's identity to the 
   destination.  The P-Asserted-Identity header is primarily used for 
   endpoint identification. This header contains the information that 
   would normally be present in the From: header; the network passes it 
   to the destination endpoint only if the caller has not requested 
   anonymity.  If the caller had requested anonymity, then the P-
   Asserted-Identity header contains an encrypted string that can be 
   used by the proxy in handling further requests.    
    
   If the user at an endpoint wants to return the last call (e.g., by 
   dialing *69 on a traditional telephone) the "call return" function 
   is invoked. If the user had subscribed to the caller ID service 
   feature, the terminating endpoint could store the information (phone 
   number or IP address) associated with the last call.  However, it 
   may be the case that the user does not subscribe to the feature, or 
   the originator of the previous call may have requested that this 
   information be blocked in order to retain privacy. In this case, 
   call return can be implemented, while keeping the caller's identity 
   private, by using the encrypted P-Asserted-Identity header. 
    
   In addition to the usual privacy elements provided by telephone 
   systems, IP-based systems must implement methods of hiding the 
   source IP address from the destination if the caller requires 
   privacy. The entire address must be obscured, since even a few 
   address bits may provide partial location information. Likewise, IP 
   addresses of the destination should not be revealed to the caller, 
   in order to maintain privacy of transfer destinations.  
    
   IP addresses typically appear in the Contact: header; they also 
   appear in SDP descriptions contained in SIP messages. These must all 
   be protected. We choose to use an application-level anonymizer that 
   inspects the SIP call signaling messages and replaces any 
   identifying information contained therein in a consistent manner. 
   The identifying information is modified such that when the messages 
   are delivered to the destination endpoint, any identifying 
   information has been replaced with fields that obscure the identity 
   of the party seeking privacy. 
    

  
DCS Group   Category: Informational - Expiration 04/30/03          17 

                           DCS Architecture               October 2002 
 
 
   This mechanism does not require any modification to the call 
   signaling initiated by the endpoints: the application-level 
   anonymizer performs these functions silently within the network. 
  
7. Security Considerations 
 
   Building an IP-based system that matches services and matches the 
   perceived security present in the PSTN is a daunting challenge.   
    
   Certain mechanisms that are defined in SIP for end-to-end security, 
   such as S/MIME, are incompatible with services being offered by the 
   proxies inside the network.  It is therefore necessary to implement 
   security on a hop-by-hop basis and depend on all the proxies and 
   trusted User-Agents on the signaling path to properly secure their 
   links.  Billing, accounting, and lawful surveillance information is 
   particularly sensitive and needs adequate safeguards. It is 
   therefore REQUIRED that all proxies and trusted User Agents 
   implement security on a hop-by-hop basis with IPsec or with TLS. 
    
   Careful network administration is required to maintain the trust 
   boundary, and interconnection agreements between service providers 
   must carefully specify the administration requirements. 
    
   Similarly, the links between each MTA and its DCS-Proxy must be 
   protected with IPsec or with TLS.   
    
   See section 6 for a separate discussion of the security 
   considerations of a caller-id service, and its associated caller-id-
   blocking service. 
    
Each of the extensions described in this document are more properly and 
formally defined in separate Internet-Drafts and RFCs.  Each contains 
further security considerations related to their specific extension. 
    
8. Notice Regarding Intellectual Property Rights 
    
   The IETF has been notified of intellectual property rights claimed 
   in regard to some or all of the specification contained in this 
   document.  For more information consult the online list of claimed 
   rights. 
    
9. Informative References 
    
   1. Jennings, C., Peterson, J., and Watson, M., Private Extensions to 
     the Session Initiation Protocol (SIP) for Asserted Identity within 
     Trusted Networks, RFC3325, November 2002. 

   2. "SIP proxy-to-proxy extensions for supporting Distributed Call 
     State", Internet Draft: <draft-dcsgroup-sipping-proxy-proxy-
     01.txt>, October 2002. 

   3. "SIP extensions for supporting Distributed Call State", Internet 
     Draft: <draft-ietf-sip-state-00.txt>, November 2000. 
  
DCS Group   Category: Informational - Expiration 04/30/03          18 

                          DCS Architecture               October 2002 


    
   4. "Private Session Initiation Protocol (SIP) Extensions for Media 
     Authorization", RFC3313, February 2003. 

   5. "Reliability of Provisional Responses in the Session Initiation 
     Protocol", RFC3262, June, 2002. 

   6. "SIP: Session Initiation Protocol", RFC3261, June 2002. 

   7. "Integration of Resource Management and Session Initiation 
     Protocol (SIP)", RFC3312, October 2002. 
    
10. Acknowledgements 
    
   The Distributed Call Signaling work in the PacketCable project is 
   the work of a large number of people, representing many different 
   companies.  The authors would like to recognize and thank the 
   following for their assistance: John Wheeler, Motorola; David 
   Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 
   Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 
   Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 
   Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 
   Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-
   Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 
   Cable Communications. 
    
   Previous versions further acknowledged, as co-authors, several 
   people for providing the text of this document.  They are: K. K. 
   Ramakrishnan (kk@teraoptic.com), TeraOptic Networks; Ed Miller 
   (edward.miller@terayon.com), Terayon; Glenn Russell 
   (G.Russell@Cablelabs.com), CableLabs; Burcak Beser 
   (burcak@juniper.net), Juniper Networks; Mike Mannette (Michael_
   Mannette@3com.com) and Kurt Steinbrenner (Kurt_
   Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com), Cisco 
   Systems; John Pickens (jpickens@com21.com), Com21; Poornima Lalwaney 
   (poornima.lalwaney@nokia.com), Nokia; Jon Fellows 
   (jfellows@coppermountain.com), Copper Mountain Networks; and Keith 
   Kelly (keith@netspeak.com), NetSpeak. 
    
11. Author's Addresses 
    
   Bill Marshall 
   AT&T 
   Florham Park, NJ  07932 
   Email: wtm@research.att.com  
    
   Matt Osman 
   CableLabs 
   Louisville, CO  80027 
   Email: M.Osman@Cablelabs.com 
    


 
DCS Group   Category: Informational - Expiration 04/30/03          19 

                          DCS Architecture               October 2002 


   Flemming Andreasen 
   Cisco 
   Edison, NJ 
   Email: fandreas@cisco.com 
    
   Doc Evans 
   ARRIS 
   Boulder, CO  80303 
   Email: n7dr@arrisi.com 
    











































 
DCS Group   Category: Informational - Expiration 04/30/03          20 

                          DCS Architecture               October 2002 



Full Copyright Statement 

   "Copyright (C) The Internet Society (2002). 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 
   English.  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 "AS IS" basis and THE INTERNET SOCIETY AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
    
   This memo is filed as <draft-dcsgroup-sipping-arch-01.txt>, and 
   expires June 30, 2003. 
    
Acknowledgement 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 





















 
DCS Group   Category: Informational - Expiration 04/30/03          21