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-Identitys 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 callees 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 tags value).
- The EA shall delete the To header from all SIP Invite
messages if the callees 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
messages 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 callees 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 callees 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" components 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.