idnits 2.17.1 draft-ietf-sip-state-02.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): ---------------------------------------------------------------------------- ** 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 document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 252 has weird spacing: '... Where enc ...' -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 48 looks like a reference -- Missing reference section? '2' on line 89 looks like a reference -- Missing reference section? '4' on line 92 looks like a reference -- Missing reference section? '5' on line 199 looks like a reference -- Missing reference section? '3' on line 221 looks like a reference -- Missing reference section? '6' on line 432 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group W. Marshall 3 Internet Draft AT&T 4 Document: 5 K. Ramakrishnan 6 TeraOptic Networks 8 E. Miller 9 Terayon 11 G. Russell 12 CableLabs 14 B. Beser 15 Pacific Broadband 17 M. Mannette 18 K. Steinbrenner 19 3Com 21 D. Oran 22 F. Andreasen 23 Cisco 25 J. Pickens 26 Com21 28 P. Lalwaney 29 Nokia 31 J. Fellows 32 Copper Mountain Networks 34 D. Evans 35 D. R. Evans Consulting 37 K. Kelly 38 NetSpeak 40 August, 2001 42 SIP Extensions for supporting Distributed Call State 44 Status of this Memo 46 This document is an Internet-Draft and is in full conformance with 47 all provisions of Section 10 of RFC2026[1]. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF), its areas, and its working groups. Note that 51 other groups may also distribute working documents as Internet- 52 Drafts. Internet-Drafts are draft documents valid for a maximum of 53 six months and may be updated, replaced, or obsoleted by other 55 SIP Working Group Expiration 02/28/02 1 56 SIP Extensions for Distributed Call State August 2001 58 documents at any time. It is inappropriate to use Internet- Drafts 59 as reference material or to cite them other than as "work in 60 progress." 62 The list of current Internet-Drafts can be accessed at 63 http://www.ietf.org/ietf/1id-abstracts.txt 65 The list of Internet-Draft Shadow Directories can be accessed at 66 http://www.ietf.org/shadow.html. 68 The distribution of this memo is unlimited. It is filed as , and expires February 28, 2002. Please send 70 comments to the authors. 72 1. Abstract 74 This document describes an extension to the Session Initiation 75 Protocol (SIP) that enables proxies to distribute call state to user 76 agents. The state information can be returned to the proxy when the 77 user agent requests a change in the characteristics of the active 78 call. By providing the ability to distribute state to the user 79 agents where it can be securely stored, proxy servers can remain 80 stateless for the duration of the call. This mechanism allows a 81 proxy server to provide services that depend on call state, while 82 still being stateless. 84 2. Conventions used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 88 this document are to be interpreted as described in RFC-2119 [2]. 90 3. Introduction 92 In the Session Initiation Protocol (SIP) [4] proxies play the role 93 of routing engines and delivery platforms for services. Many types 94 of services require these proxies to retain call state. That is, 95 these proxies know how to correlate SIP messages in order to 96 reconstruct the state of calls that exist in the user agents. 97 Unfortunately, maintaining call state presents problems. First, it 98 introduces scalability problems when there are many user agents 99 being served by a single proxy. Second, it makes failover and load 100 balancing more complex, since once state is established in one 101 proxy, subsequent signaling must return to the same proxy in order 102 for proper service execution. 104 To achieve scalability when handling signaling messages from a large 105 number of calls, SIP proxies must minimize the per call information 106 that they need to maintain. One method of achieving this is for the 107 proxy to transfer the state associated with a call to entities where 109 SIP Working Group Expiration 02/28/02 2 110 SIP Extensions for Distributed Call State August 2001 112 the state is relevant. In addition, the proxy should be able to 113 retrieve and update the call state information if the 114 characteristics of the active call are changed. 116 The extension proposed in this document allows proxies to 117 encapsulate any state information they desire into a header, called 118 a State header, that is delivered to the user agents for a call. 119 This information is reflected back in subsequent messages. This 120 effectively allows proxies to store call state in user agents - 121 behaving as SIP stateful proxies while still being stateless. 123 In this draft, we propose the following extension to SIP to support 124 the distribution of call state: 126 1) A new general State header field that can be used to distribute 127 call state information by the proxy to the UA during call setup or 128 mid-call. The state information can also be encrypted, and contain 129 an integrity check value, to guarantee detection of tampering by an 130 untrusted UA. 132 If the UA wishes to change call characteristics, it passes the saved 133 state information (which may be proxy encrypted and integrity 134 protected) in a SIP INVITE request to its proxy server. The proxy 135 is then able to perform the requested action, just as if the proxy 136 had maintained the call state information itself. By using this 137 mechanism, the proxies can offer the full range of services, yet 138 remain stateless during the call. 140 2) A new option tag "state" is defined. This is to be used in the 141 Supported header [5] by the initiating UA in its request to inform 142 its proxy server that it understands and supports the behavior 143 required by the State header. The responses would also include the 144 Supported header with the option tag "state". In addition, proxy 145 servers that transfer State to the UAS MUST also include a Require 146 and a Proxy-Require header field with the option tag "state" if the 147 proxy requires support for the extension. 149 4. Protocol Overview 151 Outlined below is an overview of the usage of the State header for 152 distributing call state. 154 Consider a basic SIP INVITE-200 OK-ACK transaction. The UAC 155 initiating the call sends an INVITE request to its proxy with the 156 called party information. If the UAC supports the State header, the 157 Supported header with the option tag "state" MUST be included in the 158 request. The originating proxy locates the SIP proxy associated with 159 the called party (referred to here as the terminating proxy) and 160 forwards the INVITE to it. After the terminating proxy processes the 161 INVITE, it has the information about the call being set up. The 162 terminating proxy can pass this state information to the 163 terminating/called UA in the State header. The State header includes 164 a host value to identify the proxy that inserted the state token(s) 166 SIP Working Group Expiration 02/28/02 3 167 SIP Extensions for Distributed Call State August 2001 169 that follows. In addition, the proxy MAY insert a Require and a 170 Proxy-Require header field with the value "state" if it wishes the 171 call to only be established if the State extension can be supported. 173 If the UAS supports the State extension, the State header along with 174 the Supported header with an option tag of "state" is reflected back 175 in the response. When the response to the INVITE (200 OK or the 176 first non-100 1xx response) arrives at the originating proxy, the 177 proxy has the complete call state information about the call being 178 setup. When forwarding the response to the calling UA, the proxy 179 includes this call state information in the State header. 181 The state information distribution described above between the proxy 182 and the UA works for a network of proxies in the signaling path as 183 well. If a proxy along the path wishes to distribute call state to 184 the user agents, it adds a State header to the request (or the 185 response). The State header includes a host value by which the 186 proxy can identify itself followed by its state token(s) and any 187 State header(s) inserted by other proxies. 189 The UAS that receives the State header(s) stores the headers and 190 associates them with the call-leg. 192 The rules for when and how the stored state information is returned 193 by the UA to the proxy are discussed in detail in the next section. 195 5. SIP Header Extension and Option Tag for Distributing Call State 197 If the State header is to be used to distribute state in a call, the 198 UAC initiating the call MUST include the Supported header defined in 199 [5] with the option tag "state" in the initial INVITE request. 201 UAS's receiving the Supported header with the value "state" MUST 202 include the Supported header with an option tag of "state" in 203 responses if they are capable of processing the State header 204 extension. 206 A proxy in the signaling path MUST insert a Require and a Proxy- 207 Require header with an option tag of "state" if it inserts a State 208 header in the request or response. 210 5.1 State Header Syntax 212 The State header contains any information a proxy would like 213 returned to it in subsequent messaging from the UA's for the same 214 call leg. This might include information for support of mid-call 215 features, billing information, etc. It is RECOMMENDED that this 216 information be protected by an integrity check mechanism. This 217 allows the proxy to reliably and securely store state information in 218 the client that may be needed for subsequent feature invocation. 220 The following syntax specification uses the augmented Backus-Naur 221 Form (BNF) as described in RFC-2234 [3]. 223 SIP Working Group Expiration 02/28/02 4 224 SIP Extensions for Distributed Call State August 2001 226 State = "State" ":" 1#(hostport ";" state-token 227 *(";" state-token)) 228 state-token = token ["=" (*token | quoted-string)] 230 The hostport field identifies the proxy that inserted the state 231 information. 233 State headers may be nested. In this case, a proxy in the signaling 234 path takes the State header(s) it received in the incoming signaling 235 message (previous host; token form), possibly adds any state-tokens 236 of its own, and generates a single new State header. The hostname 237 in the nested State header identifies the proxy that performed the 238 nesting. 240 Multiple State headers MAY be present in a request (or response). In 241 addition, the syntax allows for a proxy to insert multiple tokens in 242 the header. 244 The state token is a proxy-defined encoding of a structure 245 containing multiple pieces of information needed by the proxy to 246 perform various call features. The structure is returned from the 247 UA to its proxy for call services that affect the current call. 249 The following defines the entry for the State header of Table 5 in 250 RFC 2543. 252 Where enc e-e ACK BYE CAN INV OPT REG 253 State gc n h o o o o o o 255 6 Detailed Protocol Semantics 257 The protocol semantics for a UAC, a UAS and the proxy are addressed 258 in this section. 260 6.1 UAC behavior 262 The rules at the UAC for processing State headers are listed below: 264 1. A UAC supporting this extension MUST include a Supported header 265 field with an option tag of "state" in the initial INVITE and all 266 subsequent requests and responses. 268 2. The UAC MUST save the received State header(s) along with the 269 From, To, Call-ID and tags associated with the To and From header 270 fields for the duration of the call. 272 3. On a subsequent request, the UAC includes the State header(s) in 273 the request if the From, To (including ones with From and To 274 reversed), Call-ID and the tags on the From and To match those 276 SIP Working Group Expiration 02/28/02 5 277 SIP Extensions for Distributed Call State August 2001 279 associated with the saved State header(s) and Request-URI matches 280 the hostname of the saved State header(s). If Route header is 281 present, the UAC also includes State headers that have hostname 282 matching a component of the Route header. 284 4. Additional rules MAY be defined by other extensions that specify 285 when a State header is to be included in a request. An example of 286 this would be extensions that handle call transfers and other 287 features that would specify State header processing at the UAC. 289 5. When a call leg ends, the UAC MAY delete all saved State headers 290 associated with the call leg. 292 6.2 UAS behavior 294 The rules at the UAS for processing State headers are listed below: 296 1. A UAS that supports this extension MUST include a Supported header 297 with the token value "state" in all responses. 299 2. The UAS MUST save the received State header(s) along with the 300 From, To, Call-ID and tags associated with the To and From header 301 fields for the duration of the call, or until a new request with 302 the State is received. 304 3. In all non-100 responses to all requests, the UAS MUST include the 305 State header(s) received in that request, and a Supported: "state" 306 header. 308 6.3 Proxy Behavior 310 To support this extension, the Proxy MUST perform the following 311 functions: 313 1. A State header that is received in a request or response, with a 314 hostname other than the proxy's, MUST be passed on. 316 2. A Proxy that hides Via headers in a request MUST nest all the 317 State headers received in the request. Further, the proxy MUST 318 restore these State headers when that nested State header is 319 received in a request or response. 321 3. A proxy that hides Record-Route headers in a request MUST nest 322 all the State headers received in that request. Further, the 323 proxy MUST restore these State headers when that nested State 324 header is received in a request or response. 326 4. Requirements on a proxy that hides Record-Route headers in a 327 response, or that hides Route headers, MUST nest all the State 328 headers received in that request. Further, the proxy MUST 329 restore these State headers when that nested State header is 330 received in a request or response. 332 SIP Working Group Expiration 02/28/02 6 333 SIP Extensions for Distributed Call State August 2001 335 In addition, a proxy MAY do the following to utilize the capability 336 offered by this extension: 338 1. A State header received in a request or response with the hostname 339 matching the proxy MAY be discarded. 341 2. A proxy MAY generate one or more State headers, and include it (or 342 them) in any request or response. A proxy that generates State 343 headers MUST insert a "Require: state" header, and a "Proxy- 344 Require: state" header, in the request if not already present. 346 3. A proxy MAY nest all, or any subset, of the State headers received 347 in a request or response. A proxy that nests State headers MUST 348 restore these State headers when that nested State header is 349 received in a request or response. 351 6.4 Example of use 353 The following example illustrates the distribution of state during 354 call setup and issues associated with concatenation and encryption 355 of State headers. UAC and UAS refer to the originating and 356 terminating User Agent for the call. P1 is the proxy associated with 357 UAC and P2 is the proxy associated with UAS. eP1{*} refers to the 358 state token encrypted by P1. 360 UAC -> P1 -> P2 -> UAS 362 UAC->P1: invite 363 Supported: state 365 P1->P2: invite 366 State:P1;state=eP1{"cached translation 367 of UAS's number"} 368 Supported: state 369 Require: state 371 In this example, P2 formulates a single State header by combining 372 the State header received from the previous proxy(ies). 374 P2->UAS: invite 375 State:P2;state=eP2{"hunt group ID, 376 billing ID,P1;state=eP1{"cached 377 translation of UAS's number"}"} 378 Supported: state 379 Require: state 381 UAS saves the above state information received from its proxy P2 for 382 the duration of the call. 384 UAS->P2: response 386 SIP Working Group Expiration 02/28/02 7 387 SIP Extensions for Distributed Call State August 2001 389 State:P2; state=eP2{"hunt group ID, 390 billing ID,P1;state=eP1{"cached 391 translation of UAS's number"}"} 392 Supported: state 394 As P2 combined all State headers into one when sending the INVITE to 395 the UAS, it is responsible for restoring the State headers as 396 received in the INVITE before forwarding the response to P1 with its 397 updated State header. 399 P2->P1: response 400 State:P2;state=eP2{"hunt group ID, 401 billing ID"},P1;state=eP1{"cached 402 translation of UAS's number"} 403 Supported: state 405 P1->UAC: response 406 state:P1;state=eP1{"billing ID, 407 cached translation of UAS's 408 number, P2;state=eP2{"hunt group ID, 409 billing ID"}"} 410 Supported: state 412 UAC saves the state information received from P1 for the duration of 413 the call. 415 When the call begins, state at UAC is: 416 State:P1;state=eP1{"billing ID, cached translation of UAS's 417 number", P2;state=eP2{"hunt group ID, billing ID"}"} 419 State at UAS is: 420 State:P2;state=eP2{"hunt group ID, billing ID,P1;state=eP1{" 421 cached translation of UAS's number"}"} 423 Note that the state information for the call at the UAC and UAS is 424 different. Proxies therefore need to be aware of the direction from 425 which they receive the State header. This may be information 426 included in the state token or may be deduced from other headers in 427 the message. 429 7 State Header and HTTP Cookie/Pcookie Comparison 431 The State header field discussed in this section differs from the 432 HTTP1.1 Cookies as described in [6]. In a general sense, both 433 transfer state between the server and the client. HTTP uses the 434 Cookie for "state" management, or as a handle to pass session 435 context change from server to client where the server is the other 436 endpoint of the session. Cookies typically persist across sessions. 437 On the other hand, the State header is used to transfer current call 438 state from a proxy or intermediate network proxies to the UAC and 439 the UAS. The state header can be considered to be a handle to 440 request a change in the active/current session by the endpoint from 441 its proxy. In addition, there are no attribute value pairs 443 SIP Working Group Expiration 02/28/02 8 444 SIP Extensions for Distributed Call State August 2001 446 associated with the State header as there are in the Cookie 447 mechanism. 449 8 Security Considerations 451 If the clients/endpoints are considered untrusted entities, the 452 proxy must encrypt the State header and include an integrity check 453 with the State header information. In addition, the proxy is 454 responsible for verifying the contents and integrity of the State 455 header returned by the client as discussed in this document. 457 9 Notice Regarding Intellectual Property Rights 459 The IETF has been notified of intellectual property rights claimed 460 in regard to some or all of the specification contained in this 461 document. For more information consult the online list of claimed 462 rights. 464 10 References 466 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 467 9, RFC 2026, October 1996. 469 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 470 Levels", BCP 14, RFC 2119, March 1997 472 3. Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 473 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 474 Demon Internet Ltd., November 1997 476 4. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,"SIP: 477 session initiation protocol," Request for Comments (Proposed 478 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 480 5. J. Rosenberg and H. Schulzrinne, "The SIP Supported Header", 481 draft-ietf-sip-serverfeatures-02.txt, September 2000. 483 6. Kristol, D. and Montulli, L., "HTTP State Management Mechanism", 484 RFC 2109, February 1997. 486 11 Acknowledgements 488 The Distributed Call Signaling work in the PacketCable project is 489 the work of a large number of people, representing many different 490 companies. The authors would like to recognize and thank the 491 following for their assistance: John Wheeler, Motorola; David 492 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 493 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 494 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 495 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 497 SIP Working Group Expiration 02/28/02 9 498 SIP Extensions for Distributed Call State August 2001 500 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 501 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 502 Cable Communications. 504 Many thanks to Jonathan Rosenberg for extensive comments on this 505 draft. 507 12 Author's Addresses 509 Bill Marshall 510 AT&T 511 Florham Park, NJ 07932 512 Email: wtm@research.att.com 514 K. K. Ramakrishnan 515 TeraOptic Networks 516 Summit, NJ 07901 517 Email: kk@teraoptic.com 519 Ed Miller 520 Terayon 521 Louisville, CO 80027 522 Email: E.Miller@terayon.com 524 Glenn Russell 525 CableLabs 526 Louisville, CO 80027 527 Email: G.Russell@Cablelabs.com 529 Burcak Beser 530 Pacific Broadband Communications 531 San Jose, CA 532 Email: Burcak@pacband.com 534 Mike Mannette 535 3Com 536 Rolling Meadows, IL 60008 537 Email: Michael_Mannette@3com.com 539 Kurt Steinbrenner 540 3Com 541 Rolling Meadows, IL 60008 542 Email: Kurt_Steinbrenner@3com.com 544 Dave Oran 545 Cisco 546 Acton, MA 01720 547 Email: oran@cisco.com 549 Flemming Andreasen 550 Cisco 551 Edison, NJ 553 SIP Working Group Expiration 02/28/02 10 554 SIP Extensions for Distributed Call State August 2001 556 Email: fandreas@cisco.com 558 John Pickens 559 Com21 560 San Jose, CA 561 Email: jpickens@com21.com 563 Poornima Lalwaney 564 Nokia 565 San Diego, CA 92121 566 Email: poornima.lalwaney@nokia.com 568 Jon Fellows 569 Copper Mountain Networks 570 San Diego, CA 92121 571 Email: jfellows@coppermountain.com 573 Doc Evans 574 D. R. Evans Consulting 575 Boulder, CO 80303 576 Email: n7dr@arrl.net 578 Keith Kelly 579 NetSpeak 580 Boca Raton, FL 33587 581 Email: keith@netspeak.com 583 SIP Working Group Expiration 02/28/02 11 584 SIP Extensions for Distributed Call State August 2001 586 Full Copyright Statement 588 "Copyright (C) The Internet Society (date). All Rights Reserved. 589 This document and translations of it may be copied and furnished to 590 others, and derivative works that comment on or otherwise explain it 591 or assist in its implementation may be prepared, copied, published 592 and distributed, in whole or in part, without restriction of any 593 kind, provided that the above copyright notice and this paragraph 594 are included on all such copies and derivative works. However, this 595 document itself may not be modified in any way, such as by removing 596 the copyright notice or references to the Internet Society or other 597 Internet organizations, except as needed for the purpose of 598 developing Internet standards in which case the procedures for 599 copyrights defined in the Internet Standards process must be 600 followed, or as required to translate it into languages other than 601 English. The limited permissions granted above are perpetual and 602 will not be revoked by the Internet Society or its successors or 603 assigns. This document and the information contained herein is 604 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 605 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 606 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 607 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 610 Expiration Date: This memo is filed as , and expires February 28, 2002. 613 SIP Working Group Expiration 02/28/02 12