idnits 2.17.1 draft-dcsgroup-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 5) 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. ** There are 15 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 239 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 42 looks like a reference -- Missing reference section? '2' on line 80 looks like a reference -- Missing reference section? '4' on line 83 looks like a reference -- Missing reference section? '5' on line 133 looks like a reference -- Missing reference section? '6' on line 188 looks like a reference -- Missing reference section? '3' on line 210 looks like a reference -- Missing reference section? '7' on line 410 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 6 E. Miller 7 G. Russell 8 CableLabs 10 B. Beser 11 M. Mannette 12 K. Steinbrenner 13 3Com 15 D. Oran 16 F. Andreasen 17 Cisco 19 J. Pickens 20 Com21 22 P. Lalwaney 23 Nokia 25 J. Fellows 26 Motorola 28 D. Evans 29 Secure Cable Solutions 31 K. Kelly 32 NetSpeak 34 July, 2000 36 SIP Extensions for supporting Distributed Call State 38 Status of this Memo 40 This document is an Internet-Draft and is in full conformance with 41 all provisions of Section 10 of RFC2026[1]. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. Internet-Drafts are draft documents valid for a maximum of 47 six months and may be updated, replaced, or obsoleted by other 48 documents at any time. It is inappropriate to use Internet- Drafts 49 as reference material or to cite them other than as "work in 50 progress." 52 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 DCS Group Internet Draft - Expiration 01/31/01 1 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html. 59 The distribution of this memo is unlimited. It is filed as , and expires January 31, 2001. Please 61 send comments to the authors. 63 1. Abstract 65 This document describes an extension to the Session Initiation 66 Protocol (SIP) that enables proxies to distribute call state to user 67 agents. The state information can be returned to the proxy when the 68 user agent requests a change in the characteristics of the active 69 call. By providing the ability to distribute state to the user 70 agents where it can be securely stored, proxy servers can remain 71 stateless for the duration of the call. This mechanism allows a 72 proxy server to provide services that depend on call state, while 73 still being stateless. 75 2. Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 79 this document are to be interpreted as described in RFC-2119 [2]. 81 3. Introduction 83 In the Session Initiation Protocol (SIP) [4] proxies play the role 84 of routing engines and delivery platforms for services. Many types 85 of services require these proxies to retain call state. That is, 86 these proxies know how to correlate SIP messages in order to 87 reconstruct the state of calls that exist in the user agents. 88 Unfortunately, maintaining call state presents problems. First, it 89 introduces scalability problems when there are many user agents 90 being served by a single proxy. Second, it makes failover and load 91 balancing more complex, since once state is established in one 92 proxy, subsequent signaling must return to the same proxy in order 93 for proper service execution. 95 To achieve scalability when handling signaling messages from a large 96 number of calls, SIP proxies must minimize the per call information 97 that they need to maintain. One method of achieving this is for the 98 proxy to transfer the state associated with a call to entities where 99 the state is relevant. In addition, the proxy should be able to 100 retrieve and update the call state information if the 101 characteristics of the active call are changed. 103 The extension proposed in this document allows proxies to 104 encapsulate any state information they desire into a header, called 106 DCS Group Internet Draft - Expiration 01/31/01 2 107 a State header, that is delivered to the user agents for a call. 108 This information is reflected back in subsequent messages. This 109 effectively allows proxies to store call state in user agents - 110 behaving as SIP stateful proxies while still being stateless. 112 In this draft, we propose the following extension to SIP to support 113 the distribution of call state: 115 1) A new general State header field that can be used to distribute 116 call state information by the proxy to the UA during call setup or 117 mid-call. The state information can also be encrypted, and contain 118 an integrity check value, to guarantee detection of tampering by an 119 untrusted UA. 121 If the UA wishes to change call characteristics, it passes the saved 122 state information (which may be proxy encrypted and integrity 123 protected) in a SIP INVITE request to its proxy server. The proxy 124 is then able to perform the requested action, just as if the proxy 125 had maintained the call state information itself. By using this 126 mechanism, the proxies can offer the full range of services, yet 127 remain stateless during the call. 129 The above mechanism for distributing state information is used in 130 the Distributed call signaling (DCS) architecture [5]. 132 2) A new option tag "state" is defined. This is to be used in the 133 Supported header [5] by the initiating UA in its request to inform 134 its proxy server that it understands and supports the behavior 135 required by the State header. The responses would also include the 136 Supported header with the option tag "state". In addition, proxy 137 servers that transfer State to the UAS MUST also include a Require 138 and a Proxy-Require header field with the option tag "state" if the 139 proxy requires support for the extension. 141 4. Protocol Overview 143 Outlined below is an overview of the usage of the State header for 144 distributing call state. 146 Consider a basic SIP INVITE-200 OK-ACK transaction. The UAC 147 initiating the call sends an INVITE request to its proxy with the 148 called party information. If the UAC supports the State header, the 149 Supported header with the option tag "state" MUST be included in the 150 request. The originating proxy locates the SIP proxy associated with 151 the called party (referred to here as the terminating proxy) and 152 forwards the INVITE to it. After the terminating proxy processes the 153 INVITE, it has the information about the call being set up. The 154 terminating proxy can pass this state information to the 155 terminating/called UA in the State header. The State header includes 156 a host value to identify the proxy that inserted the state token(s) 157 that follows. In addition, the proxy MAY insert a Require and a 158 Proxy-Require header field with the value "state" if it wishes the 159 call to only be established if the State extension can be supported. 161 DCS Group Internet Draft - Expiration 01/31/01 3 162 If the UAS supports the State extension, the State header along with 163 the Supported header with an option tag of "state" is reflected back 164 in the response. When the response to the INVITE (200 OK or the 165 first non-100 1xx response) arrives at the originating proxy, the 166 proxy has the complete call state information about the call being 167 setup. When forwarding the response to the calling UA, the proxy 168 includes this call state information in the State header. 170 The state information distribution described above between the proxy 171 and the UA works for a network of proxies in the signaling path as 172 well. If a proxy along the path wishes to distribute call state to 173 the user agents, it adds a State header to the request (or the 174 response). The State header includes a host value by which the 175 proxy can identify itself followed by its state token(s) and any 176 State header(s) inserted by other proxies. 178 The UAS that receives the State header(s) stores the headers and 179 associates them with the call-leg. 181 The rules for when and how the stored state information is returned 182 by the UA to the proxy are discussed in detail in the next section. 184 5. SIP Header Extension and Option Tag for Distributing Call State 186 If the State header is to be used to distribute state in a call, the 187 UAC initiating the call MUST include the Supported header defined in 188 [6] with the option tag "state" in the initial INVITE request. 190 UAS's receiving the Supported header with the value "state" MUST 191 include the Supported header with an option tag of "state" in 192 responses if they are capable of processing the State header 193 extension. 195 A proxy in the signaling path MUST insert a Require and a Proxy- 196 Require header with an option tag of "state" if it inserts a State 197 header in the request or response. 199 5.1 State Header Syntax 201 The State header contains any information a proxy would like 202 returned to it in subsequent messaging from the UA's for the same 203 call leg. This might include information for support of mid-call 204 features, billing information, etc. It is RECOMMENDED that this 205 information be protected by an integrity check mechanism. This 206 allows the proxy to reliably and securely store state information in 207 the client that may be needed for subsequent feature invocation. 209 The following syntax specification uses the augmented Backus-Naur 210 Form (BNF) as described in RFC-2234 [3]. 212 DCS Group Internet Draft - Expiration 01/31/01 4 213 State = "State" ":" 1#(host ";" state-token 214 *(";" state-token)) 215 state-token = token ["=" (*token | quoted-string)] 217 The host field identifies the proxy that inserted the state 218 information. 220 State headers may be nested. In this case, a proxy in the signaling 221 path takes the State header(s) it received in the incoming signaling 222 message (previous host; token form), possibly adds any state-tokens 223 of its own, and generates a single new State header. The hostname 224 in the nested State header identifies the proxy that performed the 225 nesting. 227 Multiple State headers MAY be present in a request (or response). In 228 addition, the syntax allows for a proxy to insert multiple tokens in 229 the header. 231 The state token is a proxy-defined encoding of a structure 232 containing multiple pieces of information needed by the proxy to 233 perform various call features. The structure is returned from the 234 UA to its proxy for call services that affect the current call. 236 The following defines the entry for the State header of Table 5 in 237 RFC 2543. 239 Where enc e-e ACK BYE CAN INV OPT REG 241 State gc n h o o o o o o 243 6 Detailed Protocol Semantics 245 The protocol semantics for a UAC, a UAS and the proxy are addressed 246 in this section. 248 6.1 UAC behavior 250 The rules at the UAC for processing State headers are listed below: 252 1. A UAC supporting this extension MUST include a Supported header 253 field with an option tag of "state" in the initial INVITE and all 254 subsequent requests and responses. 256 2. The UAC MUST save the received State header(s) along with the 257 From, To, Call-ID and tags associated with the To and From header 258 fields for the duration of the call. 260 3. On a subsequent request, the UAC includes the State header(s) in 261 the request if the From, To (including ones with From and To 262 reversed), Call-ID and the tags on the From and To match those 263 associated with the saved State header(s) and Request-URI matches 264 the hostname of the saved State header(s). If Route header is 266 DCS Group Internet Draft - Expiration 01/31/01 5 267 present, the UAC also includes State headers that have hostname 268 matching a component of the Route header. 270 4. Additional rules MAY be defined by other extensions that specify 271 when a State header is to be included in a request. An example of 272 this would be extensions that handle call transfers and other 273 features that would specify State header processing at the UAC. 275 5. When a call leg ends, the UAC MAY delete all saved State headers 276 associated with the call leg. 278 6.2 UAS behavior 280 The rules at the UAS for processing State headers are listed below: 282 1. A UAS that supports this extension MUST include a Supported header 283 with the token value "state" in all responses. 285 2. The UAS MUST save the received State header(s) along with the 286 From, To, Call-ID and tags associated with the To and From header 287 fields for the duration of the call, or until a new request with 288 the State is received. 290 3. In all non-100 responses to all requests, the UAS MUST include the 291 State header(s) received in that request, and a Supported: "state" 292 header. 294 6.3 Proxy Behavior 296 To support this extension, the Proxy MUST perform the following 297 functions: 299 1. A State header that is received in a request or response, with a 300 hostname other than the proxy's, MUST be passed on. 302 2. A Proxy that hides Via headers in a request MUST nest all the 303 State headers received in the request. Further, the proxy MUST 304 restore these State headers when that nested State header is 305 received in a request or response. 307 3. A proxy that hides Record-Route headers in a request MUST nest 308 all the State headers received in that request. Further, the 309 proxy MUST restore these State headers when that nested State 310 header is received in a request or response. 312 4. Requirements on a proxy that hides Record-Route headers in a 313 response, or that hides Route headers, is for further study. 315 In addition, a proxy MAY do the following to utilize the capability 316 offered by this extension: 318 DCS Group Internet Draft - Expiration 01/31/01 6 319 1. A State header received in a request or response with the hostname 320 matching the proxy MAY be discarded. 322 2. A proxy MAY generate one or more State headers, and include it (or 323 them) in any request or response. A proxy that generates State 324 headers MUST insert a "Require: state" header, and a "Proxy- 325 Require: state" header, in the request if not already present. 327 3. A proxy MAY nest all, or any subset, of the State headers received 328 in a request or response. A proxy that nests State headers MUST 329 restore these State headers when that nested State header is 330 received in a request or response. 332 6.4 Example of use 334 The following example illustrates the distribution of state during 335 call setup and issues associated with concatenation and encryption 336 of State headers. UAC and UAS refer to the originating and 337 terminating User Agent for the call. P1 is the proxy associated with 338 UAC and P2 is the proxy associated with UAS. eP1{*} refers to the 339 state token encrypted by P1. 341 UAC -> P1 -> P2 -> UAS 343 UAC->P1: invite 344 Supported: state 346 P1->P2: invite 347 State:P1;state=eP1{"cached translation 348 of UAS's number"} 349 Supported: state 350 Require: state 352 In this example, P2 formulates a single State header by combining 353 the State header received from the previous proxy(ies). 355 P2->UAS: invite 356 State:P2;state=eP2{"hunt group ID, 357 billing ID,P1;state=eP1{"cached 358 translation of UAS's number"}"} 359 Supported: state 360 Require: state 362 UAS saves the above state information received from its proxy P2 for 363 the duration of the call. 365 UAS->P2: response 366 State:P2; state=eP2{"hunt group ID, 367 billing ID,P1;state=eP1{"cached 368 translation of UAS's number"}"} 369 Supported: state 371 DCS Group Internet Draft - Expiration 01/31/01 7 372 As P2 combined all State headers into one when sending the INVITE to 373 the UAS, it is responsible for restoring the State headers as 374 received in the INVITE before forwarding the response to P1 with its 375 updated State header. 377 P2->P1: response 378 State:P2;state=eP2{"hunt group ID, 379 billing ID"},P1;state=eP1{"cached 380 translation of UAS's number"} 381 Supported: state 383 P1->UAC: response 384 state:P1;state=eP1{"billing ID, 385 cached translation of UAS's 386 number, P2;state=eP2{"hunt group ID, 387 billing ID"}"} 388 Supported: state 390 UAC saves the state information received from P1 for the duration of 391 the call. 393 When the call begins, state at UAC is: 394 State:P1;state=eP1{"billing ID, cached translation of UAS's 395 number", P2;state=eP2{"hunt group ID, billing ID"}"} 397 State at UAS is: 398 State:P2;state=eP2{"hunt group ID, billing ID,P1;state=eP1{" 399 cached translation of UAS's number"}"} 401 Note that the state information for the call at the UAC and UAS is 402 different. Proxies therefore need to be aware of the direction from 403 which they receive the State header. This may be information 404 included in the state token or may be deduced from other headers in 405 the message. 407 7 State Header and HTTP Cookie/Pcookie Comparison 409 The State header field discussed in this section differs from the 410 HTTP1.1 Cookies as described in [7]. In a general sense, both 411 transfer state between the server and the client. HTTP uses the 412 Cookie for "state" management, or as a handle to pass session 413 context change from server to client where the server is the other 414 endpoint of the session. Cookies typically persist across sessions. 415 On the other hand, the State header is used to transfer current call 416 state from a proxy or intermediate network proxies to the UAC and 417 the UAS. The state header can be considered to be a handle to 418 request a change in the active/current session by the endpoint from 419 its proxy. In addition, there are no attribute value pairs 420 associated with the State header as there are in the Cookie 421 mechanism. 423 8 Security Considerations 425 DCS Group Internet Draft - Expiration 01/31/01 8 426 If the clients/endpoints are considered untrusted entities, the 427 proxy must encrypt the State header and include an integrity check 428 with the State header information. In addition, the proxy is 429 responsible for verifying the contents and integrity of the State 430 header returned by the client as discussed in this document. 432 9 Notice Regarding Intellectual Property Rights 434 AT&T may seek patent or other intellectual property protection for 435 some or all of the technologies disclosed in the document. If any 436 standards arising from this disclosure are or become protected by 437 one or more patents assigned to AT&T, AT&T intends to disclose those 438 patents and license them on reasonable and non-discriminatory terms. 439 Future revisions of this draft may contain additional information 440 regarding specific intellectual property protection sought or 441 received. 443 3COM may seek patent or other intellectual property protection for 444 some or all of the technologies disclosed in the document. If any 445 standards arising from this disclosure are or become protected by 446 one or more patents assigned to 3COM, 3COM intends to disclose those 447 patents and license them on reasonable and non-discriminatory terms. 448 Future revisions of this draft may contain additional information 449 regarding specific intellectual property protection sought or 450 received. 452 10 References 454 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 455 9, RFC 2026, October 1996. 457 2. Bradner, S., "Key words for use in RFCs to Indicate Requirement 458 Levels", BCP 14, RFC 2119, March 1997 460 3. Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 461 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 462 Demon Internet Ltd., November 1997 464 4. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,"SIP: 465 session initiation protocol," Request for Comments (Proposed 466 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 468 5. Marshall, W. et. al, "Architectural Considerations for Providing 469 Carrier Class Telephony Services Utilizing SIP-based Distributed 470 Call Control Mechanisms", Internet Draft, Internet Engineering 471 Task Force, draft-dcsgroup-sip-arch-02, June 2000, Work In 472 Progress 474 6. J. Rosenberg and H. Schulzrinne, "The SIP Supported Header", 475 draft-ietf-sip-serverfeatures-02.txt, September 2000. 477 DCS Group Internet Draft - Expiration 01/31/01 9 478 7. Kristol, D. and Montulli, L., "HTTP State Management Mechanism", 479 RFC 2109, February 1997. See current working draft modified by the same authors based on 481 field implementation feedback. 483 11 Acknowledgements 485 The Distributed Call Signaling work in the PacketCable project is 486 the work of a large number of people, representing many different 487 companies. The authors would like to recognize and thank the 488 following for their assistance: John Wheeler, Motorola; David 489 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 490 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 491 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 492 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 493 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 494 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 495 Cable Communications. 497 Many thanks to Jonathan Rosenberg for extensive comments on this 498 draft. 500 12 Author's Addresses 502 Bill Marshall 503 AT&T 504 Florham Park, NJ 07932 505 Email: wtm@research.att.com 507 K. K. Ramakrishnan 508 AT&T 509 Florham Park, NJ 07932 510 Email: kkrama@research.att.com 512 Ed Miller 513 CableLabs 514 Louisville, CO 80027 515 Email: E.Miller@Cablelabs.com 517 Glenn Russell 518 CableLabs 519 Louisville, CO 80027 520 Email: G.Russell@Cablelabs.com 522 Burcak Beser 523 3Com 524 Rolling Meadows, IL 60008 525 Email: Burcak_Beser@3com.com 527 Mike Mannette 529 DCS Group Internet Draft - Expiration 01/31/01 10 530 3Com 531 Rolling Meadows, IL 60008 532 Email: Michael_Mannette@3com.com 534 Kurt Steinbrenner 535 3Com 536 Rolling Meadows, IL 60008 537 Email: Kurt_Steinbrenner@3com.com 539 Dave Oran 540 Cisco 541 Acton, MA 01720 542 Email: oran@cisco.com 544 Flemming Andreasen 545 Cisco 546 Edison, NJ 547 Email: fandreas@cisco.com 549 John Pickens 550 Com21 551 San Jose, CA 552 Email: jpickens@com21.com 554 Poornima Lalwaney 555 Nokia 556 San Diego, CA 92121 557 Email: poornima.lalwaney@nokia.com 559 Jon Fellows 560 Motorola 561 San Diego, CA 92121 562 Email: jfellows@gi.com 564 Doc Evans 565 Secure Cable Solutions 566 Westminster, CO 30120 567 Email: drevans@securecable.com 569 Keith Kelly 570 NetSpeak 571 Boca Raton, FL 33587 572 Email: keith@netspeak.com 574 DCS Group Internet Draft - Expiration 01/31/01 11 575 Full Copyright Statement 577 "Copyright (C) The Internet Society (date). All Rights Reserved. 578 This document and translations of it may be copied and furnished to 579 others, and derivative works that comment on or otherwise explain it 580 or assist in its implementation may be prepared, copied, published 581 and distributed, in whole or in part, without restriction of any 582 kind, provided that the above copyright notice and this paragraph 583 are included on all such copies and derivative works. However, this 584 document itself may not be modified in any way, such as by removing 585 the copyright notice or references to the Internet Society or other 586 Internet organizations, except as needed for the purpose of 587 developing Internet standards in which case the procedures for 588 copyrights defined in the Internet Standards process must be 589 followed, or as required to translate it into languages other than 590 English. The limited permissions granted above are perpetual and 591 will not be revoked by the Internet Society or its successors or 592 assigns. This document and the information contained herein is 593 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 594 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 595 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 596 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 599 Expiration Date: This memo is filed as , and expires January 2001. 602 DCS Group Internet Draft - Expiration 01/31/01 12