datatracker.ietf.org
Sign in
Version 5.6.3.p2, 2014-09-29
Report a bug

Compressing the Session Initiation Protocol (SIP)
RFC 3486

Document type: RFC - Proposed Standard (February 2003; No errata)
Updated by RFC 5049
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3486 (Proposed Standard)
Responsible AD: Allison Mankin
Send notices to: <gonzalo.camarillo@ericsson.com>, <dean.willis@softarmor.com>, <rohan@cisco.com>

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

[include full document text]