Network Working Group G. Camarillo Request for Comments: 3486 Ericsson Category: Standards Track February 2003 Compressing 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.
AbstractThis document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity. 1. Introduction ............................................... 2 2. Overview of operation ...................................... 3 3. SigComp implementations for SIP ............................ 3 4. Sending a Request to a Server .............................. 3 4.1 Obtaining a SIP or SIPS URI with comp=sigcomp ........ 4 5. Sending a Response to a Client ............................. 5 6. Double Record-Routing ...................................... 6 7. Error Situations ........................................... 6 8. Augmented BNF .............................................. 7 9. Example .................................................... 7 10. Security Considerations .................................... 10 11. IANA Considerations ........................................ 10 12. Acknowledgements............................................ 10 13. Normative References ....................................... 10 14. Informative References ..................................... 11 15. Author's Address............................................ 11 16. Full Copyright Statement.................................... 12
1] client sending a request to a SIP server typically performs a DNS lookup for the domain name of the server. When NAPTR  or SRV  records are available for the server, the client can specify the type of service it wants. The service in this context is the transport protocol to be used by SIP (e.g., UDP, TCP or SCTP). A SIP server that supports, for instance, three different transport protocols, will have three different DNS entries. Since it is foreseen that the number of transport protocols supported by a particular application layer protocol is not going to grow dramatically, having a DNS entry per transport seems like a scalable enough solution. However, sometimes it is necessary to include new layers between the transport protocol and the application layer protocol. Examples of these layers are transport layer security and compression. If DNS was used to discover the availability of these layers for a particular server, the number of DNS entries needed for that server would grow dramatically. A server that, for example, supported TCP and SCTP as transports, TLS for transport security and SigComp for signaling compression, would need the 8 DNS entries listed below: 1. TCP, no security, no compression 2. TCP, no security, SigComp 3. TCP, TLS, no compression 4. TCP, TLS, SigComp 5. SCTP, no security, no compression 6. SCTP, no security, SigComp 7. SCTP, TLS, no compression 8. SCTP, TLS, SigComp It is clear that this way of using DNS is not scalable. Therefore, an application layer mechanism to express support of signalling compression is needed.
Note that for historical reasons both HTTP and SIP use a different port for TLS on top of TCP than for TCP alone, although at present, this solution is not considered scalable any longer. A SIP element that supports compression will need to be prepared to receive compressed and uncompressed messages on the same port. It will perform demultiplexing based on the cookie in the topmost bits of every compressed message. 2]. The presence of comp=sigcomp in a Via header field indicates that the response has to be compressed using SigComp. Therefore, the presence of comp=sigcomp indicates that the SIP entity identified by the URI or by the Via header field supports SigComp and is willing to receive compressed messages. Having comp=sigcomp mean "willingness" as well as "support" allows the receiver of a SIP message to influence the decision of whether or not to use SigComp at a given time. 2].
If the next-hop URI is a SIPS URI, the request SHOULD be compressed before it is passed to the TLS layer. A client MUST NOT send a compressed request to a server if it does not know whether or not the server supports SigComp. Regardless of whether the request is sent compressed or not, if a client would like to receive subsequent requests within the same dialog in the UAS->UAC direction compressed, this client SHOULD add the parameter comp=sigcomp to the URI in the Contact header field if it is a user agent client. If the client is a proxy, it SHOULD add the parameter comp=sigcomp to its URI in the Record-Route header field. If a user agent client sends a compressed request, it SHOULD add the parameter comp=sigcomp to the URI in the Contact header field. If a proxy that Record-Routes sends a compressed request, it SHOULD add comp=sigcomp to its URI in the Record-Route header field. If a client sends a compressed request, it SHOULD add the parameter comp=sigcomp to the topmost entry of the Via header field. If a client does not know whether or not the server supports SigComp, but in case the server supported it, it would like to receive compressed responses, this client SHOULD add the parameter comp=sigcomp to the topmost entry of the Via header field. The request, however, as stated above, will not be compressed. 6]) do not allow to provide the
client with URI parameters. In this case, the client SHOULD send an uncompressed OPTIONS request to its outbound proxy. The outbound proxy can provide an alternative SIP URI with the comp=sigcomp parameter in a Contact header field in a 200 OK response to the OPTIONS. The client can use this URI for subsequent requests that are sent through the same outbound proxy using compression. RFC 3261  does not define how a proxy should respond to an OPTIONS request addressed to itself. It only describes how servers respond to OPTIONS addressed to a particular user. Section 11.2 of RFC 3261 says: Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. We extend this behavior to proxy servers responding to OPTIONS addressed to them. They MAY list a set of alternative URIs to contact the proxy. Note that receiving incoming requests (even initial INVITEs) compressed is not a problem, since user agents can REGISTER a SIP URI with comp=sigcomp in their registrar. All incoming requests for the user will be sent to this SIP URI using compression. Section 9). It looks for the URI of the next upstream (closer to the user agent client) hop in the route set. If this URI contains the parameter comp=sigcomp, the proxy SHOULD add comp=sigcomp to its entry in the Record-Route header field. If this URI does not contain the parameter comp=sigcomp, the proxy SHOULD remove comp=sigcomp (if it is present) from its entry in the Record- Route header field.
The same way, a user agent server SHOULD add comp=sigcomp to the Contact header field of the response if the URI of the next upstream hop in the route set contained the parameter comp=sigcomp.
Section 25.1 of ): compression-param = "comp=" ("sigcomp" / other-compression) other-compression = token The Via compression parameter is a "via-extension", as defined by the SIP ABNF (Section 25.1 of ): via-compression = "comp" EQUAL ("sigcomp" / other-compression) other-compression = token Figure 1 shows an INVITE-200 OK-ACK handshake between a UAC and a UAS through two proxies. Proxy P1 does not Record-Route but proxy P2 does. Both proxies support compression, but they do not use it by default. UAC P1 P2 UAS |(1)INVITE(c) | | | |------------>| (2) INVITE | | | |------------>| (3) INVITE | | | |------------>| | | | (4) 200 OK | | | (5) 200 OK |<------------| |(6)200 OK(c) |<------------| | |<------------| | | | | (7)ACK(c) | | |-------------------------->| (8) ACK | | | |------------>| | | | | | | | | Figure 1: INVITE transaction through two proxies Messages (1), (6) and (7) are compressed (c). We provide a partial description of the messages involved in this call flow below. Only some parts of each message are shown, namely the Method name, the Request-URI and the Via, Route, Record-Route and
Contact header fields. We have not used a correct format for these header fields. We have rather focus on the contents of the header fields and on the presence (or absence) of the "comp=sigcomp" parameter. (1) INVITE UAS Via: UAC;comp=sigcomp Route: P1;comp=sigcomp Contact: UAC;comp=sigcomp P1 is the outbound proxy of the UAC, and it supports SigComp. The UAC is configured to send compressed traffic to P1, and therefore, it compresses the INVITE (1). In addition, the UAC wants to receive future requests and responses for this dialog compressed. Therefore, it adds the comp=Sigcomp parameter to the Via and to the Contact header fields. (2) INVITE UAS Via: P1 Via: UAC;comp=sigcomp Route: P2 Contact: UAC;comp=sigcomp P1 forwards the INVITE (2) to P2. P1 does not use compression by default, so it sends the INVITE uncompressed to P2. (3) INVITE UAS Via: P2 Via: P1 Via: UAC;comp=sigcomp Record-Route: P2 Contact: UAC;comp=sigcomp P2 forwards the INVITE (3) to the UAS. P2 supports compression, but it does not use it by default. Therefore, it sends the INVITE uncompressed. P2 wishes to remain in the signalling path and therefore it Record-Routes. (4) 200 OK Via: P2 Via: P1 Via: UAC;comp=sigcomp Record-Route: P2 Contact: UAS
The UAS generates a 200 OK response and sends it to the host in the topmost Via, which is P2. (5) 200 OK Via: P1 Via: UAC;comp=sigcomp Record-Route: P2;comp=sigcomp Contact: UAS P2 receives the 200 OK response. P2 Record-Routed, so it inspects the Route set for this dialog. For requests from the UAS towards the UAC (the opposite direction than the first INVITE), the next hop will be the Contact header field of the INVITE, because P1 did not Record-Route. That Contact identified the UAC: Contact: UAC;comp=sigcomp Since the UAC wants to receive compressed requests (Contact of the INVITE), P2 assumes that the UAC would also like to send compressed requests (Record-Route of the 200 OK). Therefore, P2 modifies its entry in the Record-Route header field of the 200 OK (5). In the INVITE (3), P2 did not used the comp=sigcomp parameter. Now it adds it in the 200 OK (5). This will allow the UAC sending compressed requests within this dialog. (6) 200 OK Via: UAC;comp=sigcomp Record-Route: P2;comp=sigcomp Contact: UAS P1 sends the 200 OK (6) compressed to the UAC because the Via header field contained the comp=sigcomp parameter. (7) ACK UAS Via: UAC;comp=sigcomp Route: P2;comp=sigcomp Contact: UAC;comp=sigcomp The UAC sends the ACK (7) compressed directly to P2 (P1 did not Record-Route). (8) ACK UAS Via: P2 Via: UAC;comp=sigcomp Contact: UAC;comp=sigcomp P2 sends the ACK (8) uncompressed to the UAS.
http://www.iana.org/assignments/sip-parameters when new signalling compression schemes are published in standards track RFCs. The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication. o Name of the compression scheme. o Token value to be used. The token MAY be of any length, but SHOULD be no more than ten characters long. The only entry in the registry for the time being is: Compression scheme Token Reference --------------------- --------- --------- Signaling Compression sigcomp RFC 3486  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.
 Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z. and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.  Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.  Schulzrinne, H., "DHCP option for SIP servers", Work in Progress.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.