[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
SIP Working Group                                           W. Marshall
Internet Draft                                          K. Ramakrishnan
Document: <draft-dcsgroup-sip-state-02.txt>                        AT&T

                                                              E. Miller
                                                             G. Russell
                                                              CableLabs

                                                               B. Beser
                                                            M. Mannette
                                                        K. Steinbrenner
                                                                   3Com

                                                                D. Oran
                                                           F. Andreasen
                                                                  Cisco

                                                             J. Pickens
                                                                  Com21

                                                            P. Lalwaney
                                                                  Nokia

                                                             J. Fellows
                                                               Motorola

                                                               D. Evans
                                                 Secure Cable Solutions

                                                               K. Kelly
                                                               NetSpeak

                                                             July, 2000


          SIP Extensions for supporting Distributed Call State


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026[1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

DCS Group        Internet Draft - Expiration 01/31/01                1

              SIP Extensions for Distributed Call State     July 2000



   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   The distribution of this memo is unlimited.  It is filed as <draft-
   dcsgroup-sip-state-02.txt>, and expires January 31, 2001. Please
   send comments to the authors.



1. Abstract

   This document describes an extension to the Session Initiation
   Protocol (SIP) that enables proxies to distribute call state to user
   agents. The state information can be returned to the proxy when the
   user agent requests a change in the characteristics of the active
   call. By providing the ability to distribute state to the user
   agents where it can be securely stored, proxy servers can remain
   stateless for the duration of the call. This mechanism allows a
   proxy server to provide services that depend on call state, while
   still being stateless.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [2].


3. Introduction

   In the Session Initiation Protocol (SIP) [4] proxies play the role
   of routing engines and delivery platforms for services.  Many types
   of services require these proxies to retain call state.  That is,
   these proxies know how to correlate SIP messages in order to
   reconstruct the state of calls that exist in the user agents.
   Unfortunately, maintaining call state presents problems.  First, it
   introduces scalability problems when there are many user agents
   being served by a single proxy.  Second, it makes failover and load
   balancing more complex, since once state is established in one
   proxy, subsequent signaling must return to the same proxy in order
   for proper service execution.

   To achieve scalability when handling signaling messages from a large
   number of calls, SIP proxies must minimize the per call information
   that they need to maintain. One method of achieving this is for the
   proxy to transfer the state associated with a call to entities where
   the state is relevant. In addition, the proxy should be able to
   retrieve and update the call state information if the
   characteristics of the active call are changed.

   The extension proposed in this document allows proxies to
   encapsulate any state information they desire into a header, called

DCS Group        Internet Draft - Expiration 01/31/01                2

              SIP Extensions for Distributed Call State     July 2000


   a State header, that is delivered to the user agents for a call.
   This information is reflected back in subsequent messages.  This
   effectively allows proxies to store call state in user agents -
   behaving as SIP stateful proxies while still being stateless.

   In this draft, we propose the following extension to SIP to support
   the distribution of call state:

   1) A new general State header field that can be used to distribute
   call state information by the proxy to the UA during call setup or
   mid-call. The state information can also be encrypted, and contain
   an integrity check value, to guarantee detection of tampering by an
   untrusted UA.

   If the UA wishes to change call characteristics, it passes the saved
   state information (which may be proxy encrypted and integrity
   protected) in a SIP INVITE request to its proxy server.  The proxy
   is then able to perform the requested action, just as if the proxy
   had maintained the call state information itself. By using this
   mechanism, the proxies can offer the full range of services, yet
   remain stateless during the call.

   The above mechanism for distributing state information is used in
   the Distributed call signaling (DCS) architecture [5].

   2) A new option tag "state" is defined. This is to be used in the
   Supported header [5] by the initiating UA in its request to inform
   its proxy server that it understands and supports the behavior
   required by the State header. The responses would also include the
   Supported header with the option tag "state". In addition, proxy
   servers that transfer State to the UAS MUST also include a Require
   and a Proxy-Require header field with the option tag "state" if the
   proxy requires support for the extension.

4. Protocol Overview

   Outlined below is an overview of the usage of the State header for
   distributing call state.

   Consider a basic SIP INVITE-200 OK-ACK transaction. The UAC
   initiating the call sends an INVITE request to its proxy with the
   called party information. If the UAC supports the State header, the
   Supported header with the option tag "state" MUST be included in the
   request. The originating proxy locates the SIP proxy associated with
   the called party (referred to here as the terminating proxy) and
   forwards the INVITE to it. After the terminating proxy processes the
   INVITE, it has the information about the call being set up. The
   terminating proxy can pass this state information to the
   terminating/called UA in the State header. The State header includes
   a host value to identify the proxy that inserted the state token(s)
   that follows. In addition, the proxy MAY insert a Require and a
   Proxy-Require header field with the value "state" if it wishes the
   call to only be established if the State extension can be supported.

DCS Group        Internet Draft - Expiration 01/31/01                3

              SIP Extensions for Distributed Call State     July 2000



   If the UAS supports the State extension, the State header along with
   the Supported header with an option tag of "state" is reflected back
   in the response. When the response to the INVITE (200 OK or the
   first non-100 1xx response) arrives at the originating proxy, the
   proxy has the complete call state information about the call being
   setup. When forwarding the response to the calling UA, the proxy
   includes this call state information in the State header.

   The state information distribution described above between the proxy
   and the UA works for a network of proxies in the signaling path as
   well. If a proxy along the path wishes to distribute call state to
   the user agents, it adds a State header to the request (or the
   response).  The State header includes a host value by which the
   proxy can identify itself followed by its state token(s) and any
   State header(s) inserted by other proxies.

   The UAS that receives the State header(s) stores the headers and
   associates them with the call-leg.

   The rules for when and how the stored state information is returned
   by the UA to the proxy are discussed in detail in the next section.

5. SIP Header Extension and Option Tag for Distributing Call State

   If the State header is to be used to distribute state in a call, the
   UAC initiating the call MUST include the Supported header defined in
   [6] with the option tag "state" in the initial INVITE request.

   UAS's receiving the Supported header with the value "state" MUST
   include the Supported header with an option tag of "state" in
   responses if they are capable of processing the State header
   extension.

   A proxy in the signaling path MUST insert a Require and a Proxy-
   Require header with an option tag of "state" if it inserts a State
   header in the request or response.

5.1 State Header Syntax

   The State header contains any information a proxy would like
   returned to it in subsequent messaging from the UA's for the same
   call leg. This might include information for support of mid-call
   features, billing information, etc. It is RECOMMENDED that this
   information be protected by an integrity check mechanism. This
   allows the proxy to reliably and securely store state information in
   the client that may be needed for subsequent feature invocation.

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [3].




DCS Group        Internet Draft - Expiration 01/31/01                4

              SIP Extensions for Distributed Call State     July 2000


        State           = "State" ":" 1#(host ";" state-token
                                *(";" state-token))
        state-token     =  token ["=" (*token | quoted-string)]

   The host field identifies the proxy that inserted the state
   information.

   State headers may be nested. In this case, a proxy in the signaling
   path takes the State header(s) it received in the incoming signaling
   message (previous host; token form), possibly adds any state-tokens
   of its own, and generates a single new State header.  The hostname
   in the nested State header identifies the proxy that performed the
   nesting.

   Multiple State headers MAY be present in a request (or response). In
   addition, the syntax allows for a proxy to insert multiple tokens in
   the header.

   The state token is a proxy-defined encoding of a structure
   containing multiple pieces of information needed by the proxy to
   perform various call features.  The structure is returned from the
   UA to its proxy for call services that affect the current call.

   The following defines the entry for the State header of Table 5 in
   RFC 2543.

                Where   enc     e-e     ACK BYE CAN INV OPT REG

   State         gc      n       h       o   o   o   o   o   o


6  Detailed Protocol Semantics

   The protocol semantics for a UAC, a UAS and the proxy are addressed
   in this section.

6.1 UAC behavior

   The rules at the UAC for processing State headers are listed below:

   1.      A UAC supporting this extension MUST include a Supported header
     field with an option tag of "state" in the initial INVITE and all
     subsequent requests and responses.

  2.      The UAC MUST save the received State header(s) along with the
     From, To, Call-ID and tags associated with the To and From header
     fields for the duration of the call.

  3.      On a subsequent request, the UAC includes the State header(s) in
     the request if the From, To (including ones with From and To
     reversed), Call-ID and the tags on the From and To match those
     associated with the saved State header(s) and Request-URI matches
     the hostname of the saved State header(s). If Route header is


DCS Group        Internet Draft - Expiration 01/31/01                5

              SIP Extensions for Distributed Call State     July 2000


     present, the UAC also includes State headers that have hostname
     matching a component of the Route header.

  4.      Additional rules MAY be defined by other extensions that specify
     when a State header is to be included in a request. An example of
     this would be extensions that handle call transfers and other
     features that would specify State header processing at the UAC.

   5.      When a call leg ends, the UAC MAY delete all saved State headers
     associated with the call leg.

6.2 UAS behavior

    The rules at the UAS for processing State headers are listed below:

   1.      A UAS that supports this extension MUST include a Supported header
     with the token value "state" in all responses.

   2.      The UAS MUST save the received State header(s) along with the
     From, To, Call-ID and tags associated with the To and From header
     fields for the duration of the call, or until a new request with
     the State is received.

   3.      In all non-100 responses to all requests, the UAS MUST include the
     State header(s) received in that request, and a Supported: "state"
     header.


6.3 Proxy Behavior

   To support this extension, the Proxy MUST perform the following
   functions:

   1. A State header that is received in a request or response, with a
      hostname other than the proxy's, MUST be passed on.

   2. A Proxy that hides Via headers in a request MUST nest all the
      State headers received in the request.  Further, the proxy MUST
      restore these State headers when that nested State header is
      received in a request or response.

   3. A proxy that hides Record-Route headers in a request MUST nest
      all the State headers received in that request.  Further, the
      proxy MUST restore these State headers when that nested State
      header is received in a request or response.

   4. Requirements on a proxy that hides Record-Route headers in a
      response, or that hides Route headers, is for further study.

   In addition, a proxy MAY do the following to utilize the capability
   offered by this extension:



DCS Group        Internet Draft - Expiration 01/31/01                6

              SIP Extensions for Distributed Call State     July 2000


  1.      A State header received in a request or response with the hostname
     matching the proxy MAY be discarded.

  2.      A proxy MAY generate one or more State headers, and include it (or
     them) in any request or response. A proxy that generates State
     headers MUST insert a "Require: state" header, and a "Proxy-
     Require: state" header, in the request if not already present.

  3.      A proxy MAY nest all, or any subset, of the State headers received
     in a request or response.  A proxy that nests State headers MUST
     restore these State headers when that nested State header is
     received in a request or response.


6.4 Example of use

   The following example illustrates the distribution of state during
   call setup and issues associated with concatenation and encryption
   of State headers. UAC and UAS refer to the originating and
   terminating User Agent for the call. P1 is the proxy associated with
   UAC and P2 is the proxy associated with UAS. eP1{*} refers to the
   state token encrypted by P1.

   UAC -> P1 -> P2 -> UAS

        UAC->P1:        invite
                        Supported: state

        P1->P2:         invite
                        State:P1;state=eP1{"cached translation
                                        of UAS's number"}
                        Supported: state
                        Require: state

   In this example, P2 formulates a single State header by combining
   the State header received from the previous proxy(ies).

        P2->UAS:        invite
                        State:P2;state=eP2{"hunt group ID,
                                billing ID,P1;state=eP1{"cached
                                translation of UAS's number"}"}
                        Supported: state
                        Require: state

   UAS saves the above state information received from its proxy P2 for
   the duration of the call.

        UAS->P2:        response
                        State:P2; state=eP2{"hunt group ID,
                                billing ID,P1;state=eP1{"cached
                                translation of UAS's number"}"}
                        Supported: state


DCS Group        Internet Draft - Expiration 01/31/01                7

              SIP Extensions for Distributed Call State     July 2000


   As P2 combined all State headers into one when sending the INVITE to
   the UAS, it is responsible for restoring the State headers as
   received in the INVITE before forwarding the response to P1 with its
   updated State header.

        P2->P1:         response
                        State:P2;state=eP2{"hunt group ID,
                                billing ID"},P1;state=eP1{"cached
                                translation of UAS's number"}
                        Supported: state

        P1->UAC:        response
                        state:P1;state=eP1{"billing ID,
                                cached translation of  UAS's
                        number, P2;state=eP2{"hunt group ID,
                                        billing ID"}"}
                        Supported: state

   UAC saves the state information received from P1 for the duration of
   the call.

   When the call begins, state at UAC is:
        State:P1;state=eP1{"billing ID, cached translation of UAS's
        number", P2;state=eP2{"hunt group ID, billing ID"}"}

   State at UAS is:
        State:P2;state=eP2{"hunt group ID, billing ID,P1;state=eP1{"
        cached translation of UAS's number"}"}

   Note that the state information for the call at the UAC and UAS is
   different. Proxies therefore need to be aware of the direction from
   which they receive the State header. This may be information
   included in the state token or may be deduced from other headers in
   the message.

7  State Header and HTTP Cookie/Pcookie Comparison

   The State header field discussed in this section differs from the
   HTTP1.1 Cookies as described in [7]. In a general sense, both
   transfer state between the server and the client. HTTP uses the
   Cookie for "state" management, or as a handle to pass session
   context change from server to client where the server is the other
   endpoint of the session. Cookies typically persist across sessions.
   On the other hand, the State header is used to transfer current call
   state from a proxy or intermediate network proxies to the UAC and
   the UAS. The state header can be considered to be a handle to
   request a change in the active/current session by the endpoint from
   its proxy. In addition, there are no attribute value pairs
   associated with the State header as there are in the Cookie
   mechanism.

8  Security Considerations


DCS Group        Internet Draft - Expiration 01/31/01                8

              SIP Extensions for Distributed Call State     July 2000


   If the clients/endpoints are considered untrusted entities, the
   proxy must encrypt the State header and include an integrity check
   with the State header information. In addition, the proxy is
   responsible for verifying the contents and integrity of the State
   header returned by the client as discussed in this document.


9  Notice Regarding Intellectual Property Rights

   AT&T may seek patent or other intellectual property protection for
   some or all of the technologies disclosed in the document. If any
   standards arising from this disclosure are or become protected by
   one or more patents assigned to AT&T, AT&T intends to disclose those
   patents and license them on reasonable and non-discriminatory terms.
   Future revisions of this draft may contain additional information
   regarding specific intellectual property protection sought or
   received.

   3COM may seek patent or other intellectual property protection for
   some or all of the technologies disclosed in the document. If any
   standards arising from this disclosure are or become protected by
   one or more patents assigned to 3COM, 3COM intends to disclose those
   patents and license them on reasonable and non-discriminatory terms.
   Future revisions of this draft may contain additional information
   regarding specific intellectual property protection sought or
   received.

10 References

   1.      Bradner, S., "The Internet Standards Process -- Revision 3", BCP
     9, RFC 2026, October 1996.

   2.      Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, March 1997

   3.      Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
     Specifications: ABNF", RFC 2234, Internet Mail Consortium and
     Demon Internet Ltd., November 1997

   4.      M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,"SIP:
     session initiation protocol," Request for Comments (Proposed
     Standard) 2543, Internet Engineering Task Force, Mar. 1999.

   5.      Marshall, W. et. al, "Architectural Considerations for Providing
     Carrier Class Telephony Services Utilizing SIP-based Distributed
     Call Control Mechanisms", Internet Draft, Internet Engineering
     Task Force, draft-dcsgroup-sip-arch-02, June 2000, Work In
     Progress

   6.      J. Rosenberg and H. Schulzrinne, "The SIP Supported Header",
     draft-ietf-sip-serverfeatures-02.txt, September 2000.



DCS Group        Internet Draft - Expiration 01/31/01                9

              SIP Extensions for Distributed Call State     July 2000



   7.      Kristol, D. and Montulli, L., "HTTP State Management Mechanism",
     RFC 2109, February 1997. See current working draft <draft-ietf-
     http-state-man-mec-12.txt> modified by the same authors based on
     field implementation feedback.


11 Acknowledgements

   The Distributed Call Signaling work in the PacketCable project is
   the work of a large number of people, representing many different
   companies.  The authors would like to recognize and thank the
   following for their assistance: John Wheeler, Motorola; David
   Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows,
   Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin,
   Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks;
   Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho,
   Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-
   Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent
   Cable Communications.

   Many thanks to Jonathan Rosenberg for extensive comments on this
   draft.


12 Author's Addresses

   Bill Marshall
   AT&T
   Florham Park, NJ  07932
   Email: wtm@research.att.com

   K. K. Ramakrishnan
   AT&T
   Florham Park, NJ  07932
   Email: kkrama@research.att.com

   Ed Miller
   CableLabs
   Louisville, CO  80027
   Email: E.Miller@Cablelabs.com

   Glenn Russell
   CableLabs
   Louisville, CO  80027
   Email: G.Russell@Cablelabs.com

   Burcak Beser
   3Com
   Rolling Meadows, IL  60008
   Email: Burcak_Beser@3com.com

   Mike Mannette

DCS Group        Internet Draft - Expiration 01/31/01               10

              SIP Extensions for Distributed Call State     July 2000


   3Com
   Rolling Meadows, IL  60008
   Email: Michael_Mannette@3com.com

   Kurt Steinbrenner
   3Com
   Rolling Meadows, IL  60008
   Email: Kurt_Steinbrenner@3com.com

   Dave Oran
   Cisco
   Acton, MA  01720
   Email: oran@cisco.com

   Flemming Andreasen
   Cisco
   Edison, NJ
   Email: fandreas@cisco.com

   John Pickens
   Com21
   San Jose, CA
   Email: jpickens@com21.com

   Poornima Lalwaney
   Nokia
   San Diego, CA  92121
   Email: poornima.lalwaney@nokia.com

   Jon Fellows
   Motorola
   San Diego, CA  92121
   Email: jfellows@gi.com

   Doc Evans
   Secure Cable Solutions
   Westminster, CO  30120
   Email: drevans@securecable.com

   Keith Kelly
   NetSpeak
   Boca Raton, FL  33587
   Email: keith@netspeak.com











DCS Group        Internet Draft - Expiration 01/31/01               11

              SIP Extensions for Distributed Call State     July 2000



Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.  The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its successors or
   assigns.  This document and the information contained herein is
   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

   Expiration Date:  This memo is filed as <draft-dcsgroup-sip-state-
   02.txt>, and expires January 2001.




























DCS Group        Internet Draft - Expiration 01/31/01               12