RFC 5049
Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
RFC 5049: Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) 💖
okay bestie, this one is a Standards Track doc from the Network Working Group, dated December 2007. It was written by C. Bormann (Universitaet Bremen TZI), Z. Liu (Nokia Research Center), R. Price (EADS Defence and Security Systems Limited), and G. Camarillo, Ed. (Ericsson). The title block doesn't list anything it obsoletes or updates, so there's no drama there 🫶
Status of This Memo ✨
so this doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🎀 for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited 🌸
Abstract 🦋
this doc describes the specifics that apply when Signaling Compression (SigComp) is used with the Session Initiation Protocol (SIP). that covers default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP 💅 any SigComp implementation used for SIP has to conform to this document and SigComp, and it also has to support the SIP and Session Description Protocol (SDP) static dictionary 🔥
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 ...................................191. Introduction ✨
okay so SigComp [RFC3320] is a solution for squishing down messages that application protocols generate 🗜️ its main job is compressing SIP [RFC3261] messages, but it was intentionally built to be application agnostic so it works with any application protocol. that's called ANY/SigComp. because of that, a lot of the application-specific stuff is left out of the base standard, and a separate spec is supposed to cover those details whenever SigComp gets applied to a particular protocol 🧚
this document is the one that binds SigComp and SIP together, and that's called 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 read as described in RFC 2119 [RFC2119] 📖
3. Compliance with This Specification 💅
any SigComp implementation that's used to compress SIP messages MUST conform to this document, and it also has to conform to [RFC3320] 🫶 on top of that, it must support the SIP/SDP static dictionary from [RFC3485], plus the mechanism for discovering SigComp support at the SIP layer from [RFC3486]. no skipping these, periodt 🔥
4. Minimum Values of SigComp Parameters for SIP/SigComp 🌈
so SigComp has a few parameters that describe how it behaves, so endpoints with all kinds of capabilities can work together (see Section 3.3 of [RFC3320]) 🧩 for each parameter, [RFC3320] sets a minimum value that any SigComp endpoint MUST support for ANY/SigComp. those minimums were picked by thinking about every imaginable device SigComp might end up running on, and scalability was a huge factor too 👑
BUT, some of those [RFC3320] minimums are way too small for good SIP message compression, so they get bumped up for SIP/SigComp in the sections below. for completeness, the parameters that are the same for both SIP/SigComp and ANY/SigComp are listed too 💖
these new minimums are specific to SIP/SigComp, so they don't apply to any other application protocols 🦋 a SIP/SigComp endpoint MAY offer extra resources above and beyond these minimums if it has them, and it can advertise those 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.
the reason is that 2048 bytes is just too small for SIP message compression 😭 it seriously limits the compression ratio and can even make compression impossible for certain messages. for example, the condition [RFC3320] sets for SigComp over UDP is C + 2*B + R + 2*S + 128 < DMS (each term is described below). so if DMS is too small, at least one of C, B, R, or S gets severely restricted 💀
BUT here's the good news: DMS is only memory that's needed temporarily while a SigComp message is being decompressed, and it can be reclaimed once the message has been decompressed. so requiring 8 KB shouldn't cause any problems for an endpoint that already implements SIP, SigComp, and the 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 to4.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.
why does this matter? a non-zero SMS lets an endpoint upload a state in the very first SIP message it sends to a remote endpoint, without having to wonder whether that remote endpoint has enough memory to store the state 🧠 a non-zero SMS also obviously means the SIP/SigComp implementation has to keep state. since there's little gain from stateless SigComp compression, purely stateless SIP implementations are unlikely to provide a SigComp function. stateful implementations should have little trouble keeping 2K of 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).
no change here, bestie, it's the same number on both sides 🤷♀️✨
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).
so this one implies that the provisions of [RFC4077] apply 🔁 which means decompression failures result in SigComp NACK messages being sent back to the originating compressor. it also means the compressor doesn't need to use the methods in Section 2.4 of [RFC4077] (Detecting Support for NACK). for example, it can use optimistic compression methods right from the very start 🚀
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].
and since support for the static SIP/SDP dictionary is mandatory, it doesn't need to be advertised 🙌 iykyk 💜
5. Delimiting SIP Messages and SigComp Messages on the Same Port ✨
okay so, to keep the number of ports a SigComp-aware endpoint needs low 💅, it's possible to let BOTH SigComp messages and "vanilla" SIP messages (uncompressed SIP messages with no SigComp header 🍓) arrive on the same port. main character energy 👑
For a message-based transport like UDP or Stream Control Transmission Protocol (SCTP) 🦋, the receiver can tell them apart per message. It checks the first octet of the UDP/SCTP payload. If the MSBs (Most Significant Bits) of that octet are "11111", the message is a SigComp message and gets parsed as per [RFC3320]. If the MSBs take any other value, the message is assumed to be an uncompressed SIP message, and it gets passed straight to the application with no further effect on the SigComp layer 🙈
For a stream-based transport like TCP 🌊, it's per connection instead. The receiver checks the first octet of the TCP data stream to see whether the stream has been compressed using SigComp. If the MSBs of the octet are "11111", the stream is considered to contain SigComp messages and is parsed as per [RFC3320]. If the MSBs take any other value, the stream is assumed to contain uncompressed SIP messages, and it gets passed directly to the application with no further effect on the SigComp layer.
Heads up: 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 every message sent over it 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, meant to be "well-known", that implement a null decompression algorithm. 🧚 These bytecodes basically let SigComp peers send selected SigComp messages with uncompressed data. If a SIP implementation has a reason to send both compressed and uncompressed SIP messages on a single TCP connection, the compressor can be told 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 SigComp feature designed to improve the overall compression ratio for long-lived connections. 📈 Using it requires the compressor and decompressor to agree on it in advance. 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. 🛡️
7. Too-Large SIP Messages 🐘
SigComp does not support the compression of messages larger than 64k. 🚫 So 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 that message over the same TCP connection. The SIP application SHOULD send it over a different transport connection instead (to do this, it may need to set up 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 that cached result. 🙅♀️
The reason this matters is that it's impossible to know whether the failure causing the retransmission happened on the message being retransmitted or on the response to that message. If the response was lost, any state changes made by the first instance of the retransmitted message would already have happened. If those state changes removed a state that the previously transmitted message relied upon, then retransmitting 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 due to 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. 🧠 On an unreliable transport, though, that NACK message may still get 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 holds the state information needed to compress outgoing messages and decompress incoming messages. To get better compression efficiency, the application needs to give distinct compartments to distinct remote applications. 💖
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. Using a URN gives you a persistent, unique name for the SIP/SigComp identifier, and it's an easy way to guarantee uniqueness. ✅ This URN MUST be persistent for 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, because other kinds of URNs are harder to compare for equality. 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 so the application can be certain that no other SIP/SigComp application would choose the same URN value.
Note that the definition of a SIP/SigComp identifier is similar to the definition of an instance identifier in [OUTBOUND]. The difference is that instance identifiers only need to be unique within their AoR (Address of Record), while SIP/SigComp identifiers need to be globally unique. 🌍
Even though instance identifiers only need 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 in a 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]). Its ABNF is the following [RFC4234]:
uri-sip-sigcomp-id = "sigcomp-id=" 1*paramcharThe 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]). Its ABNF is the following [RFC4234]:
via-sip-sigcomp-id = "sigcomp-id" EQUAL
LDQUOT *( qdtext / quoted-pair ) RDQUOTThe Via 'sigcomp-id' parameter MUST contain a URN [RFC2141].
Here's an example of a 'sigcomp-id' SIP URI parameter 🎀:
sigcomp-id=urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128And here's 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"Last but not least, a REGISTER request that carries 'sigcomp-id' parameters in a Via entry and in the Contact header field. 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: 0SIP messages get matched with remote application identifiers like this 🔍
- Outgoing requests: the remote application identifier is the SIP/SigComp identifier of the URI the request is sent to. If that URI doesn't contain a SIP/SigComp identifier, the remote 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 the response belongs to.
- Incoming requests: the remote application identifier is the SIP/SigComp identifier of the top-most Via entry. If the Via header field doesn't 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 the response belongs to. Note that, thanks to standard SIP Via header field processing, this identifier will be present in the top-most Via entry of 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 🔍
okay so equality checks between SIP/SigComp identifiers follow the URN equality rules that belong to the scheme in the URN 💅 If the element doing the comparing doesn't understand that URN scheme, it falls back to the lexical equality rules from RFC 2141 [RFC2141]. Lexical equality can say two URNs are unequal when they're actually equal 💀 But here's the thing: the only element that ever hands out these URNs is the SIP/SigComp application the URN identifies. So the SIP/SigComp application SHOULD provide lexically equivalent URNs in every registration it generates. ✨ This is probably what happens anyway, since apps aren't likely to change their identifiers into something functionally equivalent but lexically different from the old ones. Nobody's out here making that extra work for themselves 🙈
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 tied to registration state. Compartments get opened at SIP registration time and are typically closed when the registration expires or gets canceled 🎀
Note: tying compartment lifetimes to registration state limits how much this specification applies. SIP user agents that don't register but only handle PUBLISH or SUBSCRIBE/NOTIFY transactions, for example, can't create SIP/SigComp compartments under this spec. Earlier revisions also defined compartments that lasted for a SIP transaction or a SIP dialog. Those covered every SIP entity, including ones that never handle REGISTER transactions. The group still decided to drop those, though, because the complexity they added (e.g., edge proxy servers had to keep dialog state) was higher than the benefits they gave in most deployment scenarios 🌸
Usually, any states created while a compartment exists get "logically" deleted when that compartment closes. As described in Section 6.2 of [RFC3320], a logical deletion only turns into a physical deletion once no compartment that created the (same) state still exists 🧚
A SigComp endpoint may offer to keep a state that a SigComp peer endpoint created upon request, even past the default lifetime of a compartment (i.e., past the duration of its associated registration). This can improve compression efficiency for later SIP messages that the same remote application generates at the SigComp peer endpoint 📈 To say that the state will keep being available, the SigComp endpoint can tell its peer by announcing the (partial) state ID in the returned SigComp parameters at the end of the registration that was supposed to limit the state's lifetime. That's the signal that the state will be maintained 👑 The mandatory support for the SigComp Negative Acknowledgement (NACK) Mechanism [RFC4077] in SIP/SigComp means it's possible to recover from synchronization errors about compartment lifetimes. Super important safety net 🫶
As an operational concern, bugs in the compartment management implementation are likely to cause sporadic, hard-to-diagnose failures 😭 So decompressors may want to cache old state and, if it's 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 that old state might no longer be available 🔥
A REGISTER transaction causes an application to open a new compartment that stays valid for the duration of the registration the REGISTER transaction establishes 💖
A SIP application that needs to send a compressed SIP REGISTER (that's 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 (that's the registrar, or a proxy relaying the REGISTER to its next hop) SHOULD also open a compartment for the request's remote application identifier 🌈
These compartments MAY be closed if the REGISTER request gets a non-2xx final response, or when the registration expires or is canceled. Applications MAY also choose to keep these compartments open for longer, as discussed earlier 🍓 For a given successful registration, applications SHOULD NOT close their associated compartments until the registration is over. Patience, bestie ⏳
Note: a SIP network can be configured so that regular SIP traffic to and from a user agent goes through a different set of proxies than the initial REGISTER transaction. The path the REGISTER transaction follows is usually decided by configuration data. The path that later requests take is determined by the Path [RFC3327] and Service-Route [RFC3308] header fields in the REGISTER transaction, and by the Record-Route and Route header fields in dialog-creating transactions. Earlier revisions of this document supported using different paths for different types of traffic. For simplicity, though, this document now assumes that networks using compression are configured so that subsequent requests follow the same path as the initial REGISTER transaction, which gets the best possible compression 🧠 Section 10 gives network administrators recommendations for setting this up properly.
If, following the rules above, a SIP application is supposed to open a compartment for a remote application identifier that it already has a compartment for (e.g., the SIP application registers with a second registrar through the same edge proxy server it uses for its registration with its first registrar), the SIP application MUST use the already existing compartment. In other words, the SIP application MUST NOT open a new compartment 🙅♀️💜
9.4. Lack of a Compartment 🫧
Stateless compression (i.e., compression without a compartment) usually isn't worth it and can even make messages bigger 😬 So if a SIP application doesn't have a compartment for a message it needs to send, it MAY choose not to compress it, even when the 'comp=sigcomp' parameter is present. Section 5 describes how a SIP application can send compressed and uncompressed messages over the same TCP connection. Note that RFC 3486 [RFC3486] says 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's why it's not recommended to use it anymore 🥹
10. Recommendations for Network Administrators 🛠️
Network administrators can set up their networks so the compression efficiency achieved goes up 📈 The following recommendations help them do that.
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 want, insert proxies in the latter route that don't 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 above apply to requests sent outside a dialog. Requests inside a dialog follow a route built from Record-Route header fields. It is RECOMMENDED that the proxies performing SigComp that sit 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 🦋
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 set up before the registration expired, later requests within that dialog may not be compressed anymore 😭 To avoid this, it is RECOMMENDED that user agents stay registered as long as they're 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:
- Minimum values (Section 4).
- Use of continuous mode (Section 6).
- 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 it's used for SIP compression, and that profile further constrains the range some of these parameters may take. Examples are Decompressor Memory Size, State Memory Size, and SigComp Version (support for NACK) ✨ This document also 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 were designed to maximize interoperability with those legacy SIP/SigComp implementations. Still, implementers should be aware that legacy SIP/SigComp implementations may not conform to this specification. Examples of problems with legacy applications would be a smaller DMS than this document mandates, 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 that TLS provides. Two endpoints exchanging SIP/SigComp traffic over a TLS connection that provides compression need to compress the SIP messages with SigComp first and then pass them to the TLS layer, which will compress them again. When receiving data, the processing order is reversed 🔄
However, compressing messages this way twice doesn't typically bring significant gains. Once a message is compressed with SigComp, TLS usually can't compress it any further. So TLS will normally only be able to compress SigComp code sent between compressor and decompressor. Since the gain from compressing that SigComp code should be minimal in most cases, it is NOT RECOMMENDED to use TLS compression when SigComp compression is being used 💀✨
14. Example ✨
Okay bestie, this is the part where everything finally clicks 🦋 Figure 1 shows a full message flow where the user agent and the outbound proxy trade compressed SIP traffic. Compressed messages get a (c) so you can spot them instantly 💅
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 FlowSo the user agent in Figure 1 gets set up with the URI of its outbound proxy, usually through the SIP configuration framework [CONFIG] 🎀 That URI carries the outbound proxy's SIP/SigComp identifier, called 'Outbound-id', inside a 'sigcomp-id' parameter. Main character energy, the identifier literally rides along in the URI 🌸
When the user agent sends its first REGISTER request (1) to that outbound proxy URI, it opens a brand new compartment for 'Outbound-id'. That compartment stays valid for at least the length of the registration 💖
Now the outbound proxy gets the REGISTER (1) and opens its own new compartment for whatever SIP/SigComp identifier shows up in the 'sigcomp-id' parameter of the top-most Via entry. That identifier is the user agent's own ID, and it's called 'UA-id' ✨ This compartment also sticks around for at least the registration. The proxy then adds a Path header field containing its own URI, which holds the 'Outbound-id' identifier, to the REGISTER request and forwards it to the registrar (2) 🧚
When the registrar gets REGISTER (2), it builds the route that future incoming requests (headed to the user agent) will follow, using the Contact and Path header fields. So incoming traffic goes through the outbound proxy before it reaches the user agent 🫶
The registrar also builds the route that future outgoing requests (coming from the user agent) will follow, and it drops that route into a Service-Route header field in a 200 (OK) response (3). Outgoing requests will always traverse the outbound proxy, and the registrar has made sure the compressing outbound proxy handles both incoming and outgoing requests 👑 Lowkey genius.
When the outbound proxy gets the 200 (OK) response (3), it checks the top-most Via entry. That entry's 'UA-id' matches the compartment it made earlier, so the proxy uses that compartment to compress the response and send it on to the user agent 💅
When the 200 (OK) response (4) lands, the user agent saves the Service-Route header field so it knows how to send future outgoing requests. That header holds the outbound proxy's URI, which includes the 'Outbound-id' identifier 🍓
Later on, the user agent needs to send an INVITE request (5). Following the Service-Route header it got earlier, it sends the INVITE (5) to the outbound proxy's URI 🦋
Since that URI's 'Outbound-id' matches the compartment created at the start, that same compartment is used to compress the INVITE request. It's giving continuity 😭
When the outbound proxy gets the INVITE request (5), it Record Routes and forwards the INVITE request (6). The Record Route is what makes sure every SIP message in this new dialog keeps going through the outbound proxy 🌈
Finally, the dialog wraps up with a BYE transaction (11), which also goes through the outbound proxy. Iconic ending 🎀
15. Security Considerations 🔐
Okay, this part is serious, so listen up 💀 The same security considerations described in [RFC3320] apply to this document. Also, keeping SigComp states around for longer than a SIP dialog lasts should not pose new security risks, because the state was allowed to be created in the first place. Not me saying it's totally fine, but the logic checks out 🙈
16. IANA Considerations 📋
The IANA has registered the 'sigcomp-id' Via header field parameter, which is defined in Section 9.1. It lives under the Header Field Parameters and Parameter Values subregistry inside the SIP Parameters registry, like this:
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Via sigcomp-id No [RFC5049]The IANA has also registered the 'sigcomp-id' SIP URI parameter, which is defined in Section 9.1. This one goes under the SIP/SIPS URI Parameters subregistry inside the SIP Parameters registry 🧚♀️
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
sigcomp-id No [RFC5049]17. Acknowledgements 🫶
The authors want to give a huge shoutout to the people who gave 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 did thorough reviews of this document, so they get their own flowers 🌸
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.
[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.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.comFull 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.
The legal fine print, verbatim because it matters 💅
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 on 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 on the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. Info on how rights work for RFC documents is 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 to get a general license or permission for implementers or users to use these proprietary rights, can be found in the IETF's online IPR repository at:
http://www.ietf.org/iprThe IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at:
ietf-ipr@ietf.org📦 where this page comes from
- ietf: rfc5049 2007-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms