draft-ietf-rohc-sigcomp-sip-04.txt   draft-ietf-rohc-sigcomp-sip-05.txt 
Robust Header Compression C. Bormann Robust Header Compression C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Expires: May 30, 2007 Z. Liu Expires: September 4, 2007 Z. Liu
Nokia Research Center Nokia Research Center
R. Price R. Price
Cogent Defence and Security Cogent Defence and Security
Networks Networks
G. Camarillo G. Camarillo, Ed.
Ericsson Ericsson
November 26, 2006 March 3, 2007
Applying Signaling Compression (SigComp) to the Session Initiation Applying Signaling Compression (SigComp) to the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-rohc-sigcomp-sip-04.txt draft-ietf-rohc-sigcomp-sip-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 30, 2007. This Internet-Draft will expire on September 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes some specifics that apply when Signaling This document describes some specifics that apply when Signaling
Compression (SigComp) is applied to the Session Initiation Protocol Compression (SigComp) is applied to the Session Initiation Protocol
(SIP), such as default minimum values of SigComp parameters, (SIP), such as default minimum values of SigComp parameters,
compartment and state management, and a few issues on SigComp over compartment and state management, and a few issues on SigComp over
TCP. Any implementation of SigComp for use with SIP must conform to TCP. Any implementation of SigComp for use with SIP must conform to
this document, in addition to SigComp and support of the SIP and this document, in addition to SigComp and support of the SIP and
Session Description Protocol (SDP) static dictionary. Session Description Protocol (SDP) static dictionary.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Minimum Values of SigComp Parameters for SIP/SigComp . . . . . 3 3. Compliance with this Specification . . . . . . . . . . . . . . 3
3.1. decompression_memory_size (DMS) for SIP/SigComp . . . . . 4 4. Minimum Values of SigComp Parameters for SIP/SigComp . . . . . 3
3.2. state_memory_size (SMS) for SIP/SigComp . . . . . . . . . 4 4.1. decompression_memory_size (DMS) for SIP/SigComp . . . . . 4
3.3. cycles_per_bit (CPB) for SIP/SigComp . . . . . . . . . . . 5 4.2. state_memory_size (SMS) for SIP/SigComp . . . . . . . . . 4
3.4. SigComp_version (SV) for SIP/SigComp . . . . . . . . . . . 5 4.3. cycles_per_bit (CPB) for SIP/SigComp . . . . . . . . . . . 5
3.5. locally available state (LAS) for SIP/SigComp . . . . . . 5 4.4. SigComp_version (SV) for SIP/SigComp . . . . . . . . . . . 5
4. Delimiting SIP Messages and SigComp Messages on the Same 4.5. locally available state (LAS) for SIP/SigComp . . . . . . 5
5. Delimiting SIP Messages and SigComp Messages on the Same
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6 6. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6
6. Too Large SIP Messages . . . . . . . . . . . . . . . . . . . . 6 7. Too Large SIP Messages . . . . . . . . . . . . . . . . . . . . 6
7. SIP Retransmissions . . . . . . . . . . . . . . . . . . . . . 6 8. SIP Retransmissions . . . . . . . . . . . . . . . . . . . . . 7
8. Compartment and State Management for SIP/SigComp . . . . . . . 7 9. Compartment and State Management for SIP/SigComp . . . . . . . 7
8.1. Remote Application Identification . . . . . . . . . . . . 7 9.1. Remote Application Identification . . . . . . . . . . . . 7
8.2. Identifier Comparison Rules . . . . . . . . . . . . . . . 10 9.2. Identifier Comparison Rules . . . . . . . . . . . . . . . 10
8.3. Compartment Opening and Closure . . . . . . . . . . . . . 10 9.3. Compartment Opening and Closure . . . . . . . . . . . . . 11
8.4. Compartment Valid During a Registration . . . . . . . . . 11 9.4. Lack of a Compartment . . . . . . . . . . . . . . . . . . 12
8.5. Lack of a Compartment . . . . . . . . . . . . . . . . . . 12 10. Recommendations for Network Administrators . . . . . . . . . . 13
9. Recommendations for Network Administrators . . . . . . . . . . 12 11. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 13
10. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 13 12. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14
11. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 13 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17.1. Normative References . . . . . . . . . . . . . . . . . . . 18
16.1. Normative References . . . . . . . . . . . . . . . . . . . 17 17.2. Informative References . . . . . . . . . . . . . . . . . . 19
16.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Introduction 1. Introduction
SigComp [RFC3320] is a solution for compressing messages generated by SigComp [RFC3320] is a solution for compressing messages generated by
application protocols. Although its primary driver is to compress application protocols. Although its primary driver is to compress
SIP [RFC3261] messages, the solution itself has been intentionally SIP [RFC3261] messages, the solution itself has been intentionally
designed to be application agnostic so that it can be applied to any designed to be application agnostic so that it can be applied to any
application protocol; this is denoted as ANY/SigComp. Consequently, application protocol; this is denoted as ANY/SigComp. Consequently,
many application dependent specifics are left out of the base many application dependent specifics are left out of the base
standard. It is intended that a separate specification is used to standard. It is intended that a separate specification is used to
describe those specifics when SigComp is applied to a particular describe those specifics when SigComp is applied to a particular
application protocol. application protocol.
This document binds SigComp and SIP; this is denoted as SIP/SigComp. This document binds SigComp and SIP; this is denoted as SIP/SigComp.
Any SigComp implementation that is used for the compression of SIP
messages must conform to this document, as well as to [RFC3320].
Additionally, it must support the SIP/SDP static dictionary as
specified in [RFC3485] and the mechanism for discovering SigComp
support at the SIP layer as specified in [RFC3486].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Minimum Values of SigComp Parameters for SIP/SigComp 3. Compliance with this Specification
Any SigComp implementation that is used for the compression of SIP
messages MUST conform to this document, as well as to [RFC3320].
Additionally, it must support the SIP/SDP static dictionary, as
specified in [RFC3485], and the mechanism for discovering SigComp
support at the SIP layer, as specified in [RFC3486].
4. Minimum Values of SigComp Parameters for SIP/SigComp
In order to support a wide range of capabilities among endpoints In order to support a wide range of capabilities among endpoints
implementing SigComp, SigComp defines a few parameters to describe implementing SigComp, SigComp defines a few parameters to describe
SigComp behavior (see section 3.3 of [RFC3320]). For each parameter, SigComp behavior (see section 3.3 of [RFC3320]). For each parameter,
[RFC3320] specifies a minimum value that any SigComp endpoint MUST [RFC3320] specifies a minimum value that any SigComp endpoint MUST
support for ANY/SigComp. Those minimum values were determined with support for ANY/SigComp. Those minimum values were determined with
the consideration of all imaginable devices in which SigComp may be the consideration of all imaginable devices in which SigComp may be
implemented. Scalability was also considered as a key factor. implemented. Scalability was also considered as a key factor.
However, some of the minimum values specified in [RFC3320] are too However, some of the minimum values specified in [RFC3320] are too
small to allow good performance for SIP message compression. small to allow good performance for SIP message compression.
Therefore, they are increased for SIP/SigComp as specified in the Therefore, they are increased for SIP/SigComp as specified in the
following sections. For completeness, those parameters that are the following sections. For completeness, those parameters that are the
same for SIP/SigComp as they are for ANY/SigComp are also listed. same for SIP/SigComp as they are for ANY/SigComp are also listed.
Note: the new minimum values are specific to SIP/SigComp. They do The new minimum values are specific to SIP/SigComp and, thus, do not
not apply to any other application protocols. apply to any other application protocols. A SIP/SigComp endpoint MAY
offer additional resources over and above the minimum values
Note: a SigComp endpoint MAY offer additional resources if available; specified in this document if available; these resources can be
these resources can be advertised to remote endpoints as described in advertised to remote endpoints as described in section 9.4.9 of
section 9.4.9 of [RFC3320]. [RFC3320].
3.1. decompression_memory_size (DMS) for SIP/SigComp 4.1. decompression_memory_size (DMS) for SIP/SigComp
Minimum value for ANY/SigComp: 2048 bytes, as specified in section Minimum value for ANY/SigComp: 2048 bytes, as specified in section
3.3.1 of [RFC3320]. 3.3.1 of [RFC3320].
Minimum value for SIP/SigComp: 8192 bytes. Minimum value for SIP/SigComp: 8192 bytes.
Reason: a DMS of 2048 bytes is too small for SIP message compression Reason: a DMS of 2048 bytes is too small for SIP message compression
as it seriously limits the compression ratio and even makes as it seriously limits the compression ratio and even makes
compression impossible for certain messages. For example, the compression impossible for certain messages. For example, the
condition set by [RFC3320] for SigComp over UDP means: C + 2*B + R + condition set by [RFC3320] for SigComp over UDP means: C + 2*B + R +
2*S + 128 < DMS (each term is described below). On the other hand, 2*S + 128 < DMS (each term is described below). Therefore, if DMs is
8KB additional memory should not cause any problem for an endpoint too small, at least one of C, B, R, or S will be severely restricted.
that already implements SIP, SigComp, and applications that use SIP On the other hand, DMS is memory that is only temporarily needed
as DMS is memory only temporarily needed during decompression of a during decompression of a SigComp message (the memory can be
SigComp message (the memory can be reclaimed when the message has reclaimed when the message has been decompressed). Therefore, a
been decompressed). requirement of 8 KB should not cause any problem for an endpoint that
already implements SIP, SigComp, and applications that use SIP.
C size of compressed application message, depending on R C size of compressed application message, depending on R
B size of bytecode. Note: two copies -- one as part of the SigComp B size of bytecode. Note: two copies -- one as part of the SigComp
message and one in UDVM (Universal Decompressor Virtual Machine) message and one in UDVM (Universal Decompressor Virtual Machine)
memory. memory.
R size of ring buffer in UDVM memory R size of circular buffer in UDVM memory
S any additional state uploaded other than that created from the S any additional state uploaded other than that created from the
content of the ring buffer at the end of decompression (similar to content of the circular buffer at the end of decompression
B, two copies of S are needed) (similar to B, two copies of S are needed)
128 the smallest address in UDVM memory to copy bytecode to 128 the smallest address in UDVM memory to copy bytecode to
3.2. state_memory_size (SMS) for SIP/SigComp 4.2. state_memory_size (SMS) for SIP/SigComp
Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in
section 3.3.1 of [RFC3320]. section 3.3.1 of [RFC3320].
Minimum value for SIP/SigComp: 2048 bytes. Minimum value for SIP/SigComp: 2048 bytes.
Reason: a non-zero SMS allows an endpoint to upload a state in the Reason: a non-zero SMS allows an endpoint to upload a state in the
first SIP message sent to a remote endpoint without the uncertainty first SIP message sent to a remote endpoint without the uncertainty
of whether or not it can be created in the remote endpoint. A non- of whether the remote endpoint will have enough memory to store such
zero SMS obviously requires the SIP/SigComp implementation to keep a state. A non-zero SMS obviously requires the SIP/SigComp
state. Based on the observation that there is little gain from implementation to keep state. Based on the observation that there is
stateless SigComp compression, the assumption is that purely little gain from stateless SigComp compression, the assumption is
stateless SIP implementations are unlikely to provide a SigComp that purely stateless SIP implementations are unlikely to provide a
function. Stateful implementations should have little problem to SigComp function. Stateful implementations should have little
keep 2K additional state for each compartment (see Section 8). problem to keep 2K additional state for each compartment (see
Section 9).
Note: SMS is a parameter that applies to each individual compartment. Note: SMS is a parameter that applies to each individual compartment.
An endpoint MAY offer different SMS values for different compartments An endpoint MAY offer different SMS values for different compartments
as long as the SMS value is not less than 2048 bytes. as long as the SMS value is not less than 2048 bytes.
3.3. cycles_per_bit (CPB) for SIP/SigComp 4.3. cycles_per_bit (CPB) for SIP/SigComp
Minimum value for ANY/SigComp: 16, as specified in section 3.3.1 of Minimum value for ANY/SigComp: 16, as specified in section 3.3.1 of
[RFC3320]. [RFC3320].
Minimum value for SIP/SigComp: 16 (same as above) Minimum value for SIP/SigComp: 16 (same as above)
3.4. SigComp_version (SV) for SIP/SigComp 4.4. SigComp_version (SV) for SIP/SigComp
For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320]. For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320].
For SIP/SigComp: >= 0x02 (at least SigComp + NACK) For SIP/SigComp: >= 0x02 (at least SigComp + NACK)
3.5. locally available state (LAS) for SIP/SigComp 4.5. locally available state (LAS) for SIP/SigComp
Minimum LAS for ANY/SigComp: none, see section 3.3.3 of [RFC3320]. Minimum LAS for ANY/SigComp: none, see section 3.3.3 of [RFC3320].
Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined
in [RFC3485]. in [RFC3485].
4. Delimiting SIP Messages and SigComp Messages on the Same Port Note that, since support for the static SIP/SDP dictionary is
mandatory, it does not need to be advertised.
5. Delimiting SIP Messages and SigComp Messages on the Same Port
In order to limit the number of ports required by a SigComp-aware In order to limit the number of ports required by a SigComp-aware
endpoint, it is possible to allow both SigComp messages and 'vanilla' endpoint, it is possible to allow both SigComp messages and 'vanilla'
SIP messages (i.e. uncompressed SIP messages with no SigComp header) SIP messages (i.e. uncompressed SIP messages with no SigComp header)
to arrive on the same port. to arrive on the same port.
For a message-based transport such as UDP or SCTP, this can be done For a message-based transport such as UDP or SCTP, distinguishing
per message. The receiving endpoint checks the first octet of the between SigComp and non-SigComp messages can be done per message.
UDP/SCTP payload to determine whether the message has been compressed The receiving endpoint checks the first octet of the UDP/SCTP payload
using SigComp. If the MSBs (Most Significant Bits) of the octet are to determine whether the message has been compressed using SigComp.
"11111" then the message is considered to be a SigComp message and is If the MSBs (Most Significant Bits) of the octet are "11111" then the
parsed as per [RFC3320]. If the MSBs of the octet take any other message is considered to be a SigComp message and is parsed as per
value, then the message is assumed to be an uncompressed SIP message,
and is passed directly to the application with no further effect on
the SigComp layer.
For a stream-based transport such as TCP, the distinction is per
connection. The receiving endpoint checks the first octet of the TCP
data stream to determine whether the stream has been compressed using
SigComp. If the MSBs of the octet are "11111" then the stream is
considered to contain SigComp messages and is parsed as per
[RFC3320]. If the MSBs of the octet take any other value, then the [RFC3320]. If the MSBs of the octet take any other value, then the
stream is assumed to contain uncompressed SIP messages, and is passed message is assumed to be an uncompressed SIP message, and is passed
directly to the application with no further effect on the SigComp directly to the application with no further effect on the SigComp
layer. Note that SigComp message delimiters MUST NOT be used if the layer.
stream contains uncompressed SIP messages.
For a stream-based transport such as TCP, distinguishing between
SigComp and non-SigComp messages has to be done per connection. The
receiving endpoint checks the first octet of the TCP data stream to
determine whether the stream has been compressed using SigComp. If
the MSBs of the octet are "11111" then the stream is considered to
contain SigComp messages and is parsed as per [RFC3320]. If the MSBs
of the octet take any other value, then the stream is assumed to
contain uncompressed SIP messages, and is passed directly to the
application with no further effect on the SigComp layer. Note that
SigComp message delimiters MUST NOT be used if the stream contains
uncompressed SIP messages.
Applications MUST NOT mix SIP messages and SigComp messages on a Applications MUST NOT mix SIP messages and SigComp messages on a
single TCP connection. If the TCP connection is used to carry single TCP connection. If the TCP connection is used to carry
SigComp messages then all messages sent over the connection MUST have SigComp messages then all messages sent over the connection MUST have
a SigComp header and be delimited by the use of 0xFFFF as described a SigComp header and be delimited by the use of 0xFFFF as described
in [RFC3320]. in [RFC3320].
[I-D.ietf-rohc-sigcomp-impl-guide] shows how to send uncompressed [I-D.ietf-rohc-sigcomp-impl-guide] shows how to send uncompressed
messages in a SigComp structured TCP connection using a "well-known messages in a SigComp-structured TCP connection using a "well-known
shim header". Should it for any reason not be desirable to set up shim header". Should it for any reason not be desirable to set up
more than one TCP connection to a SIP implementation, but the more than one TCP connection to a SIP implementation, but the
flexibility to send both compressed and uncompressed SIP messages be flexibility to send both compressed and uncompressed SIP messages be
required, the compressor can set up a SigComp structured connection required, the compressor can set up a SigComp-structured connection
and send any uncompressed SIP messages using the well-known shim and send any uncompressed SIP messages using the well-known shim
header. header.
5. Continuous Mode over TCP 6. Continuous Mode over TCP
Continuous Mode is a special feature of SigComp, which is designed to Continuous Mode is a special feature of SigComp, which is designed to
improve the overall compression ratio for long-lived connections. improve the overall compression ratio for long-lived connections.
Its use requires pre-agreement between the SigComp compressor and Its use requires pre-agreement between the SigComp compressor and
decompressor. Continuous mode is not used with SIP/SigComp. decompressor. Continuous mode is not used with SIP/SigComp.
Reason: continuous mode requires the transport itself to provide a Reason: continuous mode requires the transport itself to provide a
certain level of protection against denial of service attacks. TCP certain level of protection against denial of service attacks. TCP
alone is not considered to provide enough protection. alone is not considered to provide enough protection.
6. Too Large SIP Messages 7. Too Large SIP Messages
SigComp does not support the compression of messages larger than 64k. SigComp does not support the compression of messages larger than 64k.
Therefore, if a SIP application sending compressed SIP messages to Therefore, if a SIP application sending compressed SIP messages to
another SIP application over a transport connection (e.g., a TCP another SIP application over a transport connection (e.g., a TCP
connection) needs to send a SIP message larger than 64k, the SIP connection) needs to send a SIP message larger than 64k, the SIP
application SHOULD establish a new transport connection and send the application SHOULD establish a new transport connection and send the
(uncompressed) SIP message over the new connection. (uncompressed) SIP message over the new connection.
7. SIP Retransmissions 8. SIP Retransmissions
SIP retransmissions need to be compressed again before being sent. SIP retransmissions need to be compressed again before being sent.
That is, SIP applications MUST NOT retransmit already-compressed That is, SIP applications MUST NOT retransmit already-compressed
information. information.
The reason for this behavior is that it is impossible to know whether The reason for this behavior is that it is impossible to know whether
the failure causing the retransmission occurred to the message being the failure causing the retransmission occurred on the message being
retransmitted or to the response to that message. If the loss retransmitted or on the response to that message. If the response
occurred to the response, any state changes effected by the first was lost, any state changes effected by the first instance of the
instance of the retransmitted message would already have taken place. retransmitted message would already have taken place. If these state
If these state changes removed a state that the previously- changes removed a state that the previously-transmitted message
transmitted message relied upon, then retransmission of the same relied upon, then retransmission of the same compressed message would
compressed message would lead to a decompression failure. lead to a decompression failure.
8. Compartment and State Management for SIP/SigComp 9. Compartment and State Management for SIP/SigComp
An application exchanging compressed traffic with a remote An application exchanging compressed traffic with a remote
application has a compartment that contains state information needed application has a compartment that contains state information needed
to compress outgoing messages and to decompress incoming messages. to compress outgoing messages and to decompress incoming messages.
To increase the compression efficiency, the application must assign To increase the compression efficiency, the application must assign
distinct compartments to distinct remote applications. distinct compartments to distinct remote applications.
8.1. Remote Application Identification 9.1. Remote Application Identification
SIP/SigComp applications identify remote applications by their SIP/ SIP/SigComp applications identify remote applications by their SIP/
SigComp identifiers. Each SIP/SigComp application MUST have a SIP/ SigComp identifiers. Each SIP/SigComp application MUST have a SIP/
SigComp identifier URN (Uniform Resource Name) that uniquely SigComp identifier URN (Uniform Resource Name) that uniquely
identifies the application. Usage of a URN provides a persistent and identifies the application. Usage of a URN provides a persistent and
unique name for the SIP/SigComp identifier. It also provides an easy unique name for the SIP/SigComp identifier. It also provides an easy
way to guarantee uniqueness. This URN MUST be persistent as long as way to guarantee uniqueness. This URN MUST be persistent as long as
the application stores compartment state related to other SIP/SigComp the application stores compartment state related to other SIP/SigComp
applications. applications.
skipping to change at page 9, line 10 skipping to change at page 9, line 21
appear in '+sip.instance' Contact header field parameters, and not appear in '+sip.instance' Contact header field parameters, and not
in SIP URI parameters. We have chosen to define 'sigcomp-id' as a in SIP URI parameters. We have chosen to define 'sigcomp-id' as a
SIP URI parameter to be consistent with the use of the already-in- SIP URI parameter to be consistent with the use of the already-in-
use 'comp=sigcomp' parameter, which is a SIP URI parameter as use 'comp=sigcomp' parameter, which is a SIP URI parameter as
well. well.
The following is an example of a 'sigcomp-id' SIP URI parameter: The following is an example of a 'sigcomp-id' SIP URI parameter:
sigcomp-id=urn%3auuid%3a0C67446E-F1A1-11D9-94D3-000A95A0E128 sigcomp-id=urn%3auuid%3a0C67446E-F1A1-11D9-94D3-000A95A0E128
The following is an example of a REGISTER request that carries
'sigcomp-id' parameters in a Via entry and in the Contact header
field. Additionally, it also carries a '+sip.instance' Contact
header field parameter.
REGISTER sip:example.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.247:2078;branch=z9hG4bK-et736vsjirav;
rport;sigcomp-id="urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473"
From: "Joe User" <sip:2145550500@example.net>;tag=6to4gh7t5j
To: "Joe User" <sip:2145550500@example.net>
Call-ID: 3c26700c1adb-lu1lz5ri5orr
CSeq: 215196 REGISTER
Max-Forwards: 70
Contact: <sip:2145550500@192.0.2.247:2078;
sigcomp-id=urn%3auuid%3a2e5fdc76-00be-4314-8202-1116fa82a473>;
q=1.0; expires=3600;
+sip.instance="<urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>"
Content-Length: 0
SIP messages are matched with remote application identifiers as SIP messages are matched with remote application identifiers as
follows. follows.
Outgoing requests: the remote application identifier is the SIP/ Outgoing requests: the remote application identifier is the SIP/
SigComp identifier of the URI to which the request is sent. If SigComp identifier of the URI to which the request is sent. If
the URI does not contain a SIP/SigComp identifier, the remote the URI does not contain a SIP/SigComp identifier, the remote
application identifier is the IP address plus port of the datagram application identifier is the IP address plus port of the datagram
carrying the request for connection-less transport protocols, and carrying the request for connection-less transport protocols, and
the transport connection (e.g., a TCP connection) carrying the the transport connection (e.g., a TCP connection) carrying the
request for connection-oriented transport protocols (this is to request for connection-oriented transport protocols (this is to
support legacy SIP/SigComp applications). support legacy SIP/SigComp applications).
Incoming responses: the remote application identifier is the same as Incoming responses: the remote application identifier is the same as
the one of the previously-sent request that initiated the that of the previously-sent request that initiated the transaction
transaction the response belongs to. to which the response belongs.
Incoming requests: the remote application identifier is the SIP/ Incoming requests: the remote application identifier is the SIP/
SigComp identifier of the top-most Via entry. If the Via header SigComp identifier of the top-most Via entry. If the Via header
field does not contain a SIP/SigComp identifier, the remote field does not contain a SIP/SigComp identifier, the remote
application identifier is the source IP address plus port of the application identifier is the source IP address plus port of the
datagram carrying the request for connection-less transport datagram carrying the request for connection-less transport
protocols, and the transport connection (e.g., a TCP connection) protocols, and the transport connection (e.g., a TCP connection)
carrying the request for connection-oriented transport protocols carrying the request for connection-oriented transport protocols
(this is to support legacy SIP/SigComp applications). (this is to support legacy SIP/SigComp applications).
Outgoing responses: the remote application identifier is the same as Outgoing responses: the remote application identifier is the same as
the previously-received request that initiated the transaction the that of the previously-received request that initiated the
response belongs to. Note that, due to standard SIP Via header transaction to which the response belongs. Note that, due to
field processing, this identifier will be present in the top-most standard SIP Via header field processing, this identifier will be
Via entry in such responses (as long as it was present in the top- present in the top-most Via entry in such responses (as long as it
most Via entry of the previously-received request). was present in the top-most Via entry of the previously-received
request).
A SIP/SigComp application placing its URI with the 'comp=sigcomp' A SIP/SigComp application placing its URI with the 'comp=sigcomp'
parameter in a header field MUST add a 'sigcomp-id' parameter with parameter in a header field MUST add a 'sigcomp-id' parameter with
its SIP/SigComp identifier to that URI. its SIP/SigComp identifier to that URI.
A SIP/SigComp application generating its own Via entry containing the A SIP/SigComp application generating its own Via entry containing the
'comp=sigcomp' parameter MUST add a 'sigcomp-id' parameter with its 'comp=sigcomp' parameter MUST add a 'sigcomp-id' parameter with its
SIP/SigComp identifier to that Via entry. SIP/SigComp identifier to that Via entry.
A given remote application identifier is mapped to a particular A given remote application identifier is mapped to a particular
SigComp compartment ID following the rules given in Section 8.3 and SigComp compartment ID following the rules given in Section 9.3.
Section 8.4.
8.2. Identifier Comparison Rules 9.2. Identifier Comparison Rules
Equality comparisons between SIP/SigComp identifiers are performed Equality comparisons between SIP/SigComp identifiers are performed
using the rules for URN equality that are specific to the scheme in using the rules for URN equality that are specific to the scheme in
the URN. If the element performing the comparisons does not the URN. If the element performing the comparisons does not
understand the URN scheme, it performs the comparisons using the understand the URN scheme, it performs the comparisons using the
lexical equality rules defined in RFC 2141 [RFC2141]. Lexical lexical equality rules defined in RFC 2141 [RFC2141]. Lexical
equality may result in two URNs being considered unequal when they equality may result in two URNs being considered unequal when they
are actually equal. In this specific usage of URNs, the only element are actually equal. In this specific usage of URNs, the only element
which provides the URN is the SIP/SigComp application identified by which provides the URN is the SIP/SigComp application identified by
that URN. As a result, the SIP/SigComp application SHOULD provide that URN. As a result, the SIP/SigComp application SHOULD provide
lexically equivalent URNs in each registration it generates. This is lexically equivalent URNs in each registration it generates. This is
likely to be normal behavior in any case; applications are not likely likely to be normal behavior in any case; applications are not likely
to modify the value of their SIP/SigComp identifiers so that they to modify the value of their SIP/SigComp identifiers so that they
remain functionally equivalent yet lexigraphically different from remain functionally equivalent yet lexigraphically different from
previous identifiers. previous identifiers.
8.3. Compartment Opening and Closure 9.3. Compartment Opening and Closure
SIP applications need to know when to open a new compartment and when SIP applications need to know when to open a new compartment and when
to close it. The lifetime of SIP/SigComp compartments is linked to to close it. The lifetime of SIP/SigComp compartments is linked to
registration state. Compartments are opened at SIP registration time registration state. Compartments are opened at SIP registration time
and are typically closed when the registration expires or is and are typically closed when the registration expires or is
canceled. canceled.
Previous revisions of this document also defined compartments Previous revisions of this document also defined compartments
valid during a SIP transaction or a SIP dialog. It was decided to valid during a SIP transaction or a SIP dialog. It was decided to
eliminate those types of compartments because the complexity they eliminate those types of compartments because the complexity they
skipping to change at page 10, line 51 skipping to change at page 11, line 34
(same) state. (same) state.
A SigComp endpoint may offer to keep a state created upon request A SigComp endpoint may offer to keep a state created upon request
from a SigComp peer endpoint beyond the default lifetime of a from a SigComp peer endpoint beyond the default lifetime of a
compartment (i.e., beyond the duration of its associated compartment (i.e., beyond the duration of its associated
registration). This may be used to improve compression efficiency of registration). This may be used to improve compression efficiency of
subsequent SIP messages generated by the same remote application at subsequent SIP messages generated by the same remote application at
the SigComp peer endpoint. To indicate that such state will continue the SigComp peer endpoint. To indicate that such state will continue
to be available, the SigComp endpoint can inform its peer SigComp to be available, the SigComp endpoint can inform its peer SigComp
endpoint by announcing the (partial) state ID in the returned SigComp endpoint by announcing the (partial) state ID in the returned SigComp
parameters at the end of the registration, dialog, or transaction parameters at the end of the registration that was supposed to limit
that was supposed to limit the lifetime of the SigComp state. That the lifetime of the SigComp state. That signals the state will be
signals the state will be maintained. The mandatory support for the maintained. The mandatory support for the SigComp Negative
SigComp Negative Acknowledgement (NACK) Mechanism [RFC4077] in SIP/ Acknowledgement (NACK) Mechanism [RFC4077] in SIP/SigComp ensures
SigComp ensures that it is possible to recover from synchronization that it is possible to recover from synchronization errors regarding
errors regarding comparment lifetimes. compartment lifetimes.
As an operational concern, bugs in the compartment management As an operational concern, bugs in the compartment management
implementation are likely to lead to sporadic, hard to diagnose implementation are likely to lead to sporadic, hard to diagnose
failures. Decompressors may therefore want to cache old state and, failures. Decompressors may therefore want to cache old state and,
if still available, allow access while logging diagnostic if still available, allow access while logging diagnostic
information. Both compressors and decompressors use the SigComp information. Both compressors and decompressors use the SigComp
Negative Acknowledgement (NACK) Mechanism [RFC4077] to recover from Negative Acknowledgement (NACK) Mechanism [RFC4077] to recover from
situations where such old state may no longer be available. situations where such old state may no longer be available.
8.4. Compartment Valid During a Registration
A REGISTER transaction causes an application to open a new A REGISTER transaction causes an application to open a new
compartment to be valid for the duration of the registration compartment to be valid for the duration of the registration
established by the REGISTER transaction. established by the REGISTER transaction.
A SIP application that needs to send a compressed SIP REGISTER (i.e., A SIP application that needs to send a compressed SIP REGISTER (i.e.,
a user agent generating a REGISTER or a proxy server relaying one to a user agent generating a REGISTER or a proxy server relaying one to
its next hop) SHOULD open a compartment for the request's remote its next hop) SHOULD open a compartment for the request's remote
application identifier. A SIP application that receives a compressed application identifier. A SIP application that receives a compressed
SIP REGISTER (i.e., the registrar or a proxy relaying the REGISTER to SIP REGISTER (i.e., the registrar or a proxy relaying the REGISTER to
its next-hop) SHOULD open a compartment for the request's remote its next-hop) SHOULD open a compartment for the request's remote
skipping to change at page 12, line 4 skipping to change at page 12, line 33
initial REGISTER transaction. The path the REGISTER transaction initial REGISTER transaction. The path the REGISTER transaction
follows is typically determined by configuration data. The path follows is typically determined by configuration data. The path
subsequent requests traverse is determined by the Path [RFC3327] subsequent requests traverse is determined by the Path [RFC3327]
and the Service-Route [RFC3308] header fields in the REGISTER and the Service-Route [RFC3308] header fields in the REGISTER
transaction and by the Record-Route and the Route header fields in transaction and by the Record-Route and the Route header fields in
dialog-creating transactions. Previous revisions of this document dialog-creating transactions. Previous revisions of this document
supported the use of different paths for different types of supported the use of different paths for different types of
traffic. However, for simplicity reasons, this document now traffic. However, for simplicity reasons, this document now
assumes that networks using compression are configured so that assumes that networks using compression are configured so that
subsequent requests follow the same path as the initial REGISTER subsequent requests follow the same path as the initial REGISTER
transaction. Section 9 provides network administrators with transaction. Section 10 provides network administrators with
recommendations so that they configure they networks properly. recommendations so that they can configure they networks properly.
If following the previous rules, a SIP application is supposed to If, following the rules above, a SIP application is supposed to open
open a compartment for a remote application identifier for which it a compartment for a remote application identifier for which it
already has a compartment, the SIP application MUST use the already already has a compartment, the SIP application MUST use the already
existing compartment. That is, the SIP application MUST NOT open a existing compartment. That is, the SIP application MUST NOT open a
new compartment. new compartment.
8.5. Lack of a Compartment 9.4. Lack of a Compartment
The use of stateless compression (i.e., compression without a The use of stateless compression (i.e., compression without a
compartment) is not typically worthwhile and may even result in compartment) is not typically worthwhile and may even result in
message expansion. Therefore, if a SIP application does not have a message expansion. Therefore, if a SIP application does not have a
compartment for a message it needs to send, it SHOULD NOT compress it compartment for a message it needs to send, it MAY choose not to
even in the presence of the comp=sigcomp parameter. Note that RFC compress it even in the presence of the comp=sigcomp parameter. Note
3486 [RFC3486] states the following: that RFC 3486 [RFC3486] states the following:
"If the next-hop URI contains the parameter comp=sigcomp, the "If the next-hop URI contains the parameter comp=sigcomp, the
client SHOULD compress the request using SigComp" client SHOULD compress the request using SigComp"
Experience since RFC 3486 [RFC3486] was written has shown that Experience since RFC 3486 [RFC3486] was written has shown that
stateless compression is not worthwhile. That is why now it is not stateless compression is, in most cases, not worthwhile. That is why
recommended to use it any longer. now it is not recommended to use it any longer.
9. Recommendations for Network Administrators 10. Recommendations for Network Administrators
Network administrators can configure their networks so that the Network administrators can configure their networks so that the
compression efficiency achieved is increased. The following compression efficiency achieved is increased. The following
recommendations help network administrators perform their task. recommendations help network administrators perform their task.
For a given user agent, the route sets for incoming requests (created For a given user agent, the route sets for incoming requests (created
by a Path header field) and for outgoing requests (created by a by a Path header field) and for outgoing requests (created by a
Service-Route header field) are typically the same. However, Service-Route header field) are typically the same. However,
registrars can, if they wish, insert proxies in the latter route that registrars can, if they wish, insert proxies in the latter route that
do not appear in the former route and vice versa. It is RECOMMENDED do not appear in the former route and vice versa. It is RECOMMENDED
skipping to change at page 13, line 13 skipping to change at page 13, line 42
inside dialogs. inside dialogs.
When a user agent's registration expires, proxy servers performing When a user agent's registration expires, proxy servers performing
compression may close their associated SIP/SigComp compartment. If compression may close their associated SIP/SigComp compartment. If
the user agent is involved in a dialog that was established before the user agent is involved in a dialog that was established before
the registration expired, subsequent requests within the dialog may the registration expired, subsequent requests within the dialog may
not be compressed any longer. In order to avoid this situation, it not be compressed any longer. In order to avoid this situation, it
is RECOMMENDED that user agents are registered as long as they are is RECOMMENDED that user agents are registered as long as they are
involved in a dialog. involved in a dialog.
10. Private Agreements 11. Private Agreements
SIP/SigComp implementations that are subject to private agreements SIP/SigComp implementations that are subject to private agreements
MAY deviate from this specification, if the private agreements MAY deviate from this specification, if the private agreements
unambiguously specify so. Plausible candidates for such deviations unambiguously specify so. Plausible candidates for such deviations
include: include:
o Minimum values (Section 3). o Minimum values (Section 4).
o Use of continuous mode (Section 5). o Use of continuous mode (Section 6).
o Compartment definition (Section 8). o Compartment definition (Section 9).
11. Backwards Compatibility 12. Backwards Compatibility
SigComp has a number of parameters that can be configured per SigComp has a number of parameters that can be configured per
endpoint. This document specifies a profile for SigComp when used endpoint. This document specifies a profile for SigComp when used
for SIP compression that further constrains the range that some of for SIP compression that further constrains the range that some of
these parameters may take. Examples of this are Decompressor Memory these parameters may take. Examples of this are Decompressor Memory
Size, State Memory Size, and SigComp Version (support for NACK). Size, State Memory Size, and SigComp Version (support for NACK).
Additionally, this document specifies how SIP/SigComp applications Additionally, this document specifies how SIP/SigComp applications
should perform compartment mapping. should perform compartment mapping.
When this document was written, there already were a few existing When this document was written, there already were a few existing
SIP/SigComp deployments. The rules in this document have been SIP/SigComp deployments. The rules in this document have been
designed to maximize interoperability with those legacy SIP/SigComp designed to maximize interoperability with those legacy SIP/SigComp
implementations. Nevertheless, implementers should be aware that implementations. Nevertheless, implementers should be aware that
legacy SIP/SigComp implementations may not conform to this legacy SIP/SigComp implementations may not conform to this
specification. Examples of problems with legacy applications would specification. Examples of problems with legacy applications would
be smaller DMS than mandated in this document, lack of NACK support, be smaller DMS than mandated in this document, lack of NACK support,
or a different comparment mapping. or a different compartment mapping.
12. Example 13. Example
Figure 1 shows an example message flow where the user agent and the Figure 1 shows an example message flow where the user agent and the
outbound proxy exchange compressed SIP traffic. Compressed messages outbound proxy exchange compressed SIP traffic. Compressed messages
are marked with a (c). are marked with a (c).
User Agent Outbound Proxy Registrar User Agent Outbound Proxy Registrar
|(1) REGISTER (c) | | |(1) REGISTER (c) | |
|---------------->| | |---------------->| |
| |(2) REGISTER | | |(2) REGISTER |
skipping to change at page 14, line 40 skipping to change at page 15, line 40
| |------------------------------> | |------------------------------>
| |(13) 200 OK | | |(13) 200 OK |
| |<------------------------------ | |<------------------------------
|(14) 200 OK (c) | | |(14) 200 OK (c) | |
|<----------------| | |<----------------| |
Figure 1: Example message flow Figure 1: Example message flow
The user agent in Figure 1 is initialy configured (e.g., using the The user agent in Figure 1 is initialy configured (e.g., using the
SIP configuration framework [I-D.ietf-sipping-config-framework]) with SIP configuration framework [I-D.ietf-sipping-config-framework]) with
the URI of its outbound proxy. That URI contains the outbound's the URI of its outbound proxy. That URI contains the outbound
proxy SIP/SigComp identifier, referred to as 'Outbound-id', in a proxy's SIP/SigComp identifier, referred to as 'Outbound-id', in a
'sigcomp-id' parameter. 'sigcomp-id' parameter.
When the user agent sends an initial REGISTER request (1) to the When the user agent sends an initial REGISTER request (1) to the
outbound proxy's URI, the user agent opens a new compartment for outbound proxy's URI, the user agent opens a new compartment for
'Outbound-id'. This compartment will be valid, at least, for the 'Outbound-id'. This compartment will be valid, at least, for the
duration of the registration. duration of the registration.
On receiving this REGISTER request (1), the outbound proxy opens a On receiving this REGISTER request (1), the outbound proxy opens a
new compartment for the SIP/SigComp identifier that appears in the new compartment for the SIP/SigComp identifier that appears in the
'sigcomp-id' parameter of the top-most Via entry. This identifier, 'sigcomp-id' parameter of the top-most Via entry. This identifier,
skipping to change at page 15, line 17 skipping to change at page 16, line 17
'Outbound-id' SIP/SigComp identifier, to the REGISTER request and 'Outbound-id' SIP/SigComp identifier, to the REGISTER request and
relays it to the registrar (2). relays it to the registrar (2).
When the registrar receives the REGISTER request (2), it constructs When the registrar receives the REGISTER request (2), it constructs
the route future incoming requests (to the user agent) will follow the route future incoming requests (to the user agent) will follow
using the Contact and the Path header fields. Future incoming using the Contact and the Path header fields. Future incoming
requests will traverse the outbound proxy before reaching the user requests will traverse the outbound proxy before reaching the user
agent. agent.
The registrar also constructs the route future outgoing requests The registrar also constructs the route future outgoing requests
(from the user agent) and places it in a Service-Route header field (from the user agent) will follow and places it in a Service-Route
in a 200 (OK) response (3). Future outgoing requests will always header field in a 200 (OK) response (3). Future outgoing requests
traverse the outbound proxy. The registrar has ensured that the will always traverse the outbound proxy. The registrar has ensured
outbound proxy performing compression handles both incoming and that the outbound proxy performing compression handles both incoming
outgoing requests. and outgoing requests.
When the outbound proxy receives a 200 (OK) response (3), it inspects When the outbound proxy receives a 200 (OK) response (3), it inspects
the top-most Via entry. This entry's SIP/SigComp identifier 'UA-id' the top-most Via entry. This entry's SIP/SigComp identifier 'UA-id'
matches that of the compartment created before. Therefore, the matches that of the compartment created before. Therefore, the
outbound proxy uses that compartment to compress it and relay it to outbound proxy uses that compartment to compress it and relay it to
the user agent. the user agent.
On receiving the 200 (OK) response (4), the user agent stores the On receiving the 200 (OK) response (4), the user agent stores the
Service-Route header field in order to use it to send future outgoing Service-Route header field in order to use it to send future outgoing
requests. The Service-Route header field contains the outbound requests. The Service-Route header field contains the outbound
skipping to change at page 15, line 49 skipping to change at page 17, line 5
the INVITE request. the INVITE request.
On receiving the INVITE request (5), the outbound proxy Record Routes On receiving the INVITE request (5), the outbound proxy Record Routes
and relays the INVITE request (6) forward. The outbound proxy Record and relays the INVITE request (6) forward. The outbound proxy Record
Routes to ensure that all SIP messages related to this new dialog are Routes to ensure that all SIP messages related to this new dialog are
routed through the outbound proxy. routed through the outbound proxy.
Finally the dialog is terminated by a BYE transaction (11) that also Finally the dialog is terminated by a BYE transaction (11) that also
traverses the outbound proxy. traverses the outbound proxy.
13. Security Considerations 14. Security Considerations
The same security considerations as described in [RFC3320] apply to The same security considerations as described in [RFC3320] apply to
this document. Note that keeping SigComp states longer than the this document. Note that keeping SigComp states longer than the
duration of a SIP dialog should not pose new security risks for two duration of a SIP dialog should not pose new security risks for two
reasons: a) the state has been allowed to be created in the first reasons: a) the state has been allowed to be created in the first
place; and b) this is on voluntary basis and a SigComp endpoint can place; and b) this is on voluntary basis and a SigComp endpoint can
choose not to offer it. choose not to offer it.
14. IANA Considerations 15. IANA Considerations
The IANA is requested to register the 'sigcomp-id' Via header field The IANA is requested to register the 'sigcomp-id' Via header field
parameter, which is defined in Section 8.1, under the Header Field parameter, which is defined in Section 9.1, under the Header Field
Parameters and Parameter Values subregistry within the SIP Parameters Parameters and Parameter Values subregistry within the SIP Parameters
registry: registry:
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
---------------------------- --------------- --------- --------- ---------------------------- --------------- --------- ---------
Via sigcomp-id No [RFCxxxx] Via sigcomp-id No [RFCxxxx]
The IANA is requested to register the 'sigcomp-id' SIP URI parameter, The IANA is requested to register the 'sigcomp-id' SIP URI parameter,
which is defined in Section 8.1, under the SIP/SIPS URI Parameters which is defined in Section 9.1, under the SIP/SIPS URI Parameters
subregistry within the SIP Parameters registry: subregistry within the SIP Parameters registry:
Parameter Name Predefined Values Reference Parameter Name Predefined Values Reference
-------------- ----------------- --------- -------------- ----------------- ---------
sigcomp-id No [RFCxxxx] sigcomp-id No [RFCxxxx]
Note to the RFC Editor: please, substitute RFCxxxx with the RFC Note to the RFC Editor: please, substitute RFCxxxx with the RFC
number this document will get. number this document will get.
15. Acknowledgements 16. Acknowledgements
The authors would like to thank the following people for their The authors would like to thank the following people for their
comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West, comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West,
Pekka Pessi, Robert Sugar, Jonathan Rosenberg, and Robert Sparks. Pekka Pessi, Robert Sugar, Jonathan Rosenberg, and Robert Sparks.
Abigail Surtees and Adam Roach performed thorough reviews of this Abigail Surtees and Adam Roach performed thorough reviews of this
document. document.
16. References 17. References
16.1. Normative References 17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
skipping to change at page 17, line 50 skipping to change at page 18, line 50
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-04 (work in progress), June 2006. draft-ietf-sip-outbound-07 (work in progress),
January 2007.
[I-D.ietf-rohc-sigcomp-impl-guide] [I-D.ietf-rohc-sigcomp-impl-guide]
Surtees, A., "Implementer's Guide for SigComp", Surtees, A., "Implementer's Guide for SigComp",
draft-ietf-rohc-sigcomp-impl-guide-06 (work in progress), draft-ietf-rohc-sigcomp-impl-guide-10 (work in progress),
March 2006. January 2007.
16.2. Informative References 17.2. Informative References
[I-D.ietf-sipping-config-framework] [I-D.ietf-sipping-config-framework]
Petrie, D., "A Framework for Session Initiation Protocol Petrie, D. and S. Channabasappa, "A Framework for Session
User Agent Profile Delivery", Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-08 (work in progress), draft-ietf-sipping-config-framework-10 (work in progress),
March 2006. January 2007.
Authors' Addresses Authors' Addresses
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28334 Bremen D-28334
Germany Germany
Phone: +49 421 218 7024 Phone: +49 421 218 7024
skipping to change at page 19, line 35 skipping to change at page 20, line 4
Richard Price Richard Price
Cogent Defence and Security Networks Cogent Defence and Security Networks
Queensway Meadows Industrial Estate Queensway Meadows Industrial Estate
Meadows Road Meadows Road
Newport, Gwent NP19 4SS Newport, Gwent NP19 4SS
Phone: +44 (0)1794 833681 Phone: +44 (0)1794 833681
Email: richard.price@cogent-dsn.com Email: richard.price@cogent-dsn.com
URI: http://www.cogent-dsn.com URI: http://www.cogent-dsn.com
Gonzalo Camarillo (editor)
Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 20, line 29 skipping to change at page 21, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 71 change blocks. 
179 lines changed or deleted 206 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/