[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01

Sipping                                                   Haseeb Akhtar
Internet-Draft                                             Dave Brombal
Expires: March 9, 2007                                    Anthony Jones
                                                                 Nortel
                                                     September 10, 2006


              New SIP Headers for Reducing SIP Message Size
              draft-akhtar-sipping-header-reduction-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

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

   This Internet-Draft will expire on August 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Current SIP messages are text based and inherently large, especially
   when these messages are to be transmitted over the bandwidth-strained
   wireless access technologies (a typical orginiating SIP Invite is
   about 1200 bytes).

   For most wireless technologies, transmitting the session initiation
   messages (such as SIP Invite) over the signaling channel can reduce
   the call setup time substantially. The size limitation of these
   wireless signaling channels are typically very small (~210 bytes in
   the uplink and ~110 bytes in the downlink).


Akhtar, et al.          Expires March 9, 2007                [Page 1]


Internet-Draft          SIP Header Reduction           September 2006

   To address this problem, a new function called Encoding Assitant
   (EA) has been introduced in the User Agent (UA) and in the
   SIP Proxy server within the network. Additionally, the method
   provided in this document defines new SIP option tags and headers.
   These new option tags and headers allow the UA and a SIP Proxy
   server within the network (such as the P-CSCF), to exchange
   information using the signaling channels supported by most wireless
   access networks.














































Akhtar, et al.          Expires March 9, 2007                [Page 2]


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1 SIP Registration . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Option Tags and Headers  . . . . . . . . . . . . . . . . . . .  8
     4.1 Option Tag 'encode' for 'Supported' header field . . . . . .  8
     4.2 Option Tag '3G-Dictionary' for 'Supported' header field  . .  8
     4.3 P-Encode-Identities. . . . . . . . . . . . . . . . . . . . .  9
     4.4 P-Encode-Access-Networks . . . . . . . . . . . . . . . . . . 10
     4.5 P-Encode-Security  . . . . . . . . . . . . . . . . . . . . . 11
     4.6 P-Contact-List . . . . . . . . . . . . . . . . . . . . . . . 11
     4.7 P-Contact-List-Location  . . . . . . . . . . . . . . . . . . 12
   5.  EA Details . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1 Encoding Considerations  . . . . . . . . . . . . . . . . . . 12
     5.2 Decoding Considerations  . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 18


































Akhtar, et al.          Expires March 9, 2007                [Page 3]


Internet-Draft          SIP Header Reduction           September 2006


1.  Introduction

   One of the Key Performance Indicators (KPI) of the Delay Sensitive
   (DS) applications such as Voice over IP (VoIP), Push To Talk (PTT),
   Video Telephony (VT) is the call set time. Current SIP messages
   used for this purpose are text based and inherently large, especially
   when these messages are to be transmitted over the bandwidth-strained
   wireless access technologies (a typical orginiating SIP Invite is
   about 1200 bytes).

   Additionally, for most wireless technologies, transmitting the DS
   session initiation messages (such as SIP Invite) over the signaling
   channel can reduce the call setup time substantially. The size
   limitation of these wireless signaling channels are typically very
   small (~210 bytes in the uplink and ~110 bytes in the downlink).

   To address this problem, a new function called Encoding Assitant
   (EA) has been introduced in the User Agent (UA) and in the
   SIP Proxy server within the network. Additionally, the method
   provided in this document defines new SIP option tags and headers.
   These new option tags and headers allow the UA and a SIP Proxy
   server within the network (such as the P-CSCF), to exchange
   information using the signaling channels supported by most
   wireless access networks.

   The proposed EA function along with the new SIP option tags
   and/or SIP headers as detailed in this document will help in
   reducing the call setup time for the DS applications.


2.  Terminology

   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.  Overview

   A new function called Encoding Assistant (EA) has been introduced
   in the UA and in the SIP Proxy server. The EA function is used to
   set the context between the mobile and the SIP Proxy server during
   SIP Registration using the new Option Tags and/or Headers
   mentioned in this document.

   The EA function within both UA and the SIP Proxy server may use
   these new option tags and/or headers during the subsequent SIP
   message exchanges, as and when possible.





Akhtar, et al.          Expires March 9, 2007                [Page 4]


Internet-Draft          SIP Header Reduction           September 2006


   The following figure shows the high level view of the functional
   components of the mobile and the SIP Server.


    ++++++++++++++                       ++++++++++++++
    + SIP        +                       + SIP        +
    ++++++++++++++                       ++++++++++++++
    + EA         +                           + EA         +
    ++++++++++++++                       ++++++++++++++
    + SIGComp    +                           + SIGComp    +
    ++++++++++++++                       ++++++++++++++
    + TCP/UDP    +                       + TCP/UDP    +
    ++++++++++++++                       ++++++++++++++
    + IP         +                       + IP         +
    ++++++++++++++                       ++++++++++++++
    + Layer 2    +                       + Layer 2    +
    ++++++++++++++                       ++++++++++++++
    + Physical   +   <--------------->   + Physical   +
    ++++++++++++++ (Any Wireless Access) ++++++++++++++

         UA                                SIP Server

    Figure 1: Functional Components of UA and SIP Server






























Akhtar, et al.          Expires March 9, 2007                [Page 5]


Internet-Draft          SIP Header Reduction           September 2006

3.1 SIP Registration

   The following figure shows the interactions between
   the UA and the SIP Proxy server during the SIP Registration
   in order to establish the EA context.


         UA                                SIP Server
          |--------(1) SIP Register------------>|
          |                                     |
          |                        (2) SIP Server checks if
          |                            the UA supports the
          |                            EA function. If
          |                            supported, continue
          |                            with the next step.
          |                            Otherwise, go to
          |                            step (5) below.
          |                                     |
          |                                     |
          |                        (3) EA function within the
          |                            SIP Server gathers
          |                            information such as
          |                            public IDs, supported
          |                            security protocols,
          |                            contact list etc.
          |                                     |
          |                                     |
          |                        (4) SIP Server creates
          |                            indexed list for
          |                            public IDs, supported
          |                            security protocols,
          |                            supported access
          |                            networks etc.
          |                                     |
          |                                     |
          |<--------(5) SIP 200 OK--------------|
          |                                     |
          |                                     |
   (6) UA checks if the                         |
       SIP Proxy server supports                |
       the EA function. If                      |
       supported, UA may                        |
       send subsequent SIP                      |
       messages using new 'P'                   |
       headers. Otherwise,                      |
       UA continues with existing               |
       SIP operations.                          |
          |                                     |
          |                                     |

    Figure 2: SIP Registration for EA Context Setup



Akhtar, et al.          Expires March 9, 2007                [Page 6]


Internet-Draft          SIP Header Reduction           September 2006

The following is the summary of the SIP Registration as shown in
Figure 2 above.

 (1) The UA sends a SIP Registration message as described in [2] and
     [3]. The UA shall add the following SIP headers to the SIP
     Register.
      - Supported: encode (a new option tag specified in section 4)
      - Allow
      - Privacy
      - Contact-List-Location

 The Allow and Privacy header values shall be set to the default
 values that would be used in subsequent SIP messages (Invite,
 etc.).

 (2) SIP Proxy server checks if the UA supports the EA function. If the
     UA does support the EA function, the SIP Proxy server shall store
     the content of the following header fields.
       - Supported
       - Via
       - Privacy
       - Allow
       - Contact
       - P-Access-Network-Info
       - Security-Verify

     In the case where UA does not support the EA function, the
     SIP Proxy server transitions to step (5).

 (3) The EA function within the SIP Proxy server retrieves and stores
     the following information related to this specific user.
     This information may be retrieved from another SIP server (Proxy,
     Serving or others) or from a database within the network.
       - Public IDs
       - Supported Security Protocols
       - Supported Access Networks
       - Contact List
       - Service Route

 (4) The EA function within the SIP Proxy server creates indexed lists
     using the following new headers (as defined in section 4)
     based on the information retrieved in step (3).
       - P-Encode-Identities
       - P-Encode-Access-Networks
       - P-Encode-Security

     The SIP Proxy server indicates that it supports the EA function
     by including the 'Supported:encode' header in the SIP 200
     OK as defined in section 4.





Akhtar, et al.          Expires March 9, 2007                [Page 7]


Internet-Draft          SIP Header Reduction           September 2006

     The SIP Proxy server may indicate that it supports the 3G
     dictionary (as specified by [4]) by including the
     'Supported:3g-dictionary' header in the SIP 200 OK as
     defined in section 4.

  (5) SIP Proxy server sends a SIP 200 OK to the UA. If the UA supports
      the EA function (as determined in step (1) above), the
      following headers and option tags (as specified in section
      4) are included in the SIP 200 OK message.
       - Supported: encode, 3g-dictionary
       - P-Encode-Identities
       - P-Encode-Access-Networks
       - P-Encode-Security

      Otherwise (i.e., if the UA does not support the EA function),
      the SIP Server sends the SIP 200 OK to the UA as specified
      in [2] and [3].

  (6) Upon receiving the SIP 200 OK, the UA checks if the SIP Proxy
      server supports EA function. If the EA function is supported
      by the SIP Proxy server, the UA sets the proper context based on
      the new 'P' headers (as specified in section 4.0) received in
      the SIP 200 OK. If, however, the SIP Proxy server does not
      support the EA function (i.e., by excluding the 'encode' option
      tag in the'Supported' header), the UA continues to process the
      SIP 200 OK as specified in [2] and [3].

4.  Option Tags and Headers

   The following new option tags and/or headers are needed to
   support the EA function within the UA and the SIP Proxy server.

4.1 Option Tag 'encode' for 'Supported' header field

   An option tag is introduced to indicate if the UA and/or the SIP
   server supports the EA based SIP header reduction. This shall be
   done by including 'Supported:encode' in the SIP message.

   If indicated in the SIP message, the EA function within the
   UA and the SIP Proxy server shall support the encoding scheme as
   specified by this document.


4.2 Option Tag '3G-Dictionary' for 'Supported' header field

   An option tag is intorduced to indicate if the UA and/or
   SIP Proxy server supports a 3G enhanced SIP/SDP dictionary as
   specified in [4]. This is done by including
   'Supported:3g-dictionary' in the SIP message.





Akhtar, et al.          Expires March 9, 2007                [Page 8]


Internet-Draft          SIP Header Reduction           September 2006


   If indicated in the SIP message, the UA and the EA function
   within the SIP Proxy server shall support a 3G enhanced dictionary.

4.3 P-Encode-Identities

   There are 6 SIP/SDP header fields that use various forms of identity
   information to describe the local user. The UA and the SIP Proxy
   server shall establish an indexed list of these values and shall
   exchange this index when identifying one of the entries. The list
   may have up to 16 entries. The following are the SIP/SDP header
   fields that utilize identity information:

    -   Via identity: This identity shall be derived from the contents
    of the ‘Via’ header. The ‘Via’ header is included in the initial
    Register message. The IP address and port number or URI
    included in the ‘Via’ header is saved as index entry # 0 in the
    Identity list.

    - From identity: This identity shall be derived from the contents
    of the ‘From’ header. The ‘From’ header is included in the
    initial Register message. The IP address and the port number or URI
    included in the ‘From’ header shall be entered as index entry # 1
    in the Identity list.

    - Contact identity: This identity shall be derived from the contents
    of the 'Contact' header. The 'Contact' header is included in the
    initial Register message. The IP address and the port number or URI
    included in the ‘From’ header shall be entered as index entry # 2
    in the Identity list.

    - P-Preferred-Identity: The UA may select the
    ‘P-Preferred-Identity’ from a number of possible public identities.
    For example, as specified in [2] and [3], the SIP Proxy server
    (P-CSCF in this case) is provided a list of the  acceptable
    ‘P-Preferred-Identity’ values in the P-Associated-URI header from
    another SIP Serving server (S-CSCF, in this case).

   In order to ensure synchronized use of index values for these
   identities, this list must be forwarded to the UA keeping the same
   order. If a UA registers several public identities, the EA
   function within the SIP Proxy server must aggregate and rationalize
   (i.e. cull duplicates from) before forwarding the aggregate list to
   the UA.

   A maximum of 13 P-Preferred-Identity’s entries are allowed in
   order to accommodate the ‘Via’, ‘From’ and ‘Contact’ identities
   described previously.






Akhtar, et al.          Expires March 9, 2007                [Page 9]


Internet-Draft          SIP Header Reduction           September 2006

    -   SDP "o=" line: The content for this line will generally be
    created by information available at the SIP Proxy server. As a
    result, no additional values need to be exchanged for this SDP
    field.

    -   SDP "c=" line: The content for this line will generally be
    created by information available at the SIP Proxy server. As a
    result, no additional values need to be exchanged for this SDP
    field.

   The list of identities shall be transferred to the UA using a new
   header attached to the 200OK (or similar) response to the initial
   Register request. The format of the header shall be as shown below,
   containing up to 16 total entries, with the order implying the index
   value to use, beginning with 0.

    Format:     P-Encode-Identities: <address:port | user.domain>
      *15[, <address:port|user.domain>]
    Source:     SIP Proxy server
    Destination: UA

4.4 P-Encode-Access-Networks

   Only a limited set of access network types are expected for the UA.
   A small set of values (up to 8) is defined in advance and provisioned
   in the SIP Proxy server. The following strings are suggested for the
   initial set of network types <net-type>:

    - IEEE-802.11a
    - IEEE-802.11b
    - 3GPP-UTRAN-FDD; utran-cell-id-3gpp=
    - 3GPP-UTRAN-TDD; utran-cell-id-3gpp=
    - 3GPP-CDMA2000; evdo-cell-id-3gpp2=
    - 3GPP-CDMA2000; 1x-cell-id-3gpp2=

   The list of network types shall be transferred to the UA using this
   new header attached to the 200 OK (or similar) response to the
   initial Register request (as shown in step (5) of Figure 2).

   The format of the header shall be as shown below, containing up to 8
   total entries, with the order implying the index value to use,
   beginning with 0.

    Format:     P-Encode-Access-Networks: <net-type> *7[, <net-type>]
    Source:     SIP Proxy server
    Destination: UA








Akhtar, et al.          Expires March 9, 2007               [Page 10]


Internet-Draft          SIP Header Reduction           September 2006


4.5 P-Encode-Security

   Only a limited set of security types are expected for the UA. A
   small set of values (up to 16) is defined in advance and
   provisioned in the SIP Proxy server. The following strings are
   suggested for the initial set of security types <sec-type>:

    - ipsec-3gpp
    - HMAC-MD5-96
    - HMAC-SHA-1-96

  The list of security types shall be transferred to the UA using
  this new header attached to the 200 OK (or similar) response to
  the initial Register request (as shown in step (5) of Figure 2).

  The format of the header shall be as shown below, containing
  up to 16 total entries, with the order implying the index
  value to use, beginning with 0.

   Format: P-Encode-Security: <sec-type> *15[, <sec-type>]
   Source: SIP Proxy server
   Destination: UA

4.6 P-Contact-List

  The addresses used to direct the initial Invite (or similar)
  message will, in most cases, be drawn from a local
  phone-book/address-book. These are referred to as a Contact
  List. This list is expected to be too large to exchange
  over the air under normal operation (e.g. when placing a call).

  It is expected that this will be maintained and kept in
  sync by the user periodically as a 'maintenance' activity
  done every few days or weeks through some form of service
  offered by the Service Provider, and is outside the scope
  of this document, but it is assumed that this synchronization has
  occurred, and that use of a 10 bit index value by the user will
  be able to be mapped to the desired destination by the network.

  The Contact List shall be stored at the shared XDMS (or
  related location), and shall be transferred from there to the
  SIP Proxy server during SIP registration.

  Within the SIP network, the list shall be transferred between
  the SIP servers using this SIP header attached to the 200 OK
  (or similar) response to the initial Register request.

  The format of the header shall be as shown below, containing
  up to 1024 total entries, with the order implying the index
  value to use, beginning with 0.



Akhtar, et al.          Expires March 9, 2007               [Page 11]


Internet-Draft          SIP Header Reduction           September 2006


   Format: P-Contact-List: <address/URI> *1023[, <address/URI>]
    Source:     SIP Proxy server/SIP Serving server/Other SIP server
    Destination: SIP Serving server/SIP Proxy server/Other SIP
                 server

4.7 P-Contact-List-Location

  The contact list of an user is located in a database within
  the service provider's network (such as a Shared XDMS). The
  SIP Proxy server may not be aware of the identity of this
  database. This header shall contain the address (such as URI)
  of the database that stores the contact list of that specific
  user.

  The format of the header shall be as shown below, containing
  an address of the contact list database.

   Format: P-Contact-List-Location: <address/URI>
            *1[, <address/URI>]
    Source:     UA
    Destination: SIP Proxy server


5. EA Details

  The EA function required to support the SIP Header Reduction
  Proposal is divided into two components - an encoding component
  and a decoding component. The following sections provide a
  detail description of these components of the EA function.

5.1 Encoding Considerations

  The following encoding considerations shall be supported
  as part of the EA function within the UA and the SIP Proxy server.

  - The EA shall encode the callee’s URI (or E.164 address) in the
    SIP Request line based on the 10-bit index associated with a
    specific Contact List entry when a match is found.

  - The EA shall delete the protocol description component (i.e.,
    ‘SIP/2.0/UDP’) if present in any SIP message.

  - The EA shall encode the identity component (IP address, URI
    etc.) of the following header fields based on the four-bit
    index values exchanged during the SIP Registration.
      - Via
      - From
      - Contact
  - The EA shall delete the "comp=sigcomp" and "branch=z9hG4bK"
    components of the ‘Via’ header.  If the "comp=sigcomp" is
    not present, EA shall leave the "branch" component in place.


Akhtar, et al.          Expires March 9, 2007               [Page 12]


Internet-Draft          SIP Header Reduction           September 2006

  - The EA shall change the following components of the ‘Contact’
    header as specified below.
      - The EA shall encode the identity component (IP address,
        URI etc.) based on the four-bit index values exchanged
        during the SIP Registration (as specified in sections
        3.1 and 4).
      - The EA shall indicate the presence of the "comp=sigcomp"
        component by adding one bit as follows.
            0 = "comp=sigcomp" present
            1 = "comp=sigcomp" absent

  - The EA shall delete the "tag=" component of the ‘From’ header
    (and leave the tag’s value).

  - The EA shall delete the ‘To’ header from all SIP Invite
    messages if the callee’s URI can be encoded as 10-bit index
    from the Buddy List.

  - The EA shall encode the ‘P-Preferred-Identity’ header using
    the respective index value as established during the SIP
    Registration. Please refer to sections 3.1 and 4 for more
    details.

  - The EA shall encode the access network type in any
    ‘P-Access-Network-Info’ header as specified in section 4.

  - The EA shall change the following components of any
    ‘Security-Verify’ header:
      - The EA shall delete the text before the "alg"
        component (such as "ipsec-3gpp" and "q=0.1").
      - The EA shall replace the "alg" component with the
        four-bit index number of the security algorithm as
        specified in section 4.
      - The EA shall convert the values of "spi-c" and
        "spi-s" components into 32-bit integer numbers.

  - The EA shall delete the ‘Allow’ header if it matches the
    value established in step (1) of section 3.1. This shall
    only be done in the uplink direction (from the UA to the
    SIP Proxy server).

  - The EA shall delete the ‘Privacy’ header if it matches
    the value established in step (1) of section 3.1.

  - The EA shall delete the SIP message name (such as INVITE)
    from the ‘CSeq’ header if the value is the same as the
    message’s Request type.







Akhtar, et al.          Expires March 9, 2007               [Page 13]


Internet-Draft          SIP Header Reduction           September 2006

  - The EA shall delete the following SDP parameters if
    present in any SIP message. This shall only be done in
    the uplink direction (from the UA to the SIP Proxy server).
      - "o=" line
      - "s=" line
      - "c=" line (if "c=" line is at the session level)
      - "t=" line

  - The EA shall delete the "b=" line if present in any SIP
    message. This shall only be done in the Uplink direction
    (from the UA to the SIP Proxy server).

  - The EA shall delete the "a=curr: local none" line if the
    ‘precondition’ value is included in the ‘Require’ header.
    This shall only be done in the uplink direction (from the
    UA to the SIP Proxy server).

  - The EA shall delete the "a=curr: remote none" line if the
    ‘precondition’ value is included in the ‘Require’ header. This
    shall only be done in the uplink direction (from the UA to the
    RAN).

  - The EA shall delete the "a=fmtp" line if present in any SIP
    message. This shall only be done in the uplink direction (from
    the UA to the SIP Proxy server).

  - The EA shall delete the "a=rtpmap: nn telephone event" (where
    "nn" is any two-digit number) line if present in any SIP
     message. This shall only be done in the uplink direction (from
     the UA to the SIP Proxy server).

5.2 Decoding Functions

  The following decoding considerations shall be supported
  as part of the EA function within the UA and the SIP Proxy server.

  - The EA shall decode the callee’s URI (or E.164 address) based on
    the 10-bit index associated with that specific buddy list entry.

  - The EA shall decode the identity component (IP address, URI etc.)
    of the following header fields based on the four-bit index values
    exchanged during the SIP Registration (as specified sections 3.1
    and 4).
      - Via
      - From
      - Contact

  - The EA shall add the "tag=" component to the ‘From’ header
    field to all SIP messages if it is not included. The "tag="
    component shall be added before the value of "tag".




Akhtar, et al.          Expires March 9, 2007               [Page 14]


Internet-Draft          SIP Header Reduction           September 2006

  - The EA shall decode any ‘P-Preferred-Identity’ header with the
    respective index value as negotiated during the SIP Registration.
    Please refer to section 3.1 for more details.

  - The EA shall change the following components of the ‘Contact’
    header as specified below.
     - The EA shall decode the identity component (IP address, URI
       etc.) based on the four-bit index values exchanged during
       the SIP Registration (as specified sections 3.1 and 4).
     - The EA shall add the "comp=sigcomp" component by evaluating
       the last bit (before CRLF) of the ‘Contact’ header as follows.
         0 = Add "comp=sigcomp"
         1 = Do not add "comp=sigcomp"

  - The EA shall decode the access network type in any
    ‘P-Access-Network-Info’ header as specified in sections 3.1 and 4.

  - The EA shall create the ‘To’ header from all SIP messages if it is
    not included and if the callee’s URI is encoded as 10-bit index in
    that particular SIP message.

  - The EA shall change the following components of the
    ‘Security-Verify’ header field as specified below.
     - The EA shall add the text before the "alg" component based on the
       configuration parameter.
     - The EA shall decode the "alg" component’s four-bit index number
       with the appropriate security algorithm using the look-up table
       created in step (4) of section 3.1.
     - The EA shall convert 32-bit integer values of the "spi-c" and
       "spi-s" components into ASCII characters.

  - If absent, the EA shall add the SIP message name (such as INVITE,)
    to the ‘CSeq’ header after the ‘CSeq’ number based on the first line
    of that particular SIP message.

  - The EA shall create the following SDP parameters if they are missing
    from a SIP message and if the same SIP message has the
    "application/sdp" value present in a ‘Content-Type’ header.
     - The EA shall create the "o=" line based on the following guidelines.
        i.   The EA shall use "-" value for the <<username>> component
             of the "o=" line.
        ii.  The EA shall choose unique values (across time) for the
             <<session id>> and <version>> components of the "o=" line.
        iii. The choice of IP4 or IP6 shall be based on address format
             discerned in the ‘Via’ header.  If a FQDN is used instead
             of IP format, the EA. shall peek at the IP layer header
             to discern the version of the IP address.

  - The EA shall create the "s=" line as "s=-".




Akhtar, et al.          Expires March 9, 2007               [Page 15]


Internet-Draft          SIP Header Reduction           September 2006


  - The EA shall create the "c=" line (at the session level). Its choice
    of IP4 or IP6 will be based on address format discerned in the
    ‘Via’ header. If a FQDN is used instead of IP format, the EA. shall
    peek at the IP layer header to discern the version of the IP
    address.

  - The EA shall create the "t=" line as "t=0 0".

  - The EA shall create the "b=" line based on the configuration
    parameters associated with the media type (such as audio, video
    etc.) present in the "m=" line.

  - The EA shall create the "a=curr: local none" line if it is missing
    from a SIP message and if the same SIP message has the
    ‘precondition’ value present in the ‘Require’ header.

  - The EA shall create the "a=curr: remote none" line if it is missing
    from a SIP message and if the same SIP message has the
    ‘precondition’ value present in the ‘Require’ header.

  - The EA shall create the "a=fmtp: nn <<format specific parameters>>"
    line base on the configuration parameter associated with codec type
    specified in the "m=" and "a=rtpmap" lines. The value of "nn" shall
    be the first two digits of the codec code component of the "m="
    line.

  - The EA shall create the "a=rtpmap: nn telephone event" (where "nn"
    is any two-digit number) line if it is missing in any SIP message
    and if the same SIP message includes the "m=" line. The value of
    "nn" shall be the last two digits of the codec code component of
    the "m=" line.

  - The EA shall add the "comp=sigcomp" and "branch=z9hG4bK" components
    of the ‘Via’ header field to all SIP messages if the
    "branch=z9hG4bK" component is missing.

  - The following decoding requirements are applicable only for the SIP
    Proxy server component.

     - The EA shall add the ‘Route’ header field to all SIP messages if
       it is not included by the UA. The content of the ‘Route’ header
       shall be same as the content of the ‘Service-Route’ header field
       saved by SIP Proxy server in step (3) of section 3.1 earlier.










Akhtar, et al.          Expires March 9, 2006               [Page 16]


Internet-Draft          SIP Header Reduction           September 2006


     - The EA shall add the ‘Allow’ header field to all SIP messages in
       the uplink direction (from UA to SIP Proxy server) if it is not
       included by the UA. The content of the 'Allow' header field shall
       be the same as the content of the ‘Allow’ header saved by SIP
       Proxy server in step (1) of section 3.1 earlier.

     - The EA shall add the 'Privacy' header field to all SIP messages
       if it is not included by the UA. The content of the header field
       shall be the same as the content of the ‘Privacy’ header field
       saved by SIP Proxy server in step (1) of section 3.1 earlier.

6.  Security Considerations

  The SIP Header Reduction proposal described in this document does not
  impose any additional security requirements on the UA or the SIP
  Proxy server.

  The EA function proposed in this document does not violate any securiy
  protocol (such as IPsec or TLS) between the UA and the SIP Proxy
  server.

7.  IANA Considerations


8.  Acknowledgments


9.  Refereneces

9.1 Normative References

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

 9.2 Informative References

  [2] TIA-873-004-A: "IP Multimedia Call Control Protocol Based
      on SIP and SDP Stage 3".

  [3] 3GPP2 X.S0013-004-A: "IP Multimedia Call Control Protocol Based
      on SIP and SDP Stage 3".

  [4] Akhtar, H., Khalil, M., Brombal, D., Jones, A., "3G Wireless
      Support in SIP/SDP Static Dictionary for Signaling Compression
      (SigComp)", draft-akhtar-sipping-3g-static-dictionary-00 (work
      in progress), February 2006.







Akhtar, et al.          Expires March 9, 2007               [Page 17]


Internet-Draft          SIP Header Reduction           September 2006


Authors' Addresses

   Haseeb Akhtar
   Nortel
   2221 Lakeside Blvd
   Richardson, TX  75082
   US

   Email: haseebak@nortel.com

   Dave Brombal
   Nortel
   2221 Lakeside Blvd
   Richardson, TX  75082
   US

   Email: davidb@nortel.com

   Anthony Jones
   Nortel
   3500 Carling Avenue
   Ottawa, Ontario
   K2H 8E9
   Canada

   Email: ajones@nortel.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Akhtar, et al.          Expires March 9, 2007               [Page 18]

Internet-Draft          SIP Header Reduction           September 2006


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.




Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/