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.
Abstract
This 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.
Table of Contents
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
Camarillo Standards Track [Page 1]
RFC 3486 Compressing SIP February 2003
1. Introduction
A SIP [1] client sending a request to a SIP server typically performs
a DNS lookup for the domain name of the server. When NAPTR [4] or
SRV [5] 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.
Camarillo Standards Track [Page 2]
RFC 3486 Compressing SIP February 2003
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. Overview of operation
datatracker.ietf.org