RFC 3486 (rfc3486) - Page 2 of 12
Compressing the Session Initiation Protocol (SIP)
Alternative Format: Original Text Document
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