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: *15[, ] 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 : - 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: *7[, ] 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 : - 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: *15[, ] 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:
*1023[,
] 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:
*1[,
] 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 <> component of the "o=" line. ii. The EA shall choose unique values (across time) for the <> and > 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 <>" 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.