SIP Working Group W. Marshall Internet Draft K. Ramakrishnan Document: <draft-dcsgroup-sip-arch-01.txt> AT&T Category: Informational E. Miller G. Russell CableLabs B. Beser M. Mannette K. Steinbrenner 3Com D. Oran F. Andreasen Cisco J. Pickens Com21 P. Lalwaney J. Fellows Motorola D. Evans Secure Cable Solutions K. Kelly NetSpeak March, 2000 Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026[1], and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. 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 DCS Group Category: Informational - Expiration 9/30/00 1 DCS Architecture March 2000 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as <draft- dcsgroup-sip-arch-01.txt>, and expires September 30, 2000. Please send comments to the authors. 1. 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 [3,4,5,6] 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 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. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction 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. 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 DCS Group Category: Informational - Expiration 9/30/00 2 DCS Architecture March 2000 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 protocol drafts. Although DCS was originally designed with cable access networks in mind, the SIP signaling enhancements have general applicability to carrier class VOIP services running over QoS enabled IP networks. The authors are submitting this draft 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 incorporation of the concepts and mechanisms described in this set of drafts by the IETF into the SIP standard 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 at the IETF SIP Working group on earlier versions of this and the other DCS related drafts. 3.1 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 DCS Group Category: Informational - Expiration 9/30/00 3 DCS Architecture March 2000 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. 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. 3.2 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 DCS Group Category: Informational - Expiration 9/30/00 4 DCS Architecture March 2000 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 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. Providing differentiated network-layer quality of service is essential, 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. DCS Group Category: Informational - Expiration 9/30/00 5 DCS Architecture March 2000 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. 6. The architecture must be implementable, cost-effectively, at very large scale. 3.3 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 9/30/00 6 DCS Architecture March 2000 +-----+ | 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 queueing 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 9/30/00 7 DCS Architecture March 2000 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 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. DCS Group Category: Informational - Expiration 9/30/00 8 DCS Architecture March 2000 The signaling gateway 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. A media gateway control protocol is used to control the operation of the media gateway from the signaling gateway. 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. 3.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 [9] 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 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 to notify it about the incoming call. The initial INVITE message invokes 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 forwarded back through the DCS- proxies. DCS Group Category: Informational - Expiration 9/30/00 9 DCS Architecture March 2000 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-------|--------->| | | | | | | | | Precondition-Met | | |----------|--------- |----------|----------|--------->| | 200 OK (acknowledging Precondition-Met) | |<---------|----------|----------|----------|----------| | | | | | 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[8] 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 DCS Group Category: Informational - Expiration 9/30/00 10 DCS Architecture March 2000 from 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 [7] directly to MTA-t. The PRACK may contain the SDP to allow for a further step in the negotiation of capabilities for the session. 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 a PRECONDITION-MET message [9] to MTA-t, which is immediately acknowledged by MTA-t with a 200-OK. MTA-o uses the PRECONDITION- MET 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 PRECONDITION-MET 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 PRECONDITION-MET message does not indicate successful resource reservation. Once MTA-t successfully reserves the resources needed for the call, 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. 4. 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 DCS Group Category: Informational - Expiration 9/30/00 11 DCS Architecture March 2000 far end telephone and after the called party picks up. At this point, the resources are made available to the endpoint, and 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). 5. 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- DCS Group Category: Informational - Expiration 9/30/00 12 DCS Architecture March 2000 proxy crashes affect only the transient calls (the calls that are in 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 "Remote-Party-ID" 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, 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 "Remote-Party- ID". 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 Remote-Party-ID is only encrypted when privacy is requested by the endpoint (covered in detail in the Section 7 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 DCS Group Category: Informational - Expiration 9/30/00 13 DCS Architecture March 2000 use of resources, this information is best stored at the edge router, where knowledge of resource usage exists. The endpoint returns the state (possibly both State and Remote- Party-ID) 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 Remote- Party-ID 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). 6. 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 down. End-points 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 DCS Group Category: Informational - Expiration 9/30/00 14 DCS Architecture March 2000 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 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 with a branch=1 field when forwarding the request. In addition, to support billing functions for a carrier, DP-o appends opaque information called the Billing-Info and Billing- ID. In addition, to support the resource management functions (such as manipulating Gates for resource management in concert with call- leg manipulation), a Gate-Location: header 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. 7. 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. DCS Group Category: Informational - Expiration 9/30/00 15 DCS Architecture March 2000 The triplet {From:, To:, Call-ID:} is used to identify a call leg in both endpoints and in proxies. Because call state information is pushed to the edge of the 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 encrypted with the originating endpoint's key. The destination endpoint does not possess the key to decrypt the From: information. No new syntax for SIP is introduced here. 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, Remote- Party-ID, is used to pass the caller's identity to the destination. The Remote-Party-ID 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 Remote- Party-ID 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 Remote-Party-ID 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 chose 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 DCS Group Category: Informational - Expiration 9/30/00 16 DCS Architecture March 2000 information has been replaced with fields that obscure the identity of the party seeking privacy. 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. 8. Security Considerations Detailed security considerations related to this architecture will be addressed in a future companion draft. 9. References 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 3. "SIP Extensions for Caller Identity, Privacy and Operator Services", Internet Draft: <draft-dcsgroup-sip-privacy-01.txt>, March 2000. 4. "SIP proxy-to-proxy extensions for supporting Distributed Call State", Internet Draft: <draft-dcsgroup-sip-proxy-proxy-01.txt>, March 2000. 5. "SIP extensions for supporting Distributed Call State", Internet Draft: <draft-dcsgroup-sip-state-01.txt>, March 2000. 6. "SIP Extensions for Media Authorization", Internet Draft: <draft- dcsgroup-sip-call-auth-01.txt>, March 2000. 7. "Reliability of Provisional Responses in SIP", Internet Draft: <draft-ietf-sip-100rel-00.txt>, January, 2000. 8. "SIP 183 Session Progress Message", Internet Draft: <draft-ietf- sip-183-00.txt>, October 1999. 9. "Integration of Resource Management and SIP for IP Telephony", Internet Draft: <draft-manyfolks-sip-resource-00.txt>, March 2000. 10. Acknowledgments 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, DCS Group Category: Informational - Expiration 9/30/00 17 DCS Architecture March 2000 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. 11. Author's Addresses Bill Marshall AT&T Florham Park, NJ 07932 Email: wtm@research.att.com K. K. Ramakrishnan AT&T Florham Park, NJ 07932 Email: kkrama@research.att.com Ed Miller CableLabs Louisville, CO 80027 Email: E.Miller@Cablelabs.com Glenn Russell CableLabs Louisville, CO 80027 Email: G.Russell@Cablelabs.com Burcak Beser 3Com Rolling Meadows, IL 60008 Email: Burcak_Beser@3com.com Mike Mannette 3Com Rolling Meadows, IL 60008 Email: Michael_Mannette@3com.com Kurt Steinbrenner 3Com Rolling Meadows, IL 60008 Email: Kurt_Steinbrenner@3com.com Dave Oran Cisco Acton, MA 01720 Email: oran@cisco.com Flemming Andreasen Cisco Edison, NJ DCS Group Category: Informational - Expiration 9/30/00 18 DCS Architecture March 2000 Email: fandreas@cisco.com John Pickens Com21 San Jose, CA Email: jpickens@com21.com Poornima Lalwaney Motorola San Diego, CA 92121 Email: plalwaney@gi.com Jon Fellows Motorola San Diego, CA 92121 Email: jfellows@gi.com Doc Evans Secure Cable Solutions Westminster, CO 30120 Email: drevans@securecable.com Keith Kelly NetSpeak Boca Raton, FL 33587 Email: keith@netspeak.com DCS Group Category: Informational - Expiration 9/30/00 19 DCS Architecture March 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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." Expiration Date This memo is filed as <draft-dcsgroup-sip-arch- 01.txt>, and expires September 30, 2000. DCS Group Category: Informational - Expiration 9/30/00 20