draft-ietf-rohc-sigcomp-sip-05.txt   draft-ietf-rohc-sigcomp-sip-06.txt 
Robust Header Compression C. Bormann Robust Header Compression C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Expires: September 4, 2007 Z. Liu Intended status: Standards Track Z. Liu
Nokia Research Center Expires: November 15, 2007 Nokia Research Center
R. Price R. Price
Cogent Defence and Security Cogent Defence and Security
Networks Networks
G. Camarillo, Ed. G. Camarillo, Ed.
Ericsson Ericsson
March 3, 2007 May 14, 2007
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-05.txt draft-ietf-rohc-sigcomp-sip-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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 Internet-Draft will expire on September 4, 2007. This Internet-Draft will expire on November 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes some specifics that apply when Signaling This document describes some specifics that apply when Signaling
Compression (SigComp) is applied to the Session Initiation Protocol Compression (SigComp) is applied to the Session Initiation Protocol
(SIP), such as default minimum values of SigComp parameters, (SIP), such as default minimum values of SigComp parameters,
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.4. SigComp_version (SV) for SIP/SigComp . . . . . . . . . . . 5 4.4. SigComp_version (SV) for SIP/SigComp . . . . . . . . . . . 5
4.5. locally available state (LAS) for SIP/SigComp . . . . . . 5 4.5. locally available state (LAS) for SIP/SigComp . . . . . . 5
5. Delimiting SIP Messages and SigComp Messages on the Same 5. Delimiting SIP Messages and SigComp Messages on the Same
Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6 6. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6
7. Too Large SIP Messages . . . . . . . . . . . . . . . . . . . . 6 7. Too Large SIP Messages . . . . . . . . . . . . . . . . . . . . 6
8. SIP Retransmissions . . . . . . . . . . . . . . . . . . . . . 7 8. SIP Retransmissions . . . . . . . . . . . . . . . . . . . . . 7
9. Compartment and State Management for SIP/SigComp . . . . . . . 7 9. Compartment and State Management for SIP/SigComp . . . . . . . 7
9.1. Remote Application Identification . . . . . . . . . . . . 7 9.1. Remote Application Identification . . . . . . . . . . . . 7
9.2. Identifier Comparison Rules . . . . . . . . . . . . . . . 10 9.2. Identifier Comparison Rules . . . . . . . . . . . . . . . 10
9.3. Compartment Opening and Closure . . . . . . . . . . . . . 11 9.3. Compartment Opening and Closure . . . . . . . . . . . . . 10
9.4. Lack of a Compartment . . . . . . . . . . . . . . . . . . 12 9.4. Lack of a Compartment . . . . . . . . . . . . . . . . . . 12
10. Recommendations for Network Administrators . . . . . . . . . . 13 10. Recommendations for Network Administrators . . . . . . . . . . 12
11. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 13 11. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 13
12. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 12. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 13
13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
17.1. Normative References . . . . . . . . . . . . . . . . . . . 18 17.1. Normative References . . . . . . . . . . . . . . . . . . . 18
17.2. Informative References . . . . . . . . . . . . . . . . . . 19 17.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 21
skipping to change at page 6, line 25 skipping to change at page 6, line 25
application with no further effect on the SigComp layer. Note that application with no further effect on the SigComp layer. Note that
SigComp message delimiters MUST NOT be used if the stream contains SigComp 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 and be delimited by the use of 0xFFFF as described a SigComp header and be delimited by the use of 0xFFFF as described
in [RFC3320]. in [RFC3320].
[I-D.ietf-rohc-sigcomp-impl-guide] shows how to send uncompressed Section 11 of [I-D.ietf-rohc-sigcomp-impl-guide] details a simple set
messages in a SigComp-structured TCP connection using a "well-known of bytecodes, intended to be "well-known", that implement a null
shim header". Should it for any reason not be desirable to set up decompression algorithm. These bytecodes effectively allow SigComp
more than one TCP connection to a SIP implementation, but the peers to send selected SigComp messages with uncompressed data. If a
flexibility to send both compressed and uncompressed SIP messages be SIP implementation has reason to send both compressed and
required, the compressor can set up a SigComp-structured connection uncompressed SIP messages on a single TCP connection, the compressor
and send any uncompressed SIP messages using the well-known shim can be instructed to use these bytecodes to send uncompressed SIP
header. messages that are also valid SigComp messages.
6. Continuous Mode over TCP 6. 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.
Its use requires pre-agreement between the SigComp compressor and Its use requires pre-agreement between the SigComp compressor and
decompressor. Continuous mode is not used with SIP/SigComp. decompressor. Continuous mode is not used with SIP/SigComp.
Reason: continuous mode requires the transport itself to provide a Reason: continuous mode requires the transport itself to provide a
certain level of protection against denial of service attacks. TCP certain level of protection against denial of service attacks. TCP
skipping to change at page 8, line 43 skipping to change at page 8, line 43
The Via 'sigcomp-id' parameter is a 'via-extension', as defined by The Via 'sigcomp-id' parameter is a 'via-extension', as defined by
the SIP ABNF (Section 25.1 of [RFC3261]). The following is its ABNF the SIP ABNF (Section 25.1 of [RFC3261]). The following is its ABNF
[RFC4234]: [RFC4234]:
via-sip-sigcomp-id = "sigcomp-id" EQUAL via-sip-sigcomp-id = "sigcomp-id" EQUAL
LDQUOT *( qdtext / quoted-pair ) RDQUOT LDQUOT *( qdtext / quoted-pair ) RDQUOT
The Via 'sigcomp-id' parameter MUST contain a URN [RFC2141]. The Via 'sigcomp-id' parameter MUST contain a URN [RFC2141].
The following is an example of a 'sigcomp-id' SIP URI parameter:
sigcomp-id=urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128
The following is an example of a Via header field with a 'sigcomp-id' The following is an example of a Via header field with a 'sigcomp-id'
parameter: parameter:
Via: SIP/2.0/UDP server1.example.com:5060 Via: SIP/2.0/UDP server1.example.com:5060
;branch=z9hG4bK87a7 ;branch=z9hG4bK87a7
;comp=sigcomp ;comp=sigcomp
;sigcomp-id="urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128" ;sigcomp-id="urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128"
Note that some characters that are allowed to appear in a Via header
field parameter, such as ':' (colon), are not allowed to appear in a
SIP URI parameter. Those characters need to be escaped when they
appear in a SIP URI parameter.
The need to escape characters in parameters could be avoided by
defining Contact, Route, Record-Route, Path, and Service-Route
header field 'sigcomp-id' parameters instead of the 'sigcomp-id'
SIP URI parameter. For example, instance identifiers typically
appear in '+sip.instance' Contact header field parameters, and not
in SIP URI parameters. We have chosen to define 'sigcomp-id' as a
SIP URI parameter to be consistent with the use of the already-in-
use 'comp=sigcomp' parameter, which is a SIP URI parameter as
well.
The following is an example of a 'sigcomp-id' SIP URI parameter:
sigcomp-id=urn%3auuid%3a0C67446E-F1A1-11D9-94D3-000A95A0E128
The following is an example of a REGISTER request that carries The following is an example of a REGISTER request that carries
'sigcomp-id' parameters in a Via entry and in the Contact header 'sigcomp-id' parameters in a Via entry and in the Contact header
field. Additionally, it also carries a '+sip.instance' Contact field. Additionally, it also carries a '+sip.instance' Contact
header field parameter. header field parameter.
REGISTER sip:example.net SIP/2.0 REGISTER sip:example.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.247:2078;branch=z9hG4bK-et736vsjirav; Via: SIP/2.0/UDP 192.0.2.247:2078;branch=z9hG4bK-et736vsjirav;
rport;sigcomp-id="urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473" rport;sigcomp-id="urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473"
From: "Joe User" <sip:2145550500@example.net>;tag=6to4gh7t5j From: "Joe User" <sip:2145550500@example.net>;tag=6to4gh7t5j
To: "Joe User" <sip:2145550500@example.net> To: "Joe User" <sip:2145550500@example.net>
Call-ID: 3c26700c1adb-lu1lz5ri5orr Call-ID: 3c26700c1adb-lu1lz5ri5orr
CSeq: 215196 REGISTER CSeq: 215196 REGISTER
Max-Forwards: 70 Max-Forwards: 70
Contact: <sip:2145550500@192.0.2.247:2078; Contact: <sip:2145550500@192.0.2.247:2078;
sigcomp-id=urn%3auuid%3a2e5fdc76-00be-4314-8202-1116fa82a473>; sigcomp-id=urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>;
q=1.0; expires=3600; q=1.0; expires=3600;
+sip.instance="<urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>" +sip.instance="<urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>"
Content-Length: 0 Content-Length: 0
SIP messages are matched with remote application identifiers as SIP messages are matched with remote application identifiers as
follows. follows.
Outgoing requests: the remote application identifier is the SIP/ Outgoing requests: the remote application identifier is the SIP/
SigComp identifier of the URI to which the request is sent. If SigComp identifier of the URI to which the request is sent. If
the URI does not contain a SIP/SigComp identifier, the remote the URI does not contain a SIP/SigComp identifier, the remote
skipping to change at page 17, line 41 skipping to change at page 17, line 41
-------------- ----------------- --------- -------------- ----------------- ---------
sigcomp-id No [RFCxxxx] sigcomp-id No [RFCxxxx]
Note to the RFC Editor: please, substitute RFCxxxx with the RFC Note to the RFC Editor: please, substitute RFCxxxx with the RFC
number this document will get. number this document will get.
16. Acknowledgements 16. Acknowledgements
The authors would like to thank the following people for their The authors would like to thank the following people for their
comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West, comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West,
Pekka Pessi, Robert Sugar, Jonathan Rosenberg, and Robert Sparks. Pekka Pessi, Robert Sugar, Jonathan Rosenberg, Robert Sparks, and
Abigail Surtees and Adam Roach performed thorough reviews of this Tuukka Karvonen. Abigail Surtees and Adam Roach performed thorough
document. reviews of this document.
17. References 17. References
17.1. Normative References 17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] 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.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
skipping to change at page 19, line 32 skipping to change at page 19, line 32
Postfach 330440 Postfach 330440
Bremen D-28334 Bremen D-28334
Germany Germany
Phone: +49 421 218 7024 Phone: +49 421 218 7024
Fax: +49 421 218 7000 Fax: +49 421 218 7000
Email: cabo@tzi.org Email: cabo@tzi.org
Zhigang Liu Zhigang Liu
Nokia Research Center Nokia Research Center
6000 Connection Drive 955 Page Mill Road
Irving, TX 75039 Palo Alto, CA 94304
USA USA
Phone: +1 972 894-5935 Phone: +1 650 796 4578
Email: zhigang.c.liu@nokia.com Email: zhigang.c.liu@nokia.com
Richard Price Richard Price
Cogent Defence and Security Networks Cogent Defence and Security Networks
Queensway Meadows Industrial Estate Queensway Meadows Industrial Estate
Meadows Road Meadows Road
Newport, Gwent NP19 4SS Newport, Gwent NP19 4SS
Phone: +44 (0)1794 833681 Phone: +44 (0)1794 833681
Email: richard.price@cogent-dsn.com Email: richard.price@cogent-dsn.com
 End of changes. 14 change blocks. 
42 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/