[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 5049

Network Working Group                         Zhigang Liu, Editor, Nokia
INTERNET-DRAFT                         Richard Price, Siemens/Roke Manor
Expires: December 17, 2003
                                                           June 17, 2003

Applying Signaling Compression (SigComp) to the Session Initiation
                             Protocol (SIP)

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://

   The list of Internet-Draft Shadow Directories can be accessed at

   This document is a submission of the IETF ROHC WG. Comments should be
   directed to its mailing list, rohc@ietf.org.


   This document describes some specifics when Signaling Compression
   (SigComp) [RFC-3320] is applied to the Session Initiation Protocol
   (SIP) [RFC-3261]. Any SigComp implementation that is used for SIP
   compression must follow this document, in addition to [RFC-3320] and

Liu & Price                                                     [Page 1]

INTERNET-DRAFT           Applying SigComp to SIP           June 17, 2003

1.  Introduction

   SigComp [RFC-3320] is a solution for compressing messages generated
   by application protocols. Although its primary driver is to compress
   SIP messages, the solution itself has been intentionally designed to
   be application agnostic so that it can be applied to any application
   protocols. (This is denoted as ANY/SigComp.) Consequently, many
   application dependent specifics are left out.  It is intended that a
   separate document will be needed to describe those specifics when
   SigComp is applied to a particular application protocol.

   This document binds SigComp and SIP (denoted as SIP/SigComp). Any
   SigComp implementation that is used for SIP message compression must
   follow this document, in addition to [RFC-3320] and [RFC-3485].

   Note: the mechanism of discovering SigComp support at SIP layer is
   specified in [RFC-3486].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in BCP 14, RFC 2119

2.  Minimum Values of SigComp Parameters for SIP/SigComp

   In order to support a wide range of capabilities among endpoints
   implementing SigComp, SigComp defines a few parameters to describe
   SigComp behaviour when receiving SigComp messages (see section 3.3 of
   [RFC-3320]). For each parameter, [RFC-3320] specifies a minimum value
   that any SigComp endpoint MUST support for ANY/SigComp. Those minimum
   values were determined with the consideration of all imaginable
   devices in which SigComp may be implemented.  Scalability is also
   considered as a key factor.

   However, some of the minimum values specified in [RFC-3320] are too
   small to allow good performance for SIP message compression.
   Therefore, they are increased for SIP/SigComp as specified in the
   following sections. For completeness, those parameters that are the
   same for SIP/SigComp as they are for ANY/SigComp are also listed.

   Note: the new minimum values are specific to SIP/SigComp. They do not
   apply to any other application protocols.

   Note: a SigComp endpoint MAY offer additional resources if available;
   these resources can be advertised to remote endpoints as described in
   section 9.4.9 of [RFC-3320].

Liu & Price                                                     [Page 2]

INTERNET-DRAFT           Applying SigComp to SIP           June 17, 2003

2.1.  decompression_memory_size (DMS) for SIP/SigComp

   Minimum value for ANY/SigComp: 2048 bytes, as specified in section
   3.3.1 of [RFC-3320].

   Minimum value for SIP/SigComp: 8192 bytes.

   Reason: DMS of 2048 bytes is too small for SIP message compression,
   as it seriously limits the compression ratio and even makes
   compression impossible for certain messages. For example, the
   condition set by [RFC-3320] for SigComp over UDP means: C + 2*B + R +
   2*S + 128 < DMS (each term is described below).  On the other hand,
   8KB additional memory should not cause any problem for an endpoint
   that implements SIP, SigComp, and applications that use SIP.

   C   = size of compressed application message, depending on R.
   B   = size of bytecode (note: two copies - one as part of SigComp
         message and one in UDVM memory)
   R   = size of ring buffer in UDVM memory
   S   = any additional state uploaded other than that created from the
         content of the ring buffer at the end of decompression. Similar
         to B, two copies of S are needed
   128 = the smallest address in UDVM memory to copy bytecode

   Note: DMS is per SigComp message and the memory can be reclaimed
   after the message has been decompressed.

2.2.  state_memory_size (SMS) for SIP/SigComp

   Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in
   section 3.3.1 of [RFC-3320].

   Minimum value for SIP/SigComp: 2048 bytes.

   Reason: a non-zero SMS allows an endpoint to upload a state in the
   first SIP message sent to a remote endpoint without the uncertainty
   of whether it can be created in the remote endpoint due to lack of

   Note: SMS is per compartment. An endpoint MAY offer different SMS for
   different compartments as long as the SMS is not less than 2048

   [Editor's note: this would prevent the use of SigComp in conjunction
   with stateless SIP proxies. Is this acceptable?]

Liu & Price                                                     [Page 3]

INTERNET-DRAFT           Applying SigComp to SIP           June 17, 2003

2.3.  cycles_per_bit (CPB) for SIP/SigComp

   Minimum value for ANY/SigComp: 16, as specified in section 3.3.1 of

   Minimum value for SIP/SigComp: 16 (same as above)

2.4.  SigComp_version (SV) for SIP/SigComp

   For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC-3320].

   For SIP/SigComp: 0x01 (same as above)

2.5.  locally available state (LAS) for SIP/SigComp

   Minimum value for ANY/SigComp: none, see section 3.3.3 of [RFC-3320]

   Minimum value for SIP/SigComp: the SIP/SDP-specific static dictionary
   as defined in [RFC-3485].

3.  Compartment and State Management for SIP/SigComp

   When SigComp is applied to SIP, there is a one-to-one relationship
   between a SIP dialog (see section 12 of [RFC-3261]) and a pair of
   peer SigComp compartments. The mapping is handled by SIP (not
   SigComp) as follows:

   - When a SIP user agent client (UAC) compresses and sends a request
   that can establish a dialog (such as INVITE), it creates a
   compartment associated with the dialog.

   - When a SIP user agent server (UAS) receives a compressed request
   and decides to respond with a response that establishes a dialog
   (such as a 2xx to INVITE), it creates a compartment associated with
   the dialog.

   - Conceptually, the SIP layer of each SigComp endpoint uses the
   dialog ID as the SigComp compartment ID for the compartment
   associated with the dialog.  However, the actual presentation of the
   compartment ID is a local implementation issue. The only requirement
   is to maintain a local one-to-one mapping between a dialog ID and a
   compartment ID.

   - A SigComp compartment will be closed by SIP when the corresponding
   dialog is terminated.

Liu & Price                                                     [Page 4]

INTERNET-DRAFT           Applying SigComp to SIP           June 17, 2003

   Usually, any states created during the lifetime of a compartment will
   be "logically" deleted when the compartment is closed. A logical
   deletion becomes a physical one when all the compartments that
   created the (same) state are closed. However, a sigcomp endpoint may
   offer to keep a state created upon request from its peer endpoint
   during a dialog beyond the duration of that dialog. This may improve
   compression efficiency of SIP messages generated by the same peer
   endpoint in subsequent dialogs.  In that case, it can inform its peer
   sigcomp endpoint by announcing the (partial) state ID in the returned
   SigComp parameters at the end of the dialog. That signals the state
   will be maintained until the associated timer times out. Since there
   is no mechanism in SigComp and SIP to convey the timeout value, a
   default value needs to be specified [Editor's note: actual value will
   be determined later].  The default value can be overwritten by
   different means in a particular SIP configuration so long as the
   value is known to and agreed by all SigComp endpoints involved.  If
   one sigcomp endpoint is a SIP registrar server and its peer endpoints
   register with it, the lifetime of the state can be specified to be
   the same as that of the registration.

   [Editor's note: this is more complicated than it appears. Above is
   only preliminary text serving as a starting point. There are
   alternative approaches such as associating states or compartments
   with URIs that are persistent through dialogs. More work is needed on
   this section before the next version of the draft.]

4.  Delimiting SIP Messages and SigComp Messages on the Same Port

   In order to limit the number of ports required by a SigComp-aware
   endpoint, it is possible to multiplex SigComp messages and 'vanilla'
   SIP messages (i.e. uncompressed SIP messages with no SigComp header)
   on the same port.

   For a message-based transport such as UDP, the receiving endpoint
   checks the first octet of the UDP payload to determine whether the
   message has been compressed using SigComp.  If the MSBs of the octet
   are "11111" then the message is considered to be a SigComp message
   and is parsed as per [RFC-3320].  If the MSBs of the octet take any
   other value, then the message is assumed to be an uncompressed SIP
   message, and is passed directly to the application with no further
   effect on the SigComp layer.

   For a stream-based transport such as TCP, the receiving endpoint
   checks the first octet of the TCP data stream to determine whether
   the stream has been compressed using SigComp.  If the MSBs of the
   octet are "11111" then the stream is considered to contain SigComp
   messages and is parsed as per [RFC-3320].  If the MSBs of the octet

Liu & Price                                                     [Page 5]

INTERNET-DRAFT           Applying SigComp to SIP           June 17, 2003

   take any other value, then the stream is assumed to contain
   uncompressed SIP messages, and is passed directly to the application
   with no further effect on the SigComp layer.  Note that SigComp
   message delimiters MUST NOT be used if the stream contains
   uncompressed SIP messages.

   Applications MUST NOT mix SIP messages and SigComp messages on a
   single TCP connection.  If the TCP connection is used to carry
   SigComp messages then all messages sent over the connection MUST have
   a SigComp header.

5.  Continuous Mode over TCP

   Continuous Mode is a special feature of SigComp, which is designed to
   improve the overall compression ratio for long-lived connections.
   However, it requires the transport itself to provide a certain level
   of protection against denial of service attacks.  TCP is not
   considered to provide enough protection, and so Continuous Mode MUST
   NOT be used over TCP.

   [Editor's note: is this too restrictive in cases where IPsec is
   enabled below TCP?]

6.  Security Considerations

   The same security considerations as described in [RFC-3320] apply to
   this document. Note that keeping SigComp states longer than the
   duration of a SIP dialog should not pose new security risks for two
   reasons: a) the state has been allowed to be created in the first
   place; and b) this is on voluntary basis and a SigComp endpoint can
   choose not to offer it.

7.  Normative References

   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC-3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
               A., Peterson, J., Sparks, R., Handley, M. and E.
               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
               June 2002.

   [RFC-3320]  Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
               Liu, Z. and J. Rosenberg, "Signaling Compression

Liu & Price                                                     [Page 6]

INTERNET-DRAFT           Applying SigComp to SIP           June 17, 2003

               (SigComp)", RFC 3320, January 2003.

   [RFC-3485]  Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and
               A. Adam, "The Session Initiation Protocol (SIP) and
               Session Description Protocol (SDP) Static Dictionary for
               Signaling Compression (SigComp)", RFC 3485, February

   [RFC-3486]  Camarillo, G., "Compressing the Session Initiation
               Protocol (SIP)", RFC 3486, February 2003.

8.  Authors' Addresses

   Zhigang Liu
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039

   Phone:  +1 972 894-5935
   E-mail: zhigang.c.liu@nokia.com

   Richard Price
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom

   Phone: +44 1794 833681
   Email: richard.price@roke.co.uk

9.  Full copyright statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of

Liu & Price                                                     [Page 7]

INTERNET-DRAFT           Applying SigComp to SIP           June 17, 2003

   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

This Internet-Draft will expire on December 17, 2003.

Liu & Price                                                     [Page 8]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/