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)
<draft-ietf-rohc-sigcomp-sip-00.txt>
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-
Drafts.
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://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is a submission of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@ietf.org.
Abstract
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
[RFC-3485].
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[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
memory.
Note: SMS is per compartment. An endpoint MAY offer different SMS for
different compartments as long as the SMS is not less than 2048
bytes.
[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
[RFC-3320].
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
2003.
[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
USA
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
English.
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
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft will expire on December 17, 2003.
Liu & Price [Page 8]
