draft-ietf-rohc-sigcomp-sip-00.txt   draft-ietf-rohc-sigcomp-sip-01.txt 
Network Working Group Zhigang Liu, Editor, Nokia Network Working Group Zhigang Liu, Editor, Nokia
INTERNET-DRAFT Richard Price, Siemens/Roke Manor INTERNET-DRAFT Richard Price, Siemens/Roke Manor
Expires: December 17, 2003 Expires: August 12, 2004
June 17, 2003 February 12, 2004
Applying Signaling Compression (SigComp) to the Session Initiation Applying Signaling Compression (SigComp) to the Session Initiation
Protocol (SIP) Protocol (SIP)
<draft-ietf-rohc-sigcomp-sip-00.txt> <draft-ietf-rohc-sigcomp-sip-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is a submission of the IETF ROHC WG. Comments should be This document is a submission of the IETF ROHC WG. Comments should be
directed to its mailing list, rohc@ietf.org. directed to its mailing list, rohc@ietf.org.
Abstract Abstract
This document describes some specifics when Signaling Compression This document describes some specifics when Signaling Compression
(SigComp) [RFC-3320] is applied to the Session Initiation Protocol (SigComp) is applied to the Session Initiation Protocol (SIP), such
(SIP) [RFC-3261]. Any SigComp implementation that is used for SIP as default minimum values of SigComp parameters, compartment and
compression must follow this document, in addition to [RFC-3320] and state management, and few issues on SigComp over TCP. Any
[RFC-3485]. implementation of SigComp for use with SIP must conform to this
document, in addition to SigComp and support of the SIP and Session
Description Protocol (SDP) static dictionary.
1. Introduction 1. Introduction
SigComp [RFC-3320] is a solution for compressing messages generated SigComp [RFC-3320] is a solution for compressing messages generated
by application protocols. Although its primary driver is to compress by application protocols. Although its primary driver is to compress
SIP messages, the solution itself has been intentionally designed to SIP messages, the solution itself has been intentionally designed to
be application agnostic so that it can be applied to any application be application agnostic so that it can be applied to any application
protocols. (This is denoted as ANY/SigComp.) Consequently, many protocols. (This is denoted as ANY/SigComp.) Consequently, many
application dependent specifics are left out. It is intended that a application dependent specifics are left out. It is intended that a
separate document will be needed to describe those specifics when separate document will be needed to describe those specifics when
SigComp is applied to a particular application protocol. SigComp is applied to a particular application protocol.
This document binds SigComp and SIP (denoted as SIP/SigComp). Any This document binds SigComp and SIP (denoted as SIP/SigComp). Any
SigComp implementation that is used for SIP message compression must SigComp implementation that is used for the compression of SIP
follow this document, in addition to [RFC-3320] and [RFC-3485]. messages must conform to this document, as well as to SigComp
[RFC-3320] and must support the SIP/SDP static dictionary as
specified in [RFC-3485].
Note: the mechanism of discovering SigComp support at SIP layer is Note: the mechanism of discovering SigComp support at SIP layer is
specified in [RFC-3486]. specified in [RFC-3486].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC-2119]. [RFC-2119].
2. Minimum Values of SigComp Parameters for SIP/SigComp 2. Minimum Values of SigComp Parameters for SIP/SigComp
In order to support a wide range of capabilities among endpoints In order to support a wide range of capabilities among endpoints
implementing SigComp, SigComp defines a few parameters to describe implementing SigComp, SigComp defines a few parameters to describe
SigComp behaviour when receiving SigComp messages (see section 3.3 of SigComp behaviour (see section 3.3 of [RFC-3320]). For each
[RFC-3320]). For each parameter, [RFC-3320] specifies a minimum value parameter, [RFC-3320] specifies a minimum value that any SigComp
that any SigComp endpoint MUST support for ANY/SigComp. Those minimum endpoint MUST support for ANY/SigComp. Those minimum values were
values were determined with the consideration of all imaginable determined with the consideration of all imaginable devices in which
devices in which SigComp may be implemented. Scalability is also SigComp may be implemented. Scalability was also considered as a key
considered as a key factor. factor.
However, some of the minimum values specified in [RFC-3320] are too However, some of the minimum values specified in [RFC-3320] are too
small to allow good performance for SIP message compression. small to allow good performance for SIP message compression.
Therefore, they are increased for SIP/SigComp as specified in the Therefore, they are increased for SIP/SigComp as specified in the
following sections. For completeness, those parameters that are the following sections. For completeness, those parameters that are the
same for SIP/SigComp as they are for ANY/SigComp are also listed. 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 Note: the new minimum values are specific to SIP/SigComp. They do not
apply to any other application protocols. apply to any other application protocols.
skipping to change at page 3, line 41 skipping to change at page 3, line 42
2.2. state_memory_size (SMS) for SIP/SigComp 2.2. state_memory_size (SMS) for SIP/SigComp
Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in
section 3.3.1 of [RFC-3320]. section 3.3.1 of [RFC-3320].
Minimum value for SIP/SigComp: 2048 bytes. Minimum value for SIP/SigComp: 2048 bytes.
Reason: a non-zero SMS allows an endpoint to upload a state in the 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 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 of whether or not it can be created in the remote endpoint due to
memory. lack of memory.
Note: SMS is per compartment. An endpoint MAY offer different SMS for Note: SMS is per compartment. An endpoint MAY offer different SMS for
different compartments as long as the SMS is not less than 2048 different compartments as long as the SMS is not less than 2048
bytes. bytes.
[Editor's note: this would prevent the use of SigComp in conjunction [Editor's note: this would prevent the use of SigComp in conjunction
with stateless SIP proxies. Is this acceptable?] with stateless SIP proxies. Is this acceptable? Discussions on
benefit/cost are ongoing in the ROHC mailing list.]
2.3. cycles_per_bit (CPB) for SIP/SigComp 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 ANY/SigComp: 16, as specified in section 3.3.1 of
[RFC-3320]. [RFC-3320].
Minimum value for SIP/SigComp: 16 (same as above) Minimum value for SIP/SigComp: 16 (same as above)
2.4. SigComp_version (SV) for SIP/SigComp 2.4. SigComp_version (SV) for SIP/SigComp
For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC-3320]. For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC-3320].
For SIP/SigComp: 0x01 (same as above) For SIP/SigComp: 0x01 (same as above)
2.5. locally available state (LAS) for SIP/SigComp 2.5. locally available state (LAS) for SIP/SigComp
Minimum value for ANY/SigComp: none, see section 3.3.3 of [RFC-3320] Minimum LAS for ANY/SigComp: none, see section 3.3.3 of [RFC-3320]
Minimum value for SIP/SigComp: the SIP/SDP-specific static dictionary Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined
as defined in [RFC-3485]. in [RFC-3485].
3. Compartment and State Management for SIP/SigComp 3. Compartment and State Management for SIP/SigComp
When SigComp is applied to SIP, there is a one-to-one relationship 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 between a SIP dialog (see section 12 of [RFC-3261]) and a pair of
peer SigComp compartments. The mapping is handled by SIP (not peer SigComp compartments. The mapping is handled by SIP (not
SigComp) as follows: SigComp) as follows:
- When a SIP user agent client (UAC) compresses and sends a request - When a SIP user agent client (UAC) compresses and sends a request
that can establish a dialog (such as INVITE), it creates a that can establish a dialog (such as INVITE), it creates a
compartment associated with the dialog. compartment associated with the dialog.
- When a SIP user agent server (UAS) receives a compressed request - When a SIP user agent server (UAS) receives a compressed request
and decides to respond with a response that establishes a dialog and decides to respond with a response that establishes a dialog
(such as a 2xx to INVITE), it creates a compartment associated with (such as a 2xx to INVITE), it creates a compartment associated with
the dialog. the dialog.
- Conceptually, the SIP layer of each SigComp endpoint uses the - Conceptually, the SIP layer of each SigComp endpoint uses the
dialog ID as the SigComp compartment ID for the compartment dialog ID as the SigComp compartment ID for the compartment
associated with the dialog. However, the actual presentation of the associated with the dialog. However, the actual representation of
compartment ID is a local implementation issue. The only requirement the compartment ID is a local implementation issue. The only
is to maintain a local one-to-one mapping between a dialog ID and a requirement is to maintain a local one-to-one mapping between a
compartment ID. dialog ID and a compartment ID.
- A SigComp compartment will be closed by SIP when the corresponding - A SigComp compartment will be closed by SIP when the corresponding
dialog is terminated. dialog is terminated.
Usually, any states created during the lifetime of a compartment will Usually, any states created during the lifetime of a compartment will
be "logically" deleted when the compartment is closed. A logical be "logically" deleted when the compartment is closed. A logical
deletion becomes a physical one when all the compartments that deletion becomes a physical one when all the compartments that
created the (same) state are closed. However, a sigcomp endpoint may created the (same) state are closed. However, a SigComp endpoint may
offer to keep a state created upon request from its peer endpoint offer to keep a state created upon request from its peer endpoint
during a dialog beyond the duration of that dialog. This may improve during a dialog beyond the duration of that dialog. This may improve
compression efficiency of SIP messages generated by the same peer compression efficiency of SIP messages generated by the same peer
endpoint in subsequent dialogs. In that case, it can inform its 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 endpoint by announcing the (partial) state ID in the returned
SigComp parameters at the end of the dialog. That signals the state SigComp parameters at the end of the dialog. That signals the state
will be maintained until the associated timer times out. Since there will be maintained until the associated timer times out. Since there
is no mechanism in SigComp and SIP to convey the timeout value, a 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 default value needs to be specified [Editor's note: actual value will
be determined later]. The default value can be overwritten by be determined later]. The default value can be overwritten by
different means in a particular SIP configuration so long as the different means in a particular SIP configuration so long as the
value is known to and agreed by all SigComp endpoints involved. If value is known to and agreed by all SigComp endpoints involved. If
one sigcomp endpoint is a SIP registrar server and its peer endpoints 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 register with it, the lifetime of the state can be specified to be
the same as that of the registration. the same as that of the registration.
[Editor's note: this is more complicated than it appears. Above is [Editor's note: this is more complicated than it appears. Above is
only preliminary text serving as a starting point. There are only preliminary text serving as a starting point. There are
alternative approaches such as associating states or compartments improvements and alternatives being discussed in the ROHC WG.]
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 4. Delimiting SIP Messages and SigComp Messages on the Same Port
In order to limit the number of ports required by a SigComp-aware In order to limit the number of ports required by a SigComp-aware
endpoint, it is possible to multiplex SigComp messages and 'vanilla' endpoint, it is possible to multiplex SigComp messages and 'vanilla'
SIP messages (i.e. uncompressed SIP messages with no SigComp header) SIP messages (i.e. uncompressed SIP messages with no SigComp header)
on the same port. on the same port.
For a message-based transport such as UDP, the receiving endpoint For a message-based transport such as UDP, the receiving endpoint
checks the first octet of the UDP payload to determine whether the checks the first octet of the UDP payload to determine whether the
skipping to change at page 6, line 13 skipping to change at page 6, line 19
messages and is parsed as per [RFC-3320]. If the MSBs of the octet messages and is parsed as per [RFC-3320]. If the MSBs of the octet
take any other value, then the stream is assumed to contain take any other value, then the stream is assumed to contain
uncompressed SIP messages, and is passed directly to the application uncompressed SIP messages, and is passed directly to the application
with no further effect on the SigComp layer. Note that SigComp with no further effect on the SigComp layer. Note that SigComp
message delimiters MUST NOT be used if the stream contains message delimiters MUST NOT be used if the stream contains
uncompressed SIP messages. uncompressed SIP messages.
Applications MUST NOT mix SIP messages and SigComp messages on a Applications MUST NOT mix SIP messages and SigComp messages on a
single TCP connection. If the TCP connection is used to carry single TCP connection. If the TCP connection is used to carry
SigComp messages then all messages sent over the connection MUST have SigComp messages then all messages sent over the connection MUST have
a SigComp header. a SigComp header and be delimited by the use of 0xFFFF as described
in [RFC 3320].
[Editor's note: there have been discussions on the need of
multiplexing SigComp and non-SigComp messages on the same TCP
connection. However, no conclusion was reached.]
5. Continuous Mode over TCP 5. Continuous Mode over TCP
Continuous Mode is a special feature of SigComp, which is designed to Continuous Mode is a special feature of SigComp, which is designed to
improve the overall compression ratio for long-lived connections. improve the overall compression ratio for long-lived connections.
However, it requires the transport itself to provide a certain level However, it requires the transport itself to provide a certain level
of protection against denial of service attacks. TCP is not of protection against denial of service attacks. TCP is not
considered to provide enough protection, and so Continuous Mode MUST considered to provide enough protection, and so Continuous Mode MUST
NOT be used over TCP. NOT be used over TCP.
[Editor's note: is this too restrictive in cases where IPsec is [Editor's note: is this too restrictive in cases where IPsec is
enabled below TCP?] enabled below TCP? There have been no comments on this issue so far.]
6. Security Considerations 6. Security Considerations
The same security considerations as described in [RFC-3320] apply to The same security considerations as described in [RFC-3320] apply to
this document. Note that keeping SigComp states longer than the this document. Note that keeping SigComp states longer than the
duration of a SIP dialog should not pose new security risks for two 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 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 place; and b) this is on voluntary basis and a SigComp endpoint can
choose not to offer it. choose not to offer it.
7. Normative References 7. Acknowledgements
The authors would like to thank the following people for their
comments and suggestions: Carsten Bormann, Jan Christoffersson, Pekka
Pessi, Robert Sugar, Abigail Surtees, and Mark West.
8. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC-3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E. A., Peterson, J., Sparks, R., Handley, M. and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC-3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., [RFC-3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H.,
skipping to change at page 7, line 15 skipping to change at page 8, line 5
[RFC-3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and [RFC-3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and
A. Adam, "The Session Initiation Protocol (SIP) and A. Adam, "The Session Initiation Protocol (SIP) and
Session Description Protocol (SDP) Static Dictionary for Session Description Protocol (SDP) Static Dictionary for
Signaling Compression (SigComp)", RFC 3485, February Signaling Compression (SigComp)", RFC 3485, February
2003. 2003.
[RFC-3486] Camarillo, G., "Compressing the Session Initiation [RFC-3486] Camarillo, G., "Compressing the Session Initiation
Protocol (SIP)", RFC 3486, February 2003. Protocol (SIP)", RFC 3486, February 2003.
8. Authors' Addresses 9. Authors' Addresses
Zhigang Liu Zhigang Liu
Nokia Research Center Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Phone: +1 972 894-5935 Phone: +1 972 894-5935
E-mail: zhigang.c.liu@nokia.com E-mail: zhigang.c.liu@nokia.com
Richard Price Richard Price
Roke Manor Research Ltd Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN Romsey, Hants, SO51 0ZN
United Kingdom United Kingdom
Phone: +44 1794 833681 Phone: +44 1794 833681
Email: richard.price@roke.co.uk Email: richard.price@roke.co.uk
9. Full copyright statement 10. Full copyright statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 8, line 19 skipping to change at page 9, line 7
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This Internet-Draft will expire on December 17, 2003. This Internet-Draft will expire on August 12, 2004.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/