idnits 2.17.1 draft-dcsgroup-sipping-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 919: '... therefore REQUIRED that all proxies...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 15, 2003) is 7744 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '7' on line 584 looks like a reference -- Missing reference section? '5' on line 578 looks like a reference -- Missing reference section? '3' on line 710 looks like a reference -- Missing reference section? '2' on line 813 looks like a reference -- Missing reference section? '1' on line 862 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group W. Marshall 2 Internet Draft AT&T 3 Document: 4 Category: Informational M. Osman 5 CableLabs 7 F. Andreasen 8 Cisco 10 D. Evans 11 ARRIS 13 January 15, 2003 15 Architectural Considerations for Providing Carrier Class Telephony 16 Services Utilizing Session Initiation Protocol (SIP)-based 17 Distributed Call Control Mechanisms 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 This document provides an overview of a SIP-based Distributed Call 41 Signaling (DCS) architecture to support carrier class packet-based 42 voice, video, and other real time multimedia services. Companion 43 documents address a specific set of SIP 2.0 protocol extensions and 44 usage rules that are necessary to implement the DCS architecture in 45 an interoperable fashion. 47 The DCS architecture takes advantage of endpoint intelligence in 48 supporting telephony services without sacrificing the network's 49 ability to provide value through mechanisms such as resource 50 management, lookup of directory information and translation 51 databases, routing services, security, and privacy enforcement. At 52 the same time, the architecture provides flexibility to allow 54 DCS Group Category: Informational - Expiration 04/30/03 1 55 DCS Architecture October 2002 57 evolution in the services that may be provided by endpoints and the 58 network. 60 DCS also takes into account the need to manage access to network 61 resources and account for resource usage. The SIP usage rules 62 defined in the accompanying IDs specifically address the 63 coordination between Distributed Call Signaling and dynamic quality 64 of service control mechanisms for managing resources over the access 65 network. In addition, the DCS architecture defines the interaction 66 needed between network provided call controllers, known as a "DCS- 67 proxy" for supporting these services. 69 Table of Contents 71 Status of this Memo................................................1 72 Abstract...........................................................1 73 Table of Contents..................................................2 74 1. Introduction....................................................2 75 2. Background and Motivation.......................................3 76 2.1 Requirements And Design Principles.............................4 77 2.2 Distributed Call Signaling Architecture........................6 78 2.3 Trust Boundary.................................................9 79 2.4 Basic Call Flow................................................9 80 3. Resource Management............................................12 81 4. Distributed Call State.........................................13 82 5. DCS Proxy - DCS Proxy Communications...........................15 83 6. Privacy........................................................16 84 7. Security Considerations........................................18 85 8. Notice Regarding Intellectual Property Rights..................18 86 9. Informative References.........................................18 87 10. Acknowledgements..............................................19 88 11. Author's Addresses............................................19 89 Full Copyright Statement..........................................21 90 Acknowledgement...................................................21 92 1. Introduction 94 This document provides an overview of a SIP[6]-based Distributed 95 Call Signaling (DCS) architecture to support carrier class packet- 96 based voice, video, and other real time multimedia services. The 97 DCS architecture and the corresponding SIP protocol enhancements 98 (described in companion documents) are being developed as part of 99 the cable industry's PacketCable initiative, managed out of 100 CableLabs (see www.cablelabs.com). PacketCable is defining a series 101 of interface specifications that will enable vendors to develop 102 interoperable products for providing internet telephony and other 103 multimedia services over DOCSIS-enabled cable data networks. 104 The DCS architecture described herein has its roots in the DOSA work 105 performed by AT&T Laboratories ["Distributed Open Signaling 106 Architecture"; Kalmanek, Marshall, Mishra, Nortz, Ramakrishnan, et 107 al.; October, 1998]. A relatively large group of vendors have 108 cooperated in an intensive effort to develop the DCS architecture 109 and SIP protocol extensions described here and in the accompanying 111 DCS Group Category: Informational - Expiration 04/30/03 2 112 DCS Architecture October 2002 114 protocol drafts. Although DCS was originally designed with cable 115 access networks in mind, the SIP signaling enhancements have general 116 applicability to carrier class Voice over IP (VoIP) services running 117 over Quality of Service (QoS) enabled IP networks. 119 The authors have submitted this document to the IETF in order to 120 provide general information regarding the DCS architecture and to 121 convey the motivation behind the SIP enhancements recommended in the 122 accompanying protocol drafts. We believe that providing SIP 123 extensions for the concepts and mechanisms described in this set of 124 drafts will significantly enhance SIP's ability to function as a 125 carrier-class signaling protocol. Such an enhancement to SIP would 126 undoubtedly aid in its widespread acceptance and deployment. We have 127 incorporated several useful comments received from the IETF SIP and 128 SIPPING Working groups on earlier versions of this and the other DCS 129 related drafts. 131 The PacketCable Draft Specification for DCS is available from the 132 CableLabs website at: 134 ftp://ftp.cablelabs.com/pub/pkt-sp-dcs-d03-000428.pdf 136 2. Background and Motivation 138 The design of the Distributed Call Signaling (DCS) architecture 139 recognizes the trend towards use of packet networks as the 140 underlying framework for communications. These networks will 141 provide a broad range of services, including traditional best-effort 142 data service as well as enhanced, value-added services, such as 143 telephony. At the same time, improvements in silicon will reinforce 144 the trend towards increased functionality in endpoints. These 145 intelligent endpoints will take advantage of the widespread 146 availability of packet networks to enable a rich set of applications 147 and services for users. 149 However, when the network is used for real-time telephony 150 applications, it is essential to have service differentiation at the 151 IP layer. The ability to control and monitor usage is needed for 152 the provider to be able to provide service differentiation and to 153 derive revenue from the enhanced services. At the same time, the 154 availability of best effort communications and the migration of 155 functionality to the endpoints pose a challenge to the provider to 156 find incentives for users to use or pay for enhanced services. 158 We see three key functions that a provider can offer, as incentives 159 to use enhanced services. First, the network service provider has 160 the unique ability to manage and provide network layer quality of 161 service. When users depend on the quality of the service, as with 162 telephony, there is a strong incentive to use the enhanced service, 163 rather than a best effort service. Second, the network service 164 provider can play an important role as a trusted intermediary. This 165 includes ensuring the integrity of call routing, as well as ensuring 166 both the accuracy and the privacy of information that is exchanged. 168 DCS Group Category: Informational - Expiration 04/30/03 3 169 DCS Architecture October 2002 171 The service provider can also add value by ensuring that services 172 are provided consistently and reliably, even when an endpoint is 173 unavailable. Finally, there are a number of services that may be 174 offered more efficiently by the network service provider rather than 175 in endpoints. For example, conference bridging may be more cost 176 effective to implement in a multi-point bridge rather than in every 177 endpoint attached to the network. 179 A key contribution of the DCS architecture is a recognition of the 180 need for coordination between call signaling, which controls access 181 to telephony specific services, and resource management, which 182 controls access to network-layer resources. This coordination is 183 designed to meet the user expectations and human factors associated 184 with telephony. For example, the called party should not be 185 alerted until the resources necessary to complete the call are 186 available. If resources were not available when the called party 187 picked up, the user would experience a call defect. In addition, 188 users expect to be charged for service only after the called party 189 answers the phone. As a result, usage accounting starts only after 190 the called party picks up. Coordination between call signaling and 191 resource management is also needed to prevent fraud and theft of 192 service. The coordination between DCS and Dynamic QoS protocols 193 ensures that users are authenticated and authorized before receiving 194 access to the enhanced QoS associated with the telephony service. 196 It is important to be able to deploy a residential telephone service 197 at very large scale, cost-effectively. To achieve this, DCS 198 minimizes the messaging overhead on network call servers, and does 199 not require these servers to maintain call state for active calls. 200 Once a call is established, call state is maintained only where it 201 is needed, in keeping (informally) with the principle of "fate- 202 sharing" at the endpoints that are involved in the call, and at the 203 Edge Routers in the bearer path that are providing differentiated 204 service to the media flow. This allows the network call servers to 205 scale to support more users, and imposes less stringent reliability 206 requirements on those servers. 208 DCS is also designed so that calling users receive consistent 209 service even when a called endpoint is unavailable. For example, 210 when an endpoint is unavailable, service logic in a network call 211 server can forward telephone calls to a voice mailbox. 213 2.1 Requirements And Design Principles 215 In this section, we briefly describe the application requirements 216 that led to a set of DCS signaling design principles. In its most 217 basic implementation, DCS supports a residential telephone service 218 comparable to the local telephone services offered today. In 219 addition to the commonly used service features that need to be 220 supported, there are important requirements in the areas of 221 reliability, performance, and scalability that influence the 222 signaling architecture. Supporting an IP telephony service 224 DCS Group Category: Informational - Expiration 04/30/03 4 225 DCS Architecture October 2002 227 comparable to the telephony service offered today requires enhanced 228 bearer channel and signaling performance, including: 230 . Low delay - end-to-end packet delay must be small enough that it 231 does not interfere with normal voice conversations. The ITU 232 recommends no greater than 300 ms roundtrip delay for telephony 233 service. 235 . Low packet loss - packet loss must be small enough to not 236 perceptibly impede voice quality or performance of fax and voice 237 band modems. 239 . Short post-dial delay - the delay between the user dialing the 240 last digit and receiving positive confirmation from the network 241 must be short enough that users do not perceive a difference with 242 post-dial delay in the circuit switched network or believe that 243 the network has failed. 245 . Short post pickup delay - the delay between a user picking up a 246 ringing phone and the voice path being cut through must be short 247 enough so that the "hello" from either the initiator or the 248 receiver of the call is not clipped. 250 We identify a number of key design principles that arise from the 251 requirements and philosophy outlined above: 253 1. It is essential to provide differentiated network-layer quality of 254 service, while allowing the provider to derive revenues from the 255 use of such differentiated services. 257 2. The architecture should allow, and even encourage, implementation 258 of services and features in the intelligent endpoints, where 259 economically feasible, while still retaining value in the network 260 and network-based services. 262 3. The architecture must ensure that the network is protected from 263 fraud and theft of service. The service provider must be able to 264 authenticate users requesting service and ensure that only those 265 authorized to receive a particular service be able to obtain it. 267 4. The architecture must enable the service provider to add value by 268 supporting the functions of a trusted intermediary. This includes 269 protecting the privacy of calling and called party information, 270 and ensuring the accuracy of the information that is provided in 271 messages from the network. 273 5. The architecture must enable the service provider to give a 274 consistent view of basic services and features even when customer 275 premise equipment is unavailable, and allow users to take 276 advantage of functionality that is provided in the network, when 277 it is cost-effective and easy to use. 279 DCS Group Category: Informational - Expiration 04/30/03 5 280 DCS Architecture October 2002 282 6. The architecture must be implementable, cost-effectively, at very 283 large scale. 285 2.2 Distributed Call Signaling Architecture 287 The Distributed Call Signaling Architecture follows the principles 288 outlined above to support a robust telephony service. Figure 1 289 introduces the key components in the architecture. 291 The architecture assumes a broad range of DCS-compliant endpoints 292 that provide telephony service to the user including Media Terminal 293 Adapters (MTAs) that may be integrated with a Cable Modem or is a 294 standalone device, as well as other endpoints such as personal 295 computers. The access network interfaces to an IP backbone through a 296 system we refer to as the Edge Router (ER). The ER is the first 297 trusted element within the provider's network and is considered to 298 be the edge of the network for providing access to differentiated 299 quality of service. We believe that the access network is likely to 300 manage resources on a per-flow basis, with associated signaling 301 mechanisms (such as RSVP). The ER performs resource management, acts 302 as a policy enforcement point and as a source of billing 303 information. 305 DCS-proxies (DPs) process call signaling messages and support number 306 translation, call routing, feature support and admission control. 307 In the context of SIP, a DCS-proxy is a SIP proxy that is involved 308 in processing and forwarding of SIP requests. DPs act as trusted 309 decision points for controlling when resources are committed to 310 particular users. Media servers represent network-based components 311 that operate on media flows to support the service. Media servers 312 perform audio bridging, play terminating announcements, provide 313 interactive voice response services, etc. Finally, PSTN gateways 314 interface to the Public Switched Telephone Network. 316 DCS Group Category: Informational - Expiration 04/30/03 6 317 DCS Architecture October 2002 319 +-----+ 320 | MTA | MTA: media terminal adapter 321 +-----+ 322 | ER: Edge Router 323 Access Network | 324 | 325 +----+ 326 | ER | 327 +----+ 328 | +-----------+ 329 |----| DCS Proxy | 330 | +-----------+ 331 | 332 | +------------+ 333 Backbone Network |----|Media Server| 334 | +------------+ 335 | 336 | +------------+ 337 |----|PSTN Gateway| 338 | +------------+ 339 +----+ 340 | ER | 341 +----+ 342 | 343 Access Network | 344 | 345 +-----+ 346 | MTA | 347 +-----+ 348 Figure 1: A Simple view of Components of an IP Telephony 349 Architecture used in a HFC Cable Environment. 351 Telephony endpoints are considered to be "clients" of the telephony 352 service. Consistent with the design principles, the architecture 353 allows a range of services to be implemented by intelligent 354 endpoints. They collect dialed digits, participate in signaling and 355 contain the service logic required for basic call setup and feature 356 support. Endpoints also participate in end-to-end capability 357 negotiation. However, endpoints are not trusted to provide accurate 358 information to the network or to keep information that is received 359 private, except when it is in the endpoint's best interests to do 360 so. 362 Access to network resources on a differentiated basis is likely to 363 be controlled by the service provider. The ER receives resource 364 management requests from endpoints, and is responsible for ensuring 365 that packets are provided the QoS they are authorized to receive 366 (either through packet marking, or through routing and queuing the 367 packets as a specific QoS assured flow). The ER requires 368 authorization from a network entity (on a call-by-call basis for the 369 telephony service) before providing access to enhanced QoS for an 370 end-to-end IP flow. The obvious point where this policy and control 371 function resides is the DCS-proxy (also called a gate-controller, 373 DCS Group Category: Informational - Expiration 04/30/03 7 374 DCS Architecture October 2002 376 because of this responsibility for managing access to enhanced QoS). 377 Thus, the ER is able to ensure that enhanced QoS is only provided 378 for end-to-end flows that have been authorized and for which usage 379 accounting is being done. Since the ER knows about the resource 380 usage associated with individual IP flows, it generates the usage 381 events that allow a user to be charged for service. 383 We introduce the concept of a "gate" in the ER, which manages access 384 to enhanced quality of service. The gate is a packet classifier and 385 policer that ensures that only those IP flows that have been 386 authorized by the DCS-proxy are granted access to enhanced QoS in 387 the access and backbone networks. Gates are "opened" selectively for 388 a flow. For the telephony service, they are opened for individual 389 calls. Opening a gate involves an admission control check that is 390 performed when a resource management request is received from the 391 endpoint for an individual call, and it may involve resource 392 reservation in the network for the call if necessary. The packet 393 filter in the gate allows a flow of packets to receive enhanced QoS 394 for a call from a specific IP source address and port number to a 395 specific IP destination address and port number. 397 The DCS-proxy, in addition to implementing many of the call control 398 functions, is responsible for the policy decision regarding whether 399 the gate should be opened. DCS sets up a gate in advance of a 400 resource management message. This allows the policy function, which 401 is at the DCS-proxy, to be "stateless" in that it does not need to 402 know the state of calls that are already in progress. 404 DCS-proxies are typically organized in domains. A DCS-proxy is 405 responsible for a set of endpoints and the associated ERs. While 406 endpoints are not trusted, there is a trust relationship between the 407 ER and its associated DCS-proxy, since the DCS-proxy plays a role as 408 a policy server controlling when the ER can provide enhanced QoS 409 service. There is also a trust relationship among DCS-proxies. 410 Details of the security model are outside the scope of this draft. 412 The DCS-proxy is designed as a simple transaction server, so that 413 the failure of a DCS-proxy does not affect calls in progress. A 414 domain will likely have a primary and one or more secondary DCS- 415 proxies. If the primary DCS-proxy fails, only calls in a transient 416 state are affected. The endpoints involved in those calls will time 417 out and retry. All active calls are unaffected. This is possible 418 because the DCS-proxy retains no call state for stable calls. We 419 believe this design makes the DCS-proxy efficient and highly 420 scalable, and keeps the reliability requirements manageable. 422 DCS supports inter-working with the circuit switched telephone 423 network through PSTN gateways. A PSTN gateway may be realized as a 424 combination of a media gateway controller, media gateway, and a 425 signaling gateway. A media gateway acts as the IP peer of an 426 endpoint for media packets, converting between the data format used 427 over the IP network and the PCM format required for transmission 428 over the PSTN. The media gateway controller or the signaling gateway 430 DCS Group Category: Informational - Expiration 04/30/03 8 431 DCS Architecture October 2002 433 acts as the IP peer of an endpoint for signaling packets, providing 434 signaling inter-working between DCS and conventional telephony 435 signaling protocols such as ISUP/SS7. When the media gateway 436 controller is the peer, it communicates with the signaling gateway. 437 A media gateway control protocol is used to control the operation of 438 the media gateway from the media gateway controller. 440 There are additional system elements that may be involved in 441 providing the telephony service. For example, the DCS-proxy may 442 interface with other servers that implement the authorization or 443 translation functions. Similarly, three way calling may be supported 444 using media servers in the network. 446 2.3 Trust Boundary 448 The DCS architecture defines a trust boundary around the various 449 systems and servers that are owned, operated by, and/or controlled 450 by the service provider. These trusted systems include the proxies 451 and various servers such as bridge servers, voicemail servers, 452 announcement servers, etc. Outside of the trust boundary lie the 453 customer premises equipment, and various media servers operated by 454 third-party service providers. 456 Certain subscriber-specific information, such as billing and 457 accounting information, stays within the trust boundary. Other 458 subscriber-specific information, such as endpoint identity, may be 459 presented to untrusted endpoints or may be withheld based on 460 subscriber profiles. 462 The SIP User Agent (UA) may be either within the trust boundary 463 (e.g. PSTN gateway) or outside the trust boundary (e.g. MTA), 464 depending on exactly what function is being performed and exactly 465 how it is being performed. Accordingly, the procedures followed by 466 a User Agent, as contained in the accompanying drafts, are different 467 depending on whether the UA is within the trust boundary or outside 468 the trust boundary. A trusted user agent is, in almost all cases, 469 equivalent to the combination of an untrusted user agent and a 470 proxy. 472 2.4 Basic Call Flow 474 Figure 2 presents a high-level overview of a basic MTA-to-MTA call 475 flow in DCS. Each MTA is associated with a DCS-proxy, which acts as 476 a SIP proxy. When a user goes off-hook and dials a telephone number, 477 the originating MTA (MTA-o) collects the dialed digits and sends the 478 initial INVITE message in SIP, to the "originating" DCS-proxy (DP- 479 o). This INVITE contains SDP proposing a set of codecs that are 480 acceptable to MTA-o (and their implied bandwidth requirements), and 481 an indication of the (mandatory) QoS preconditions [7] needed for 482 the session. DP-o verifies that MTA-o is a valid subscriber of the 483 telephony service (using authentication information in the INVITE 484 message) and determines whether this subscriber is authorized to 485 place this call. DP-o then translates the dialed number into the 487 DCS Group Category: Informational - Expiration 04/30/03 9 488 DCS Architecture October 2002 490 address of a "terminating" DCS-proxy (DP-t) and forwards the INVITE 491 message to it. 493 We assume that the originating and terminating DCS-proxies trust 494 each other. DP-o augments the INVITE message that it forwards with 495 additional information, such as billing information containing the 496 account number of the caller. DP-t then translates the dialed number 497 into the address of the terminating MTA (MTA-t) and forwards the 498 INVITE message to MTA-t to notify it about the incoming call. 500 The initial INVITE message may invoke call feature handling at the 501 terminating MTA, such as call-forwarding. Assuming that the call is 502 not forwarded, MTA-t negotiates the coding style and bandwidth 503 requirements for the media streams. A reliable provisional 1xx 504 response to the initial INVITE is sent back through the DCS-proxies. 506 DCS Group Category: Informational - Expiration 04/30/03 10 507 DCS Architecture October 2002 509 MTA-o ER-o DP-o DP-t ER-t MTA-t 511 | INVITE | | | | | 512 |----------|--------->| INVITE | | | 513 | | |--------->| | | 514 | | | | INVITE | | 515 | | | |----------|--------->| 516 | | | | | 183 SDP | 517 | | | |<---------|----------| 518 | | | | | | 519 | | Gate | 183 SDP |Gate Setup| | 520 | | Setup |<---------|--------->| | 521 | |<---------| | | | 522 | 183 SDP | | | | | 523 |<---------|----------| | | | 524 | | | PRACK | | | 525 |----------|----------|----------|----------|--------->| 526 | | 200 OK (acknowledging PRACK) | | 527 |<---------|----------|----------|----------|----------| 528 | | | | | | 529 |<---------|--------Reserve Resources-------|--------->| 530 | | | | | | 531 | | UPDATE | | 532 |----------|--------- |----------|----------|--------->| 533 | 200 OK (acknowledging UPDATE) | 534 |<---------|----------|----------|----------|----------| 535 | | | | | 180 Ring | 536 | | | 180 Ring |<---------|----------| 537 | | 180 Ring |<---------| | | 538 |<---------|----------| | | | 539 | | | PRACK | | | 540 |----------|----------|----------|----------|--------->| 541 | | 200 OK (acknowledging PRACK) | | 542 |<---------|----------|----------|----------|----------| 543 | | | | | | User 544 | | | | | 200 OK | Answers 545 | | | 200 OK |<---------|----------| 546 | | 200 OK |<---------| | | 547 |<---------|----------| | | | 548 | ACK | | | | | 549 |----------|----------|----------|----------|--------->| 550 | | | | | | 551 |<---------|----------Active Call----------|--------->| 552 | | | | | | User 553 | | | | | BYE | Hangs Up 554 |<---------|----------|----------|----------|----------| 555 | | | | | 200 OK | 556 |----------|----------|----------|----------|--------->| 557 Figure 2: A Basic Call Flow, including Resource Management functions 559 In the figure, MTA-t sends a 183 SDP message to DP-t. The 183 SDP 560 contains a subset of the capabilities in the INVITE message that are 561 acceptable to MTA-t. The SDP also carries the QoS preconditions from 563 DCS Group Category: Informational - Expiration 04/30/03 11 564 DCS Architecture October 2002 566 the INVITE. DP-t sends a GATE-SETUP message to the terminating ER 567 (ER-t), conveying policy instructions allowing ER-t to open a gate 568 for the IP flow associated with this phone call. The GATE_SETUP 569 message contains billing information containing the account number 570 of the subscriber that will pay for the call. 572 DP-t forwards the 183 SDP to DP-o. DP-o sends a GATE-SETUP message 573 to the originating ER (ER-o) to indicate that it can open a gate for 574 the IP flow associated with the phone call. Finally, DP-o forwards 575 200 OK to MTA-o. The initial INVITE request and 183 SDP response 576 contain a SIP Contact header to indicate the IP address of the 577 remote MTA to be used for subsequent end-to-end SIP signaling 578 exchanges. MTA-o acknowledges the 183 SDP by sending a PRACK [5] 579 directly to MTA-t. 581 Once the initial INVITE/183/PRACK exchange has completed, both MTAs 582 reserve the resources that will be needed for the media streams. 583 Once MTA-o has successfully made its reservation, it sends an UPDATE 584 message [7] to MTA-t, which is immediately acknowledged by MTA-t 585 with a 200-OK. MTA-o uses the UPDATE message to communicate the fact 586 that the desired pre-conditions necessary for the session as 587 perceived by MTA-o are satisfied (e.g., successful reservation of 588 resources, as perceived by MTA-o). MTA-t acknowledges the UPDATE 589 message with a 200 OK final response directly to MTA-o. However, 590 resource reservation from MTA-t's perspective may not be completed 591 yet. Thus, the 200 OK acknowledging the UPDATE message does not 592 indicate successful resource reservation. Once MTA-t successfully 593 reserves the resources needed for the call and starts alerting the 594 called user, it sends a 180 Ringing through the proxies to indicate 595 that the phone is ringing, and that the calling party should be 596 given a ringback call progress tone. We have not described, in 597 detail, the messaging involved in resource reservation here, as we 598 believe that it is appropriate to allow for a variety of resource 599 management mechanisms. Thus, the MTA may use the resource management 600 mechanism that is most suitable to the network segment that it is 601 attached to. When the called party answers by going off-hook, MTA-t 602 sends a 200 OK final response through the proxies, which MTA-o 603 acknowledges with an end-to-end ACK. At this point the resources 604 that were previously reserved are committed to this conversation, 605 and the call is "cut through." 607 Either party can terminate the call. An MTA that detects an on-hook 608 sends a SIP BYE message to the remote MTA, which is acknowledged. 610 3. Resource Management 612 DCS's resource management protocols distinguish between two phases: 613 a "Reserve" phase and a "Commit" phase. During the Reserve phase, 614 resources are reserved but are not yet made available to the 615 endpoint. This ensures that resources are available before ringing 616 the far-end telephone. The Commit phase, which commits the resources 617 associated with the flow, is initiated after ringing the far-end 618 telephone and after the called party picks up. At this point, the 620 DCS Group Category: Informational - Expiration 04/30/03 12 621 DCS Architecture October 2002 623 resources are made available to the endpoint, and usage recording is 624 started so that the user can be billed for usage. The use of a two- 625 phase approach is essential because of the unique requirements 626 associated with human communication, such as telephony. Recognition 627 of the need for a two phase resource management approach is a 628 significant motivation for the call flow adopted in the previous 629 section. 631 Although we believe that issues of billing ought not to be the 632 primary consideration in the design of the protocol, the protocol 633 design should not preclude the possibility of usage sensitive 634 billing. Therefore, in addition to ensuring that resources are 635 available before ringing the phone, the two-phase resource 636 management protocol also allows us to preserve the semantics of 637 billing that users are accustomed to, whereby usage recording is not 638 started until the called party picks up the phone. Backbone 639 resources are reserved and allocated in the first phase of the two- 640 phase resource reservation protocol. This is important in order to 641 limit the impact of backbone resource management on post-pickup 642 delay (this minimizes the likelihood of clipping the first few 643 syllables of the conversation). 645 4. Distributed Call State 647 In order to provide enhanced services to millions of endpoints, we 648 need an architecture that can be implemented cost-effectively at 649 very large scale. Just as we enable flexibility by exploiting 650 intelligence at the endpoints, services can be provided in a 651 scaleable manner by storing the state associated with applications 652 at the endpoints, rather than in network servers. Especially with 653 telephony, endpoints are directly involved in handling calls and 654 therefore need to maintain and use call state. In contrast, while 655 network servers may need to be involved when setting up a call to 656 gain access to enhanced QoS, there is no fundamental need for those 657 servers to be involved throughout the lifetime of the call. 658 Maintaining state for every call at network servers, while 659 achievable, increases the reliability requirements and load on the 660 servers. The less state kept in the network, the better. 662 As a result, the DCS-proxies in DCS are designed to be Call 663 stateless transaction servers. The proxy maintains SIP transaction 664 state. So, when a DCS-proxy processes a service request from an 665 endpoint, it maintains state until the transaction is complete, but 666 does not maintain any per-call state about active calls in the 667 network. There are two major advantages to this design. First the 668 reliability of the service does not depend on the reliability of an 669 individual DCS-proxy. A DCS-proxy can fail without affecting calls 670 that are currently in progress. Second, it removes many complex 671 synchronization problems where two (or more) entities need to have 672 simultaneously accurate information. Since interactions with the 673 DCS-proxies are simple stateless transactions, it is not necessary 674 for consecutive calls to be processed by the same DCS-proxy. DCS- 675 proxy crashes affect only the transient calls (the calls that are in 677 DCS Group Category: Informational - Expiration 04/30/03 13 678 DCS Architecture October 2002 680 the process of being set up), and not stable conversations. 681 Further, it is likely that most calls in a transient state can be 682 recovered and successfully established through a backup or spare 683 DCS-proxy using endpoint retransmission, with no explicit 684 synchronization protocol required between the DCS-proxies. We 685 believe this design principle will enable us to operate in very 686 large scale, cost effectively. Furthermore it places the function of 687 managing the state of a call where it belongs - at the endpoint. An 688 existing call can only be affected by failures along the path or by 689 failure of the endpoints: there are no unnecessary elements involved 690 in a call. 692 We note that there are many services that involve the use of servers 693 or proxy endpoints that communicate directly with clients. Since 694 these endpoints are directly involved in providing service, it is 695 necessary and appropriate for them to maintain state. Examples of 696 proxy endpoints include application layer firewalls, caching 697 servers, transcoders, network-based conference bridges, interactive 698 voice response systems, and PSTN gateways. The DCS architecture 699 models these as end-points, that maintain appropriate call state. 701 We now turn to the mechanisms that allow us to avoid state in the 702 DCS-proxies. A number of examples of the need for distributed state 703 arise in the implementation of telephony features. These give rise 704 to two types of information that a DCS-proxy may present to an 705 endpoint that may subsequently be given back to the proxy by the 706 endpoint. The first type of information is Remote endpoint 707 identification, contained in the "P-Asserted-Identity" header. The 708 second type of information is associated with an active session that 709 an endpoint is participating in. This latter information, stored in 710 the "State" header[3], is information that a service provider or 711 proxy may need for methods that are invoked by an endpoint related 712 to that session. Thus, a DCS-proxy stores the state information 713 about the calls at an endpoint in two new headers, "State" and "P- 714 Asserted-Identity". The State header is both encrypted and signed by 715 the proxy to ensure the privacy and the integrity of the information 716 contained in the header. The information that may be contained in 717 State includes resource information (such as Gate information) and 718 billing information (such as a billing id). The P-Asserted-Identity 719 is only encrypted when privacy is requested by the endpoint (covered 720 in detail in the Section 6 below.) 722 When needed, the endpoint provides the State to the DCS-proxy that 723 generated it, which can use the information to provide additional 724 functionality. Because the State header is encrypted and signed by 725 the DCS-proxy, the information it contains is trusted by the network 726 even though the endpoint itself is not trusted. In addition, DCS- 727 proxies store service-specific opaque data associated with a call at 728 the edge router. Since charging for telephony services may be tied 729 to the use of resources, this information is best stored at the edge 730 router, where knowledge of resource usage exists. 732 DCS Group Category: Informational - Expiration 04/30/03 14 733 DCS Architecture October 2002 735 The endpoint returns the state (possibly both State and P-Asserted- 736 Identity) information to the DCS-proxy when it is needed to 737 implement specific features. The endpoint cannot interpret the 738 information in the encrypted and signed State header (and P- 739 Asserted-Identity if it is also encrypted), and any attempt to 740 tamper with it can be detected by the DCS-proxy. 742 An example of use of the State information is one where a change in 743 coding method in the middle of a call (e.g., upon detection of a fax 744 tone) may require the proxies to authorize additional resources. 745 Services such as call-transfer and three-way-calling require the 746 proxy to be involved in authorizing resources for packet flows to 747 the new destination(s). 749 5. DCS Proxy - DCS Proxy Communications 751 DCS-proxies implement a set of service-specific control functions 752 required to support the telephony service: 754 . Authentication and authorization: Since services are only provided 755 to authorized subscribers, DCS-proxies authenticate signaling 756 messages and authorize requests for service on a call-by-call 757 basis. 759 . Name/number translation and call routing: DCS-proxies translate 760 dialed E.164 numbers, or names, to a terminating IP address based 761 on call routing logic to support a wide range of call features. 763 . Service-specific admission control: DCS-proxies can implement a 764 broad range of admission control policies for the telephony 765 service. For example, DCS-proxies may provide precedence for 766 particular calls (e.g., 911 calls). Admission control may also be 767 used to implement overload control mechanisms, e.g. to restrict 768 the number of calls to a particular location or to restrict the 769 frequency of call setup to avoid signaling overload. 771 . Signaling and service feature support: While many service features 772 are implemented by endpoints, the DCS-proxy also plays a role in 773 feature support. DCS signaling provides a set of service 774 primitives to end-points that are mediated by the DCS-proxy. The 775 DCS-proxy is involved in implementing service features that depend 776 on the privacy of calling information, e.g., caller-ID blocking. 777 It also plays a role in supporting service features that require 778 users to receive a consistent view of feature operation even when 779 an endpoint is down. For example, while an endpoint may normally 780 participate in call forwarding, the DCS-proxy can control call 781 forwarding on behalf of an endpoint when the endpoint is 782 unavailable. 784 Endpoints MTA-o and MTA-t communicate through the DCS-Proxies DP-o 785 and DP-t, as shown in Figure 2. The interface of concern in this 786 section is the one between the DCS-Proxies DP-o and DP-t. In 787 contrast to a true stateless SIP proxy, the DCS-Proxy maintains 789 DCS Group Category: Informational - Expiration 04/30/03 15 790 DCS Architecture October 2002 792 transaction state. During the interval that a call is being setup, a 793 DCS-Proxy keeps state related to a request until a response is 794 received. 796 For each call made to a phone number, DP-o may need to perform the 797 functions needed for Local Number Portability (LNP). If a LNP 798 database lookup is performed and the resulting dialed string is 799 modified, DP-o must modify the Request-URI to include the result of 800 the LNP lookup. The originating proxy DP-o generates and stores the 801 State header. This information is intended to be sent to endpoint 802 MTA-o and included with the first response that is returned to MTA- 803 o. The originating DCS-Proxy, DP-o, may then use the call state 804 information provided to it in the State header to manipulate call- 805 legs when requested by MTA-o. 807 As with conventional SIP proxies, DP-o adds its address to the top 808 of the Via: header list when forwarding the request. In addition, to 809 support billing functions for a carrier, DP-o appends opaque billing 810 information in the form of P-DCS-Billing-Info. In addition, to 811 support the resource management functions (such as manipulating 812 Gates for resource management in concert with call-leg 813 manipulation), a P-DCS-Gate: header[2] is included. This allows for 814 the subsequent generation of requests for access network QoS by the 815 end-points. 817 We also depend on originating DCS-Proxy, DP-o to be responsible for 818 manipulating call legs. For instance, when a call is being 819 forwarded, information about the new destination that the call is 820 being forwarded to is provided by DP-t to DP-o. The new INVITE is 821 then issued from DP-o. The information exchanged between the DCS- 822 proxies enables such a function to be performed. 824 6. Privacy 826 Many conventional telephony systems have the ability to provide 827 information about the identity of the calling party to the called 828 party before the latter accepts the call (such a capability is 829 typically termed "Caller-ID"). Systems that support Caller-ID 830 usually provide a mechanism that allows the calling party to 831 instruct the network to refrain from delivering this information to 832 the destination. 834 In order for an IP-based network to provide a caller with a similar 835 capability, a new SIP header is needed to signal the desire for 836 anonymity to the network elements that would otherwise provide the 837 caller's identity to the destination party. If a caller desires to 838 remain anonymous, several additional changes to standard SIP are 839 necessary. 841 The triplet {From:, To:, Call-ID:} is used to (at least in RFC 2543- 842 based implementations) identify a call leg in both endpoints and in 843 proxies. Because call state information is pushed to the edge of the 845 DCS Group Category: Informational - Expiration 04/30/03 16 846 DCS Architecture October 2002 848 network, this information must be delivered unchanged to the 849 destination endpoint. 851 The SIP From: header normally contains information that identifies 852 the caller. In order to hide the identity of the caller, the From: 853 header information is provided as anonymous. 855 Normally, the SIP Call-ID: header also contains information about 856 the caller. In the DCS architecture, to support privacy the value of 857 the Call-ID: header is a cryptographic hash string that contains no 858 information about the user. 860 Since all the normally available mechanisms for passing information 861 about the caller are no longer available, a new SIP header, P- 862 Asserted-Identity[1], is used to pass the caller's identity to the 863 destination. The P-Asserted-Identity header is primarily used for 864 endpoint identification. This header contains the information that 865 would normally be present in the From: header; the network passes it 866 to the destination endpoint only if the caller has not requested 867 anonymity. If the caller had requested anonymity, then the P- 868 Asserted-Identity header contains an encrypted string that can be 869 used by the proxy in handling further requests. 871 If the user at an endpoint wants to return the last call (e.g., by 872 dialing *69 on a traditional telephone) the "call return" function 873 is invoked. If the user had subscribed to the caller ID service 874 feature, the terminating endpoint could store the information (phone 875 number or IP address) associated with the last call. However, it 876 may be the case that the user does not subscribe to the feature, or 877 the originator of the previous call may have requested that this 878 information be blocked in order to retain privacy. In this case, 879 call return can be implemented, while keeping the caller's identity 880 private, by using the encrypted P-Asserted-Identity header. 882 In addition to the usual privacy elements provided by telephone 883 systems, IP-based systems must implement methods of hiding the 884 source IP address from the destination if the caller requires 885 privacy. The entire address must be obscured, since even a few 886 address bits may provide partial location information. Likewise, IP 887 addresses of the destination should not be revealed to the caller, 888 in order to maintain privacy of transfer destinations. 890 IP addresses typically appear in the Contact: header; they also 891 appear in SDP descriptions contained in SIP messages. These must all 892 be protected. We choose to use an application-level anonymizer that 893 inspects the SIP call signaling messages and replaces any 894 identifying information contained therein in a consistent manner. 895 The identifying information is modified such that when the messages 896 are delivered to the destination endpoint, any identifying 897 information has been replaced with fields that obscure the identity 898 of the party seeking privacy. 900 DCS Group Category: Informational - Expiration 04/30/03 17 901 DCS Architecture October 2002 903 This mechanism does not require any modification to the call 904 signaling initiated by the endpoints: the application-level 905 anonymizer performs these functions silently within the network. 907 7. Security Considerations 909 Building an IP-based system that matches services and matches the 910 perceived security present in the PSTN is a daunting challenge. 912 Certain mechanisms that are defined in SIP for end-to-end security, 913 such as S/MIME, are incompatible with services being offered by the 914 proxies inside the network. It is therefore necessary to implement 915 security on a hop-by-hop basis and depend on all the proxies and 916 trusted User-Agents on the signaling path to properly secure their 917 links. Billing, accounting, and lawful surveillance information is 918 particularly sensitive and needs adequate safeguards. It is 919 therefore REQUIRED that all proxies and trusted User Agents 920 implement security on a hop-by-hop basis with IPsec or with TLS. 922 Careful network administration is required to maintain the trust 923 boundary, and interconnection agreements between service providers 924 must carefully specify the administration requirements. 926 Similarly, the links between each MTA and its DCS-Proxy must be 927 protected with IPsec or with TLS. 929 See section 6 for a separate discussion of the security 930 considerations of a caller-id service, and its associated caller-id- 931 blocking service. 933 Each of the extensions described in this document are more properly and 934 formally defined in separate Internet-Drafts and RFCs. Each contains 935 further security considerations related to their specific extension. 937 8. Notice Regarding Intellectual Property Rights 939 The IETF has been notified of intellectual property rights claimed 940 in regard to some or all of the specification contained in this 941 document. For more information consult the online list of claimed 942 rights. 944 9. Informative References 946 1. Jennings, C., Peterson, J., and Watson, M., Private Extensions to 947 the Session Initiation Protocol (SIP) for Asserted Identity within 948 Trusted Networks, RFC3325, November 2002. 950 2. "SIP proxy-to-proxy extensions for supporting Distributed Call 951 State", Internet Draft: , October 2002. 954 3. "SIP extensions for supporting Distributed Call State", Internet 955 Draft: , November 2000. 957 DCS Group Category: Informational - Expiration 04/30/03 18 958 DCS Architecture October 2002 960 4. "Private Session Initiation Protocol (SIP) Extensions for Media 961 Authorization", RFC3313, February 2003. 963 5. "Reliability of Provisional Responses in the Session Initiation 964 Protocol", RFC3262, June, 2002. 966 6. "SIP: Session Initiation Protocol", RFC3261, June 2002. 968 7. "Integration of Resource Management and Session Initiation 969 Protocol (SIP)", RFC3312, October 2002. 971 10. Acknowledgements 973 The Distributed Call Signaling work in the PacketCable project is 974 the work of a large number of people, representing many different 975 companies. The authors would like to recognize and thank the 976 following for their assistance: John Wheeler, Motorola; David 977 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 978 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 979 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 980 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 981 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 982 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 983 Cable Communications. 985 Previous versions further acknowledged, as co-authors, several 986 people for providing the text of this document. They are: K. K. 987 Ramakrishnan (kk@teraoptic.com), TeraOptic Networks; Ed Miller 988 (edward.miller@terayon.com), Terayon; Glenn Russell 989 (G.Russell@Cablelabs.com), CableLabs; Burcak Beser 990 (burcak@juniper.net), Juniper Networks; Mike Mannette (Michael_ 991 Mannette@3com.com) and Kurt Steinbrenner (Kurt_ 992 Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com), Cisco 993 Systems; John Pickens (jpickens@com21.com), Com21; Poornima Lalwaney 994 (poornima.lalwaney@nokia.com), Nokia; Jon Fellows 995 (jfellows@coppermountain.com), Copper Mountain Networks; and Keith 996 Kelly (keith@netspeak.com), NetSpeak. 998 11. Author's Addresses 1000 Bill Marshall 1001 AT&T 1002 Florham Park, NJ 07932 1003 Email: wtm@research.att.com 1005 Matt Osman 1006 CableLabs 1007 Louisville, CO 80027 1008 Email: M.Osman@Cablelabs.com 1010 DCS Group Category: Informational - Expiration 04/30/03 19 1011 DCS Architecture October 2002 1013 Flemming Andreasen 1014 Cisco 1015 Edison, NJ 1016 Email: fandreas@cisco.com 1018 Doc Evans 1019 ARRIS 1020 Boulder, CO 80303 1021 Email: n7dr@arrisi.com 1023 DCS Group Category: Informational - Expiration 04/30/03 20 1024 DCS Architecture October 2002 1026 Full Copyright Statement 1028 "Copyright (C) The Internet Society (2002). All Rights Reserved. 1029 This document and translations of it may be copied and furnished to 1030 others, and derivative works that comment on or otherwise explain it 1031 or assist in its implementation may be prepared, copied, published 1032 and distributed, in whole or in part, without restriction of any 1033 kind, provided that the above copyright notice and this paragraph 1034 are included on all such copies and derivative works. However, this 1035 document itself may not be modified in any way, such as by removing 1036 the copyright notice or references to the Internet Society or other 1037 Internet organizations, except as needed for the purpose of 1038 developing Internet standards in which case the procedures for 1039 copyrights defined in the Internet Standards process must be 1040 followed, or as required to translate it into languages other than 1041 English. The limited permissions granted above are perpetual and 1042 will not be revoked by the Internet Society or its successors or 1043 assigns. This document and the information contained herein is 1044 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1045 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1046 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1047 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1048 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1050 This memo is filed as , and 1051 expires June 30, 2003. 1053 Acknowledgement 1055 Funding for the RFC Editor function is currently provided by the 1056 Internet Society. 1058 DCS Group Category: Informational - Expiration 04/30/03 21