summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5049.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5049.txt')
-rw-r--r--doc/rfc/rfc5049.txt1179
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc5049.txt b/doc/rfc/rfc5049.txt
new file mode 100644
index 0000000..42d963a
--- /dev/null
+++ b/doc/rfc/rfc5049.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group C. Bormann
+Request for Comments: 5049 Universitaet Bremen TZI
+Category: Standards Track Z. Liu
+ Nokia Research Center
+ R. Price
+ EADS Defence and Security Systems Limited
+ G. Camarillo, Ed.
+ Ericsson
+ December 2007
+
+
+ Applying Signaling Compression (SigComp)
+ to the Session Initiation Protocol (SIP)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document describes some specifics that apply when Signaling
+ Compression (SigComp) is applied to the Session Initiation Protocol
+ (SIP), such as default minimum values of SigComp parameters,
+ compartment and state management, and a few issues on SigComp over
+ TCP. Any implementation of SigComp for use with SIP must conform to
+ this document and SigComp, and in addition, support the SIP and
+ Session Description Protocol (SDP) static dictionary.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et al. Standards Track [Page 1]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. Compliance with This Specification ..............................3
+ 4. Minimum Values of SigComp Parameters for SIP/SigComp ............3
+ 4.1. decompression_memory_size (DMS) for SIP/SigComp ............4
+ 4.2. state_memory_size (SMS) for SIP/SigComp ....................4
+ 4.3. cycles_per_bit (CPB) for SIP/SigComp .......................5
+ 4.4. SigComp_version (SV) for SIP/SigComp .......................5
+ 4.5. locally available state (LAS) for SIP/SigComp ..............5
+ 5. Delimiting SIP Messages and SigComp Messages on the Same Port ...5
+ 6. Continuous Mode over TCP ........................................6
+ 7. Too-Large SIP Messages ..........................................7
+ 8. SIP Retransmissions .............................................7
+ 9. Compartment and State Management for SIP/SigComp ................7
+ 9.1. Remote Application Identification ..........................8
+ 9.2. Identifier Comparison Rules ...............................10
+ 9.3. Compartment Opening and Closure ...........................11
+ 9.4. Lack of a Compartment .....................................13
+ 10. Recommendations for Network Administrators ....................13
+ 11. Private Agreements ............................................14
+ 12. Backwards Compatibility .......................................14
+ 13. Interactions with Transport Layer Security (TLS) ..............14
+ 14. Example .......................................................15
+ 15. Security Considerations .......................................17
+ 16. IANA Considerations ...........................................17
+ 17. Acknowledgements ..............................................17
+ 18. References ....................................................18
+ 18.1. Normative References .....................................18
+ 18.2. Informative References ...................................19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et al. Standards Track [Page 2]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+1. Introduction
+
+ SigComp [RFC3320] is a solution for compressing messages generated by
+ application protocols. Although its primary driver is to compress
+ SIP [RFC3261] messages, the solution itself has been intentionally
+ designed to be application agnostic so that it can be applied to any
+ application protocol; this is denoted as ANY/SigComp. Consequently,
+ many application-dependent specifics are left out of the base
+ standard. It is intended that a separate specification be used to
+ describe those specifics when SigComp is applied to a particular
+ application protocol.
+
+ This document binds SigComp and SIP; this is denoted as SIP/SigComp.
+
+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 [RFC2119].
+
+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
+ implementing SigComp, SigComp defines a few parameters to describe
+ SigComp behavior (see Section 3.3 of [RFC3320]). For each parameter,
+ [RFC3320] specifies a minimum value that any SigComp endpoint MUST
+ support for ANY/SigComp. Those minimum values were determined with
+ the consideration of all imaginable devices in which SigComp may be
+ implemented. Scalability was also considered as a key factor.
+
+ However, some of the minimum values specified in [RFC3320] are too
+ small to allow good performance for SIP message compression.
+ Therefore, they are increased for SIP/SigComp as specified in the
+ following sections. For completeness, those parameters that are the
+ same for SIP/SigComp as they are for ANY/SigComp are also listed.
+
+ The new minimum values are specific to SIP/SigComp and, thus, do not
+ apply to any other application protocols. A SIP/SigComp endpoint MAY
+ offer additional resources over and above the minimum values
+
+
+
+
+Bormann, et al. Standards Track [Page 3]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ specified in this document if available; these resources can be
+ advertised to remote endpoints as described in Section 9.4.9 of
+ [RFC3320].
+
+4.1. decompression_memory_size (DMS) for SIP/SigComp
+
+
+ Minimum value for ANY/SigComp: 2048 bytes, as specified in Section
+ 3.3.1 of [RFC3320].
+
+ Minimum value for SIP/SigComp: 8192 bytes.
+
+ Reason: a DMS of 2048 bytes is too small for SIP message compression
+ as it seriously limits the compression ratio and even makes
+ compression impossible for certain messages. For example, the
+ condition set by [RFC3320] for SigComp over UDP means: C + 2*B + R +
+ 2*S + 128 < DMS (each term is described below). Therefore, if DMS is
+ too small, at least one of C, B, R, or S will be severely restricted.
+ On the other hand, DMS is memory that is only temporarily needed
+ during decompression of a SigComp message (the memory can be
+ reclaimed when the message has been decompressed). Therefore, a
+ requirement of 8 KB should not cause any problems for an endpoint
+ that already implements SIP, SigComp, and applications that use SIP.
+
+ C size of compressed application message, depending on R
+ B size of bytecode. Note: two copies -- one as part of the
+ SigComp message and one in UDVM (Universal Decompressor Virtual
+ Machine) memory.
+ R size of circular buffer in UDVM memory
+ S any additional state uploaded other than that created from the
+ content of the circular buffer at the end of decompression
+ (similar to B, two copies of S are needed)
+ 128 the smallest address in UDVM memory to copy bytecode to
+
+4.2. state_memory_size (SMS) for SIP/SigComp
+
+ Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in
+ Section 3.3.1 of [RFC3320].
+
+ Minimum value for SIP/SigComp: 2048 bytes.
+
+ 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
+ of whether the remote endpoint will have enough memory to store such
+ a state. A non-zero SMS obviously requires the SIP/SigComp
+ implementation to keep state. Based on the observation that there is
+ little gain from stateless SigComp compression, the assumption is
+ that purely stateless SIP implementations are unlikely to provide a
+
+
+
+Bormann, et al. Standards Track [Page 4]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ SigComp function. Stateful implementations should have little
+ problem to keep 2K additional state for each compartment (see Section
+ 9).
+
+ Note: SMS is a parameter that applies to each individual compartment.
+ An endpoint MAY offer different SMS values for different compartments
+ as long as the SMS value is not less than 2048 bytes.
+
+4.3. cycles_per_bit (CPB) for SIP/SigComp
+
+ Minimum value for ANY/SigComp: 16, as specified in Section 3.3.1 of
+ [RFC3320].
+
+ Minimum value for SIP/SigComp: 16 (same as above).
+
+4.4. SigComp_version (SV) for SIP/SigComp
+
+ For ANY/SigComp: 0x01, as specified in Section 3.3.2 of [RFC3320].
+
+ For SIP/SigComp: >= 0x02 (at least SigComp + NACK).
+
+ Note that this implies that the provisions of [RFC4077] apply. That
+ is, decompression failures result in SigComp NACK messages sent back
+ to the originating compressor. It also implies that the compressor
+ need not make use of the methods detailed in Section 2.4 of [RFC4077]
+ (Detecting Support for NACK); for example, it can use optimistic
+ compression methods right from the outset.
+
+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 SIP/SigComp: the SIP/SDP static dictionary as defined
+ in [RFC3485].
+
+ 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
+ endpoint, it is possible to allow both SigComp messages and 'vanilla'
+ SIP messages (i.e., uncompressed SIP messages with no SigComp header)
+ to arrive on the same port.
+
+ For a message-based transport such as UDP or Stream Control
+ Transmission Protocol (SCTP), distinguishing between SigComp and
+ non-SigComp messages can be done per message. The receiving endpoint
+
+
+
+Bormann, et al. Standards Track [Page 5]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ checks the first octet of the UDP/SCTP payload to determine whether
+ the message has been compressed using SigComp. If the MSBs (Most
+ Significant Bits) of the octet are "11111", then the message is
+ considered to be a SigComp message and is parsed as per [RFC3320].
+ If the MSBs of the octet take any other value, then the message is
+ assumed to be an uncompressed SIP message, and it is passed directly
+ to the application with no further effect on the SigComp layer.
+
+ 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 it 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
+ single TCP connection. If the TCP connection is used to carry
+ SigComp messages, then all messages sent over the connection MUST
+ have a SigComp header and be delimited by the use of 0xFFFF, as
+ described in [RFC3320].
+
+ Section 11 of [RFC4896] details a simple set of bytecodes, intended
+ to be "well-known", that implement a null decompression algorithm.
+ These bytecodes effectively allow SigComp peers to send selected
+ SigComp messages with uncompressed data. If a SIP implementation has
+ reason to send both compressed and uncompressed SIP messages on a
+ single TCP connection, the compressor can be instructed to use these
+ bytecodes to send uncompressed SIP messages that are also valid
+ SigComp messages.
+
+6. Continuous Mode over TCP
+
+ Continuous Mode is a special feature of SigComp, which is designed to
+ improve the overall compression ratio for long-lived connections.
+ Its use requires pre-agreement between the SigComp compressor and
+ decompressor. Continuous mode is not used with SIP/SigComp.
+
+ Reason: continuous mode requires the transport itself to provide a
+ certain level of protection against denial-of-service attacks. TCP
+ alone is not considered to provide enough protection.
+
+
+
+
+
+
+Bormann, et al. Standards Track [Page 6]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+7. Too-Large SIP Messages
+
+ SigComp does not support the compression of messages larger than 64k.
+ Therefore, if a SIP application sending compressed SIP messages to
+ another SIP application over a transport connection (e.g., a TCP
+ connection) needs to send a SIP message larger than 64k, the SIP
+ application MUST NOT send the message over the same TCP connection.
+ The SIP application SHOULD send the message over a different
+ transport connection (to do this, the SIP application may need to
+ establish a new transport connection).
+
+8. SIP Retransmissions
+
+ When SIP messages are retransmitted, they need to be re-compressed,
+ taking into account any SigComp states that may have been created or
+ invalidated since the previous transmission. Implementations MUST
+ NOT cache the result of compressing the message and retransmit such a
+ cached result.
+
+ The reason for this behavior is that it is impossible to know whether
+ the failure causing the retransmission occurred on the message being
+ retransmitted or on the response to that message. If the response
+ was lost, any state changes effected by the first instance of the
+ retransmitted message would already have taken place. If these state
+ changes removed a state that the previously transmitted message
+ relied upon, then retransmission of the same compressed message would
+ lead to a decompression failure.
+
+ Note that a SIP retransmission may be caused by the original message
+ or its response being lost by a decompression failure. In this case,
+ a NACK will have been sent by the decompressor to the compressor,
+ which may use the information in this NACK message to adjust its
+ compression parameters. Note that, on an unreliable transport, such
+ a NACK message may still be lost, so if a compressor used some form
+ of optimistic compression, it MAY want to switch to a method less
+ likely to cause any form of decompression failure when compressing a
+ SIP retransmission.
+
+9. Compartment and State Management for SIP/SigComp
+
+ An application exchanging compressed traffic with a remote
+ application has a compartment that contains state information needed
+ to compress outgoing messages and to decompress incoming messages.
+ To increase the compression efficiency, the application must assign
+ distinct compartments to distinct remote applications.
+
+
+
+
+
+
+Bormann, et al. Standards Track [Page 7]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+9.1. Remote Application Identification
+
+ SIP/SigComp applications identify remote applications by their SIP/
+ SigComp identifiers. Each SIP/SigComp application MUST have a SIP/
+ SigComp identifier URN (Uniform Resource Name) that uniquely
+ identifies the application. Usage of a URN provides a persistent and
+ unique name for the SIP/SigComp identifier. It also provides an easy
+ way to guarantee uniqueness. This URN MUST be persistent as long as
+ the application stores compartment state related to other SIP/SigComp
+ applications.
+
+ A SIP/SigComp application SHOULD use a UUID (Universally Unique
+ IDentifier) URN as its SIP/SigComp identifier, due to the
+ difficulties in equality comparisons for other kinds of URNs. The
+ UUID URN [RFC4122] allows for non-centralized computation of a URN
+ based on time, unique names (such as a Media Access Control (MAC)
+ address), or a random number generator. If a URN scheme other than
+ UUID is used, the URN MUST be selected such that the application can
+ be certain that no other SIP/SigComp application would choose the
+ same URN value.
+
+ Note that the definition of SIP/SigComp identifier is similar to the
+ definition of instance identifier in [OUTBOUND]. One difference is
+ that instance identifiers are only required to be unique within their
+ AoR (Address of Record) while SIP/SigComp identifiers are required to
+ be globally unique.
+
+ Even if instance identifiers are only required to be unique within
+ their AoR, devices may choose to generate globally unique instance
+ identifiers. A device with a globally unique instance identifier
+ SHOULD use its instance identifier as its SIP/SigComp identifier.
+
+ Note: Using the same value for an entity's instance and
+ SIP/SigComp identifiers improves the compression ratio of header
+ fields that carry both identifiers (e.g., a Contact header field
+ in a REGISTER request).
+
+ Server farms that share SIP/SigComp state across servers MUST use the
+ same SIP/SigComp identifier for all their servers.
+
+ SIP/SigComp identifiers are carried in the 'sigcomp-id' SIP URI
+ (Uniform Resource Identifier) or Via header field parameter. The
+ 'sigcomp-id' SIP URI parameter is a 'uri-parameter', as defined by
+ the SIP ABNF (Augmented Backus-Naur Form, Section 25.1 of [RFC3261]).
+ The following is its ABNF [RFC4234]:
+
+ uri-sip-sigcomp-id = "sigcomp-id=" 1*paramchar
+
+
+
+
+Bormann, et al. Standards Track [Page 8]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ The SIP URI 'sigcomp-id' parameter MUST contain a URN [RFC2141].
+
+ The Via 'sigcomp-id' parameter is a 'via-extension', as defined by
+ the SIP ABNF (Section 25.1 of [RFC3261]). The following is its ABNF
+ [RFC4234]:
+
+ via-sip-sigcomp-id = "sigcomp-id" EQUAL
+ LDQUOT *( qdtext / quoted-pair ) RDQUOT
+
+ The Via 'sigcomp-id' parameter MUST contain a URN [RFC2141].
+
+ The following is an example of a 'sigcomp-id' SIP URI parameter:
+
+ sigcomp-id=urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128
+
+ The following is an example of a Via header field with a 'sigcomp-id'
+ parameter:
+
+ Via: SIP/2.0/UDP server1.example.com:5060
+ ;branch=z9hG4bK87a7
+ ;comp=sigcomp
+ ;sigcomp-id="urn:uuid:0C67446E-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:uuid:2e5fdc76-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
+ follows:
+
+ Outgoing requests: the remote application identifier is the SIP/
+ SigComp identifier of the URI to which the request is sent. If
+ the URI does not contain a SIP/SigComp identifier, the remote
+
+
+
+Bormann, et al. Standards Track [Page 9]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ application identifier is the IP address plus port of the datagram
+ carrying the request for connectionless transport protocols, and
+ the transport connection (e.g., a TCP connection) carrying the
+ request for connection-oriented transport protocols (this is to
+ support legacy SIP/SigComp applications).
+
+ Incoming responses: the remote application identifier is the same as
+ that of the previously sent request that initiated the transaction
+ to which the response belongs.
+
+ Incoming requests: the remote application identifier is the SIP/
+ SigComp identifier of the top-most Via entry. If the Via header
+ field does not contain a SIP/SigComp identifier, the remote
+ application identifier is the source IP address plus port of the
+ datagram carrying the request for connectionless transport
+ protocols, and the transport connection (e.g., a TCP connection)
+ carrying the request for connection-oriented transport protocols
+ (this is to support legacy SIP/SigComp applications).
+
+ Outgoing responses: the remote application identifier is the same as
+ that of the previously received request that initiated the
+ transaction to which the response belongs. Note that, due to
+ standard SIP Via header field processing, this identifier will be
+ present in the top-most Via entry in such responses (as long as it
+ was present in the top-most Via entry of the previously received
+ request).
+
+ A SIP/SigComp application placing its URI with the 'comp=sigcomp'
+ parameter in a header field MUST add a 'sigcomp-id' parameter with
+ its SIP/SigComp identifier to that URI.
+
+ A SIP/SigComp application generating its own Via entry containing the
+ 'comp=sigcomp' parameter MUST add a 'sigcomp-id' parameter with its
+ SIP/SigComp identifier to that Via entry.
+
+ A given remote application identifier is mapped to a particular
+ SigComp compartment ID following the rules given in Section 9.3.
+
+9.2. Identifier Comparison Rules
+
+ Equality comparisons between SIP/SigComp identifiers are performed
+ using the rules for URN equality that are specific to the scheme in
+ the URN. If the element performing the comparisons does not
+ understand the URN scheme, it performs the comparisons using the
+ lexical equality rules defined in RFC 2141 [RFC2141]. Lexical
+ equality may result in two URNs being considered unequal when they
+ are actually equal. In this specific usage of URNs, the only element
+ that provides the URN is the SIP/SigComp application identified by
+
+
+
+Bormann, et al. Standards Track [Page 10]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ that URN. As a result, the SIP/SigComp application SHOULD provide
+ lexically equivalent URNs in each registration it generates. This is
+ likely to be normal behavior in any case; applications are not likely
+ to modify the value of their SIP/SigComp identifiers so that they
+ remain functionally equivalent yet lexicographically different from
+ previous identifiers.
+
+9.3. Compartment Opening and Closure
+
+ 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
+ registration state. Compartments are opened at SIP registration time
+ and are typically closed when the registration expires or is
+ canceled.
+
+ Note: Linking the lifetime of SIP/SigComp compartments to
+ registration state limits the applicability of this specification.
+ In particular, SIP user agents that do not register but, for
+ example, only handle PUBLISH or SUBSCRIBE/NOTIFY transactions are
+ not able create SIP/SigComp compartments following this
+ specification. Previous revisions of this specification also
+ defined compartments valid during a SIP transaction or a SIP
+ dialog. Those compartments covered all possible SIP entities,
+ including those that do not handle REGISTER transactions.
+ However, it was decided to eliminate those types of compartments
+ because the complexity they introduced (e.g., edge proxy servers
+ were required to keep dialog state) was higher than the benefits
+ they brought in most deployment scenarios.
+
+ Usually, any states created during the lifetime of a compartment will
+ be "logically" deleted when the compartment is closed. As described
+ in Section 6.2 of [RFC3320], a logical deletion can become a physical
+ deletion only when no compartment continues to exist that created the
+ (same) state.
+
+ A SigComp endpoint may offer to keep a state created upon request
+ from a SigComp peer endpoint beyond the default lifetime of a
+ compartment (i.e., beyond the duration of its associated
+ registration). This may be used to improve compression efficiency of
+ subsequent SIP messages generated by the same remote application at
+ the SigComp peer endpoint. To indicate that such state will continue
+ to be available, the SigComp endpoint can inform its peer SigComp
+ endpoint by announcing the (partial) state ID in the returned SigComp
+ parameters at the end of the registration that was supposed to limit
+ the lifetime of the SigComp state. That signals the state will be
+ maintained. The mandatory support for the SigComp Negative
+
+
+
+
+
+Bormann, et al. Standards Track [Page 11]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ Acknowledgement (NACK) Mechanism [RFC4077] in SIP/SigComp ensures
+ that it is possible to recover from synchronization errors regarding
+ compartment lifetimes.
+
+ As an operational concern, bugs in the compartment management
+ implementation are likely to lead to sporadic, hard-to-diagnose
+ failures. Decompressors may therefore want to cache old state and,
+ if still available, allow access while logging diagnostic
+ information. Both compressors and decompressors use the SigComp
+ Negative Acknowledgement (NACK) Mechanism [RFC4077] to recover from
+ situations where such old state may no longer be available.
+
+ A REGISTER transaction causes an application to open a new
+ compartment to be valid for the duration of the registration
+ established by the REGISTER transaction.
+
+ 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
+ its next hop) SHOULD open a compartment for the request's remote
+ application identifier. A SIP application that receives a compressed
+ 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
+ application identifier.
+
+ These compartments MAY be closed if the REGISTER request is responded
+ with a non-2xx final response, or when the registration expires or is
+ canceled. However, applications MAY also choose to keep these
+ compartments open for a longer period of time, as discussed
+ previously. For a given successful registration, applications SHOULD
+ NOT close their associated compartments until the registration is
+ over.
+
+ Note: A SIP network can be configured so that regular SIP traffic
+ to and from a user agent traverses a different set of proxies than
+ the initial REGISTER transaction. The path the REGISTER
+ transaction follows is typically determined by configuration data.
+ The path subsequent requests traverse is determined by the Path
+ [RFC3327] and the Service-Route [RFC3308] header fields in the
+ REGISTER transaction and by the Record-Route and the Route header
+ fields in dialog-creating transactions. Previous revisions of
+ this document supported the use of different paths for different
+ types of traffic. However, for simplicity reasons, this document
+ now assumes that networks using compression will be configured so
+ that subsequent requests follow the same path as the initial
+ REGISTER transaction in order to achieve the best possible
+ compression. Section 10 provides network administrators with
+ recommendations so that they can configure the networks properly.
+
+
+
+
+Bormann, et al. Standards Track [Page 12]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ If, following the rules above, a SIP application is supposed to open
+ a compartment for a remote application identifier for which it
+ already has a compartment (e.g., the SIP application registers
+ towards a second registrar using the same edge proxy server as for
+ its registration towards its first registrar), the SIP application
+ MUST use the already existing compartment. That is, the SIP
+ application MUST NOT open a new compartment.
+
+9.4. Lack of a Compartment
+
+ The use of stateless compression (i.e., compression without a
+ compartment) is not typically worthwhile and may even result in
+ message expansion. Therefore, if a SIP application does not have a
+ compartment for a message it needs to send, it MAY choose not to
+ compress it even in the presence of the 'comp=sigcomp' parameter.
+ Section 5 describes how a SIP application can send compressed and
+ uncompressed messages over the same TCP connection. Note that RFC
+ 3486 [RFC3486] states the following:
+
+ "If the next-hop URI contains the parameter comp=sigcomp, the
+ client SHOULD compress the request using SigComp".
+
+ Experience since RFC 3486 [RFC3486] was written has shown that
+ stateless compression is, in most cases, not worthwhile. That is why
+ it is not recommended to use it any longer.
+
+10. Recommendations for Network Administrators
+
+ Network administrators can configure their networks so that the
+ compression efficiency achieved is increased. The following
+ recommendations help network administrators perform their task.
+
+ For a given user agent, the route sets for incoming requests (created
+ by a Path header field) and for outgoing requests (created by a
+ Service-Route header field) are typically the same. However,
+ 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
+ that registrars are configured so that proxies performing SigComp
+ compression appear in both routes.
+
+ The routes described previously apply to requests sent outside a
+ dialog. Requests inside a dialog follow a route constructed using
+ Record-Route header fields. It is RECOMMENDED that the proxies
+ performing SigComp that are in the route for requests outside a
+ dialog are configured to place themselves (by inserting themselves in
+ the Record-Route header fields) in the routes used for requests
+ inside dialogs.
+
+
+
+
+Bormann, et al. Standards Track [Page 13]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ When a user agent's registration expires, proxy servers performing
+ compression may close their associated SIP/SigComp compartment. If
+ the user agent is involved in a dialog that was established before
+ the registration expired, subsequent requests within the dialog may
+ not be compressed any longer. In order to avoid this situation, it
+ is RECOMMENDED that user agents are registered as long as they are
+ involved in a dialog.
+
+11. Private Agreements
+
+ SIP/SigComp implementations that are subject to private agreements
+ MAY deviate from this specification, if the private agreements
+ unambiguously specify so. Plausible candidates for such deviations
+ include:
+
+ o Minimum values (Section 4).
+ o Use of continuous mode (Section 6).
+ o Compartment definition (Section 9).
+
+12. Backwards Compatibility
+
+ SigComp has a number of parameters that can be configured per
+ endpoint. This document specifies a profile for SigComp when used
+ for SIP compression that further constrains the range that some of
+ these parameters may take. Examples of this are Decompressor Memory
+ Size, State Memory Size, and SigComp Version (support for NACK).
+ Additionally, this document specifies how SIP/SigComp applications
+ should perform compartment mapping.
+
+ When this document was written, there were already a few existing
+ SIP/SigComp deployments. The rules in this document have been
+ designed to maximize interoperability with those legacy SIP/SigComp
+ implementations. Nevertheless, implementers should be aware that
+ legacy SIP/SigComp implementations may not conform to this
+ specification. Examples of problems with legacy applications would
+ be smaller DMS than mandated in this document, lack of NACK support,
+ or a different compartment mapping.
+
+13. Interactions with Transport Layer Security (TLS)
+
+ Endpoints exchanging SIP traffic over a TLS [RFC4346] connection can
+ use the compression provided by TLS. Two endpoints exchanging SIP/
+ SigComp traffic over a TLS connection that provides compression need
+ to first compress the SIP messages using SigComp and then pass them
+ to the TLS layer, which will compress them again. When receiving
+ data, the processing order is reversed.
+
+
+
+
+
+Bormann, et al. Standards Track [Page 14]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ However, compressing messages this way twice does not typically bring
+ significant gains. Once a message is compressed using SigComp, TLS
+ is not usually able to compress it further. Therefore, TLS will
+ normally only be able to compress SigComp code sent between
+ compressor and decompressor. Since the gain of having SigComp code
+ compressed should be minimal in most cases, it is NOT RECOMMENDED to
+ use TLS compression when SigComp compression is being used.
+
+14. Example
+
+ Figure 1 shows an example message flow where the user agent and the
+ outbound proxy exchange compressed SIP traffic. Compressed messages
+ are marked with a (c).
+
+ User Agent Outbound Proxy Registrar
+
+ |(1) REGISTER (c) | |
+ |---------------->| |
+ | |(2) REGISTER |
+ | |---------------->|
+ | |(3) 200 OK |
+ | |<----------------|
+ |(4) 200 OK (c) | |
+ |<----------------| |
+ |(5) INVITE (c) | |
+ |---------------->| |
+ | |(6) INVITE |
+ | |------------------------------>
+ | |(7) 200 OK |
+ | |<------------------------------
+ |(8) 200 OK (c) | |
+ |<----------------| |
+ |(9) ACK (c) | |
+ |---------------->| |
+ | |(10) ACK |
+ | |------------------------------>
+ |(11) BYE (c) | |
+ |---------------->| |
+ | |(12) BYE |
+ | |------------------------------>
+ | |(13) 200 OK |
+ | |<------------------------------
+ |(14) 200 OK (c) | |
+ |<----------------| |
+
+ Figure 1: Example Message Flow
+
+
+
+
+
+Bormann, et al. Standards Track [Page 15]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ The user agent in Figure 1 is initially configured (e.g., using the
+ SIP configuration framework [CONFIG]) with the URI of its outbound
+ proxy. That URI contains the outbound proxy's SIP/SigComp
+ identifier, referred to as 'Outbound-id', in a 'sigcomp-id'
+ parameter.
+
+ 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-id'. This compartment will be valid for the duration of
+ the registration, at least.
+
+ On receiving this REGISTER request (1), the outbound proxy opens a
+ new compartment for the SIP/SigComp identifier that appears in the
+ 'sigcomp-id' parameter of the top-most Via entry. This identifier,
+ which is the user agent's SIP/SigComp identifier, is referred to as
+ 'UA-id'. The compartment opened by the outbound proxy will be valid
+ for the duration of the registration, at least. The outbound proxy
+ adds a Path header field with its own URI, which contains the
+ 'Outbound-id' SIP/SigComp identifier, to the REGISTER request and
+ relays it to the registrar (2).
+
+ When the registrar receives the REGISTER request (2), it constructs
+ the route future incoming requests (to the user agent) will follow
+ using the Contact and the Path header fields. Future incoming
+ requests will traverse the outbound proxy before reaching the user
+ agent.
+
+ The registrar also constructs the route future outgoing requests
+ (from the user agent) will follow and places it in a Service-Route
+ header field in a 200 (OK) response (3). Future outgoing requests
+ will always traverse the outbound proxy. The registrar has ensured
+ that the outbound proxy performing compression handles both incoming
+ and outgoing requests.
+
+ 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'
+ matches that of the compartment created before. Therefore, the
+ outbound proxy uses that compartment to compress it and relay it to
+ the user agent.
+
+ 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
+ requests. The Service-Route header field contains the outbound
+ proxy's URI, which contains the 'Outbound-id' SIP/SigComp identifier.
+
+ At a later point, the user agent needs to send an INVITE request (5).
+ According to the Service-Route header field received previously, the
+ user agent sends the INVITE request (5) to the outbound proxy's URI.
+
+
+
+Bormann, et al. Standards Track [Page 16]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ Since this URI's SIP/SigComp identifier 'Outbound-id' matches that of
+ the compartment created before, this compartment is used to compress
+ the INVITE request.
+
+ On receiving the INVITE request (5), the outbound proxy Record Routes
+ and relays the INVITE request (6) forward. The outbound proxy Record
+ Routes to ensure that all SIP messages related to this new dialog are
+ routed through the outbound proxy.
+
+ Finally, the dialog is terminated by a BYE transaction (11) that also
+ traverses the outbound proxy.
+
+15. Security Considerations
+
+ The same security considerations as described in [RFC3320] apply to
+ this document. Note that keeping SigComp states longer than the
+ duration of a SIP dialog should not pose new security risks because
+ the state has been allowed to be created in the first place.
+
+16. IANA Considerations
+
+ The IANA has registered the 'sigcomp-id' Via header field parameter,
+ which is defined in Section 9.1, under the Header Field Parameters
+ and Parameter Values subregistry within the SIP Parameters registry:
+
+ Predefined
+ Header Field Parameter Name Values Reference
+ ---------------------------- --------------- --------- ---------
+ Via sigcomp-id No [RFC5049]
+
+ The IANA has registered the 'sigcomp-id' SIP URI parameter, which is
+ defined in Section 9.1, under the SIP/SIPS URI Parameters subregistry
+ within the SIP Parameters registry:
+
+ Parameter Name Predefined Values Reference
+ -------------- ----------------- ---------
+ sigcomp-id No [RFC5049]
+
+17. Acknowledgements
+
+ The authors would like to thank the following people for their
+ comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West,
+ Pekka Pessi, Robert Sugar, Jonathan Rosenberg, Robert Sparks, Juergen
+ Schoenwaelder, and Tuukka Karvonen. Abigail Surtees and Adam Roach
+ performed thorough reviews of this document.
+
+
+
+
+
+
+Bormann, et al. Standards Track [Page 17]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+18. References
+
+18.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+ [RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer
+ Two Tunneling Protocol (L2TP) Differentiated Services
+ Extension", RFC 3308, November 2002.
+
+ [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
+ Liu, Z., and J. Rosenberg, "Signaling Compression
+ (SigComp)", RFC 3320, January 2003.
+
+ [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
+ (SIP) Extension Header Field for Registering Non-Adjacent
+ Contacts", RFC 3327, December 2002.
+
+ [RFC3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A.
+ Roach, "The Session Initiation Protocol (SIP) and Session
+ Description Protocol (SDP) Static Dictionary for Signaling
+ Compression (SigComp)", RFC 3485, February 2003.
+
+ [RFC3486] Camarillo, G., "Compressing the Session Initiation
+ Protocol (SIP)", RFC 3486, February 2003.
+
+ [RFC4077] Roach, A., "A Negative Acknowledgement Mechanism for
+ Signaling Compression", RFC 4077, May 2005.
+
+ [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
+ Unique IDentifier (UUID) URN Namespace", RFC 4122, July
+ 2005.
+
+ [RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+
+
+
+
+Bormann, et al. Standards Track [Page 18]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+ [RFC4896] Surtees, A., West, M., and A. Roach, "Signaling
+ Compression (SigComp) Corrections and Clarifications", RFC
+ 4896, June 2007.
+
+18.2. Informative References
+
+ [CONFIG] Petrie, D. and S. Channabasappa, "A Framework for Session
+ Initiation Protocol User Agent Profile Delivery", Work in
+ Progress, June 2007.
+
+ [OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated
+ Connections in the Session Initiation Protocol (SIP)",
+ Work in Progress, March 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et al. Standards Track [Page 19]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+Authors' Addresses
+
+ Carsten Bormann
+ Universitaet Bremen TZI
+ Postfach 330440
+ Bremen D-28334
+ Germany
+
+ Phone: +49 421 218 63921
+ Fax: +49 421 218 7000
+ EMail: cabo@tzi.org
+
+
+ Zhigang Liu
+ Nokia Research Center
+ 955 Page Mill Road
+ Palo Alto, CA 94304
+ USA
+
+ Phone: +1 650 796 4578
+ EMail: zhigang.c.liu@nokia.com
+
+
+ Richard Price
+ EADS Defence and Security Systems Limited
+ Meadows Road
+ Queensway Meadows
+ Newport, Gwent NP19 4SS
+
+ Phone: +44 (0)1633 637874
+ EMail: richard.price@eads.com
+
+
+ Gonzalo Camarillo (editor)
+ Ericsson
+ Hirsalantie 11
+ Jorvas 02420
+ Finland
+
+ EMail: Gonzalo.Camarillo@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et al. Standards Track [Page 20]
+
+RFC 5049 Applying SigComp to SIP December 2007
+
+
+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
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Bormann, et al. Standards Track [Page 21]
+