idnits 2.17.1 draft-dcsgroup-sip-resource-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 530 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 43 looks like a reference -- Missing reference section? '2' on line 84 looks like a reference -- Missing reference section? '3' on line 93 looks like a reference -- Missing reference section? '4' on line 311 looks like a reference -- Missing reference section? 'RFC 2543' on line 334 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group W. Marshall 3 Internet Draft K. Ramakrishnan 4 Document: AT&T 5 Category: Informational 6 E. Miller 7 G. Russell 8 CableLabs 10 B. Beser 11 M. Mannette 12 K. Steinbrenner 13 3Com 15 D. Oran 16 Cisco 18 J. Pickens 19 Com21 21 P. Lalwaney 22 J. Fellows 23 General Instrument 25 D. Evans 26 Lucent Cable 28 K. Kelly 29 NetSpeak 31 F. Andreasen 32 Telcordia 34 October, 1999 36 Integration of Resource Management and Call Signaling for IP Telephony 38 Status of this Memo 40 This document is an Internet-Draft and is NOT offered in accordance 41 with Section 10 of RFC2026[1], and the author does not provide the 42 IETF with any rights other than to publish as an Internet-Draft. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF), its areas, and its working groups. Note that 46 other groups may also distribute working documents as Internet- 47 Drafts. Internet-Drafts are draft documents valid for a maximum of 48 six months and may be updated, replaced, or obsoleted by other 49 documents at any time. It is inappropriate to use Internet- Drafts 50 as reference material or to cite them other than as "work in 51 progress." 53 DCS Group Category Informational - Expiration 4/30/00 1 54 Integration of Resource Mgmt and Signaling October 1999 56 The list of current Internet-Drafts can be accessed at 57 http://www.ietf.org/ietf/1id-abstracts.txt 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html. 62 The distribution of this memo is unlimited. It is filed as , and expires April 30, 2000. Please 64 send comments to the authors. 66 1. Abstract 68 This document describes a two-stage call-setup mechanism, with the 69 resource management protocol interleaved between the two stages. The 70 objective of such a mechanism is to enable deployment of robust IP 71 Telephony services. The first phase ensures that resources are made 72 available before the phone rings and the participants of the call 73 are "invited" to participate. The second phase involves the alerting 74 of the user after the network resources are reserved. This draft 75 presents the call signaling requirements that lead to this design, 76 and the specific SIP extension of an INVITE that does not ring the 77 far-end phone. 79 2. Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 83 this document are to be interpreted as described in RFC-2119 [2]. 85 3. Introduction 87 For an Internet Telephony service to be successfully used by a large 88 number of subscribers, it must offer few surprises to those 89 accustomed to the behavior of existing telephony services. One 90 expectation is that of connection quality, implying resources must 91 be set aside for each call. 93 A key contribution of the DCS architecture, as described in [3], is 94 a recognition of the need for coordination between call signaling, 95 which controls access to telephony specific services, and resource 96 management, which controls access to network-layer resources. This 97 coordination is designed to meet the user expectations and human 98 factors associated with telephony. 100 While customers may expect, during times of heavy load, to receive a 101 "fast busy" or an announcement saying "all circuits are busy now," 102 the general expectation is that once the destination phone rings 103 that the connection can be made. Blocking a call after ringing the 105 DCS Group Category Informational - Expiration 4/30/00 2 106 Integration of Resource Mgmt and Signaling October 1999 108 destination is considered a "call defect" and is a very undesirable 109 exception condition. 111 We consider the case where a provider may choose to block a call 112 when adequate resources for the call are not available. It may be 113 argued that best-effort connections may be an alternative in such a 114 case. However, public policy demands that the phone system provide 115 adequate quality at least in certain cases: e.g., for emergency 116 communications during times of disasters. Call blocking enables a 117 provider to meet such requirements. This draft and the overall DCS 118 architecture assumes that the provider blocks calls when resources 119 are unavailable. 121 It is often the case that calls into a disaster area are blocked, to 122 ensure resources are available for calls out of the disaster area. 123 Such policy-level controls also need to be available for the service 124 provider. 126 A further expectation of customers of a carrier-grade telephony 127 system is that the first few syllables of a conversation not be 128 clipped. While residential users often introduce a long delay 129 between pickup and use of the voice path (e.g., time taken to lift 130 receiver and placing it to the ear before speaking), automatic 131 answering devices and operators with headsets have no such delay and 132 demand fast cut-through of the voice path. 134 Coordination between call signaling and resource management is also 135 needed to prevent fraud and theft of service. The coordination 136 between call-signaling and QoS setup protocols ensures that users 137 are authenticated and authorized before receiving access to the 138 enhanced QoS associated with the telephony service. 140 3.1 Requirements 142 The basic motivation in this work is to meet and possibly exceed the 143 user expectations and human factors associated with telephony. 145 In this section, we briefly describe the application requirements 146 that led to the set of DCS signaling design principles. In its 147 basic implementation, DCS supports a residential telephone service 148 comparable to the local telephone services offered today. Some of 149 the requirements for resource management, in concert with call 150 signaling, are as follows: 152 The system must minimize call defects. These are situations where 153 either the call never completes, or an error occurs after the 154 destination is alerted. Requirements on call defects are typically 155 far more stringent than call blocking. Note that we expect the 156 provider and the endpoints to attempt to use lower bandwidth CODECs 157 as the first line of defense against limited network capacity, and 158 to avoid blocking calls. 160 DCS Group Category Informational - Expiration 4/30/00 3 161 Integration of Resource Mgmt and Signaling October 1999 163 The system must minimize the post-dial-delay, which is the time 164 between the user dialing the last digit and receiving positive 165 confirmation from the network. This delay must be short enough that 166 users do not perceive a difference with post-dial delay in the 167 circuit switched network or conclude that the network connectivity 168 no longer exists. 170 The system must minimize the post-pickup-delay, which is the time 171 between the user picking up a ringing phone and the voice path being 172 ready for use. This must be short enough that the "hello" is not 173 clipped (both from the called party and the caller). In practical 174 terms, this delay cannot be more than tens of milliseconds beyond 175 the one-way propagation delay. 177 Call signaling needs to provide enough information to the resource 178 management protocol so as to enable resources to be allocated in the 179 network. This typically requires most if not all of the components 180 of a packet classifier (source IP, destination IP, source port, 181 destination port, protocol) to be available for resource allocation. 183 3.2 Overview 185 For acceptable interactive voice communication it is important to 186 achieve end-to-end QoS. The end-to-end QoS assurance implies 187 achieving low packet delay and packet loss. End-to-end packet delay 188 must be small enough that it does not interfere with normal voice 189 conversations. The ITU recommends no greater than 300 ms roundtrip 190 delay for telephony service. Packet loss must be small enough to 191 not perceptibly impede voice quality or the performance of fax and 192 voice band modems. 194 If it is found that the network does not have end-to-end QoS 195 resources there are two alternatives: either (1) allow call 196 signaling to proceed with high probability of excessive delay and 197 packet loss which could impair any interactive real-time 198 communication between the participants, or (2) to block the call 199 prior to the called party being alerted. When calls are blocked 200 because of a lack of resources in a particular segment of the 201 network, it is highly desirable that such blocking occur before the 202 called party picks up. 204 We do expect the endpoints to attempt to use lower bandwidth CODECs, 205 thereby avoiding blocking calls, as the first line of defense 206 against limited network capacity. 208 The call-signaling and resource reservation must be achieved in such 209 a way that the post-dial-delay must be minimized without increasing 210 the probability of call defects. This means that the number of 211 round-trip messages must be kept at an absolute minimum and messages 212 must be send directly end system-to-end system if possible. 214 DCS Group Category Informational - Expiration 4/30/00 4 215 Integration of Resource Mgmt and Signaling October 1999 217 Since the post-pickup-delay has a much more stringent requirement 218 than the post-dial-delay, post-pickup-delay must not depend on any 219 signals that are not sent directly end-to-end. Otherwise it may be 220 difficult to avoid quality impairments such as clipping of the 221 initial user "hello". 223 3.3 Basic Call Flow 225 Originating (MTA-o) Terminating (MTA-t) 226 | SIP-Proxy(s) | 227 | INVITE(Stage1) | | 228 |---------------------->|---------------------->| 229 | | | 230 | | 200 OK | 231 |<----------------------|<----------------------| 232 | | 233 | | 234 | ACK | 235 |---------------------------------------------->| 236 | Reservation Reservation | 237 ===========> <=========== 238 | | 239 | | 240 | INVITE | 241 |---------------------------------------------->| 242 | 243 | 244 | User Alerted 245 | RINGING | 246 |<----------------------------------------------| 247 | | 248 | User Picks-Up 249 | the phone 250 | 200 OK | 251 |<----------------------------------------------| 252 | 253 | 254 | ACK | 255 |---------------------------------------------->| 257 Figure 1 259 Figure 1 presents a high-level overview of a basic end-point to end- 260 point(MTA-to-MTA) call flow. 262 When a user goes off-hook and dials a telephone number, the 263 originating MTA (MTA-o) collects the dialed digits and sends the 264 initial call INVITE message to a SIP-Proxy. 266 Upon reception the initial INVITE message at the destination MTA 267 (MTA-t), the MTA invokes call feature handling, such as call- 269 DCS Group Category Informational - Expiration 4/30/00 5 270 Integration of Resource Mgmt and Signaling October 1999 272 forwarding but does not alert the user. This action is indicated by 273 the existence of the Stage1 statement. 275 Assuming that the call is not forwarded, MTA-t communicates the 276 coding style and bandwidth requirements for the media streams. The 277 200 OK response to the initial INVITE is forwarded back through the 278 SIP-proxies. 280 The INVITE request and 200 OK response contain a SIP Contact header 281 to indicate the IP address of the remote MTA to be used for 282 subsequent end-to-end SIP signaling exchanges. MTA-o acknowledges 283 the 200 OK directly to MTA-t. 285 Once the initial INVITE/200 OK exchange has completed, each MTA has 286 sufficient information regarding the other end-point, bandwidth and 287 other characteristics of the media exchange. Now the endpoints may 288 reserve the resources that will be needed for the media streams. 290 Once MTA-o has successfully made its reservation, it sends a second 291 INVITE message directly to MTA-t without the Stage1 statement, 292 stating that the MTA-t should alert the user. If MTA-t successfully 293 reserved the resources needed for the call, it responds with a 180 294 Ringing to indicate that the user is alerted, and that the calling 295 user should be given a ring-back call progress tone. When the 296 called party answers, by going off-hook, MTA-t sends a 200 OK final 297 response directly to MTA-o, which MTA-o acknowledges. 299 Either party can terminate the call. An MTA that detects an "on- 300 hook" (request to terminate the call) releases the QoS resources 301 held for the connection, and sends a SIP BYE message to the remote 302 MTA, which is acknowledged. 304 4. Changes to SIP to Support Two-Stage Call Setup 306 The profile/extension defined in this section allows network 307 resources to be reserved prior to alerting the user and 308 simultaneously reduces the user perceived delays. 310 The following syntax specification uses the augmented Backus-Naur 311 Form (BNF) as described in RFC-2234 [4]. 313 4.1 SIP Header Extension: Stage1 315 The Stage1 request header allows the caller to indicate that an 316 INVITE should not alert the user. 318 Stage1 = "Stage1:" 320 A SIP server, on receiving an INVITE with "Stage1" MUST execute the 321 feature logic associated with the "line" (the logical end-point) and 322 seize the line if it is not busy and the number has not been 324 DCS Group Category Informational - Expiration 4/30/00 6 325 Integration of Resource Mgmt and Signaling October 1999 327 forwarded, but the server SHOULD NOT alert the user. Once network 328 resources have been reserved, the originating client MUST issue a 329 second INVITE without the Stage1 header. This second INVITE 330 instructs the destination server to alert the user. 332 4.2 SIP Profile 334 This section defines a SIP [RFC 2543] profile for integrating 335 resource management. 337 4.2.1 Phase One 339 Phase one consists of an INVITE message which does not alert the 340 user. The INVITE message can be sent through proxies or (in the 341 case that the desired end point is known, and no resource 342 reservation needs to be authorized by the network, and enhanced QoS 343 is not desired for communication) to the destination itself. Because 344 of the possibility of call forwarding, the originator does not know 345 the final end-point and its characteristics (e.g. CODECs supported, 346 etc.); therefore the resource reservation MUST NOT be attempted yet. 348 Additionally, to support CODEC selection an SDP session description 349 MUST be included in: 350 @ The INVITE message MUST contain the Stage1 header. 352 @ The 200 OK response to the INVITE MUST contain the Stage1 header, 353 and a CONTACT header that indicates the final recipient of the 354 call. 356 @ The ACK associated with INVITE containing the Stage1 header MUST 357 be send end-to-end. 359 4.2.2 Phase Two 361 The message sent during phase two depends on the result of the QoS 362 reservation carried out after phase one. If the reservation is 363 unsuccessful the originating MTA sends a BYE message to terminate 364 the session. 366 If the reservation is successful, the originating MTA sends a second 367 INVITE message directly to the destination MTA, to the address as 368 indicated by the CONTACT header. This direct end-to-end INVITE 369 message is necessary to minimize post-pickup delay. The 200 OK final 370 response message generated after the called user picks up will also 371 be sent directly end-to-end to minimize post-pickup delay as well as 372 avoid clipping the initial "hello". Otherwise, there is the 373 potential of excessive delay if the 200 OK goes through proxies 374 after the phone is picked up, resulting in a delay to cut-through 375 the voice path. 377 DCS Group Category Informational - Expiration 4/30/00 7 378 Integration of Resource Mgmt and Signaling October 1999 380 The second INVITE and 200 OK messages MUST NOT contain the Stage1 381 statement since during this phase the user should be alerted. The 382 INVITE message MUST NOT carry different SDP descriptions than that 383 communicated in the first phase. 385 Upon reception of the INVITE message, the terminating MTA responds 386 based upon its QoS reservation. If the reservation is unsuccessful 387 then it MUST return an error indication. If the reservation is 388 successful, the terminating MTA MUST return 180 ringing message and 389 alert the user, or return a 200 OK message directly when the called 390 user picks up. 392 5. Advantages of the Proposed Approach 394 The use of two-phase call signaling makes it possible for SIP to 395 meet user expectations that come from the telephony services. 397 The reservation of resources before the user is alerted makes sure 398 that the network resources are assured before the destination end- 399 point is informed about the call. 401 The number of messages and the total delay introduced by these 402 messages is kept to a minimum without sacrificing compatibility with 403 classic SIP. 405 Because the response messages to second phase goes directly end-to- 406 end between the endpoints without traversing the DCS-proxies, the 407 post-dial-delay is minimized. This reduces the chance that the 408 "hello" greeting of the caller (in response to the callee's 409 greeting) gets clipped. 411 6. Security Considerations 413 There are no security implication recognized by the extensions 414 proposed in this draft. 416 7. References 418 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 419 9, RFC 2026, October 1996. 421 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 422 Levels", BCP 14, RFC 2119, March 1997 424 3 DCS Group, "Architectural Considerations for Providing Carrier 425 Class Telephony Services Utilizing SIP-based Distributed Call 426 Control Mechanisms", draft-dcsgroup-sip-arch-01.txt, October 427 1999. 429 DCS Group Category Informational - Expiration 4/30/00 8 430 Integration of Resource Mgmt and Signaling October 1999 432 4 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 433 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 434 Demon Internet Ltd., November 1997 436 8. Acknowledgments 438 The Distributed Call Signaling work in the PacketCable project is 439 the work of a large number of people, representing many different 440 companies. The authors would like to recognize and thank the 441 following for their assistance: John Wheeler, Motorola; David 442 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 443 Jay Strater, Jeff Ollis, Clive Holborow, General Instruments; Doug 444 Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay 445 Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael 446 Ramalho, Cisco; and Chuck Kalmanek, Doug Nortz, John Lawser, James 447 Cheng, Tung-Hai Hsiao, and Partho Mishra, AT&T. 449 9. Author's Addresses 451 Bill Marshall 452 AT&T 453 Florham Park, NJ 07932 454 Email: wtm@research.att.com 456 K. K. Ramakrishnan 457 AT&T 458 Florham Park, NJ 07932 459 Email: kkrama@research.att.com 461 Ed Miller 462 CableLabs 463 Louisville, CO 80027 464 Email: E.Miller@Cablelabs.com 466 Glenn Russell 467 CableLabs 468 Louisville, CO 80027 469 Email: G.Russell@Cablelabs.com 471 Burcak Beser 472 3Com 473 Rolling Meadows, IL 60008 474 Email: Burcak_Beser@3com.com 476 Mike Mannette 477 3Com 479 DCS Group Category Informational - Expiration 4/30/00 9 480 Integration of Resource Mgmt and Signaling October 1999 482 Rolling Meadows, IL 60008 483 Email: Michael_Mannette@3com.com 485 Kurt Steinbrenner 486 3Com 487 Rolling Meadows, IL 60008 488 Email: Kurt_Steinbrenner@3com.com 490 Dave Oran 491 Cisco 492 Acton, MA 01720 493 Email: oran@cisco.com 495 John Pickens 496 Com21 497 San Jose, CA 498 Email: jpickens@com21.com 500 Poornima Lalwaney 501 General Instrument 502 San Diego, CA 92121 503 Email: plalwaney@gi.com 505 Jon Fellows 506 General Instrument 507 San Diego, CA 92121 508 Email: jfellows@gi.com 510 Doc Evans 511 Lucent Cable Communications 512 Westminster, CO 30120 513 Email: n7dr@lucent.com 515 Keith Kelly 516 NetSpeak 517 Boca Raton, FL 33587 518 Email: keith@netspeak.com 520 Flemming Andreasen 521 Telcordia 522 Piscataway, NJ 523 Email: fandreas@telcordia.com 525 DCS Group Category Informational - Expiration 4/30/00 10 526 Integration of Resource Mgmt and Signaling October 1999 528 Full Copyright Statement 530 "Copyright (C) The Internet Society (date). All Rights Reserved. 531 This document and translations of it may be copied and furnished to 532 others, and derivative works that comment on or otherwise explain it 533 or assist in its implmentation may be prepared, copied, published 534 and distributed, in whole or in part, without restriction of any 535 kind, provided that the above copyright notice and this paragraph 536 are included on all such copies and derivative works. However, this 537 document itself may not be modified in any way, such as by removing 538 the copyright notice or references to the Internet Society or other 539 Internet organizations, except as needed for the purpose of 540 developing Internet standards in which case the procedures for 541 copyrights defined in the Internet Standards process must be 542 followed, or as required to translate it into languages other than 543 English. The limited permissions granted above are perpetual and 544 will not be revoked by the Internet Society or its successors or 545 assigns. This document and the information contained herein is 546 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 547 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 548 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 549 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 550 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 552 Expiration Date This memo is filed as , and expires April 30, 2000. 555 DCS Group Category Informational - Expiration 4/30/00 11