RFC 3486 (rfc3486) - Page 2 of 12

Compressing the Session Initiation Protocol (SIP)

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