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.

      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.