idnits 2.17.1 draft-ietf-rohc-sigcomp-sip-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 935. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 941. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 20, 2007) is 6062 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 789, but not defined ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-12 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-08 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Robust Header Compression C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track Z. Liu 5 Expires: March 19, 2008 Nokia Research Center 6 R. Price 7 EADS Defence and Security Systems 8 Limited 9 G. Camarillo, Ed. 10 Ericsson 11 September 20, 2007 13 Applying Signaling Compression (SigComp) to the Session Initiation 14 Protocol (SIP) 15 draft-ietf-rohc-sigcomp-sip-08.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on March 19, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document describes some specifics that apply when Signaling 49 Compression (SigComp) is applied to the Session Initiation Protocol 50 (SIP), such as default minimum values of SigComp parameters, 51 compartment and state management, and a few issues on SigComp over 52 TCP. Any implementation of SigComp for use with SIP must conform to 53 this document and SigComp, and in addition support the SIP and 54 Session Description Protocol (SDP) static dictionary. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Compliance with this Specification . . . . . . . . . . . . . . 3 61 4. Minimum Values of SigComp Parameters for SIP/SigComp . . . . . 3 62 4.1. decompression_memory_size (DMS) for SIP/SigComp . . . . . 4 63 4.2. state_memory_size (SMS) for SIP/SigComp . . . . . . . . . 4 64 4.3. cycles_per_bit (CPB) for SIP/SigComp . . . . . . . . . . . 5 65 4.4. SigComp_version (SV) for SIP/SigComp . . . . . . . . . . . 5 66 4.5. locally available state (LAS) for SIP/SigComp . . . . . . 5 67 5. Delimiting SIP Messages and SigComp Messages on the Same 68 Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 6. Continuous Mode over TCP . . . . . . . . . . . . . . . . . . . 6 70 7. Too Large SIP Messages . . . . . . . . . . . . . . . . . . . . 7 71 8. SIP Retransmissions . . . . . . . . . . . . . . . . . . . . . 7 72 9. Compartment and State Management for SIP/SigComp . . . . . . . 7 73 9.1. Remote Application Identification . . . . . . . . . . . . 8 74 9.2. Identifier Comparison Rules . . . . . . . . . . . . . . . 10 75 9.3. Compartment Opening and Closure . . . . . . . . . . . . . 11 76 9.4. Lack of a Compartment . . . . . . . . . . . . . . . . . . 13 77 10. Recommendations for Network Administrators . . . . . . . . . . 13 78 11. Private Agreements . . . . . . . . . . . . . . . . . . . . . . 14 79 12. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14 80 13. Interactions with TLS . . . . . . . . . . . . . . . . . . . . 14 81 14. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 15. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 85 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 18.1. Normative References . . . . . . . . . . . . . . . . . . . 18 87 18.2. Informative References . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 89 Intellectual Property and Copyright Statements . . . . . . . . . . 21 91 1. Introduction 93 SigComp [RFC3320] is a solution for compressing messages generated by 94 application protocols. Although its primary driver is to compress 95 SIP [RFC3261] messages, the solution itself has been intentionally 96 designed to be application agnostic so that it can be applied to any 97 application protocol; this is denoted as ANY/SigComp. Consequently, 98 many application dependent specifics are left out of the base 99 standard. It is intended that a separate specification is used to 100 describe those specifics when SigComp is applied to a particular 101 application protocol. 103 This document binds SigComp and SIP; this is denoted as SIP/SigComp. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 3. Compliance with this Specification 113 Any SigComp implementation that is used for the compression of SIP 114 messages MUST conform to this document, as well as to [RFC3320]. 115 Additionally, it must support the SIP/SDP static dictionary, as 116 specified in [RFC3485], and the mechanism for discovering SigComp 117 support at the SIP layer, as specified in [RFC3486]. 119 4. Minimum Values of SigComp Parameters for SIP/SigComp 121 In order to support a wide range of capabilities among endpoints 122 implementing SigComp, SigComp defines a few parameters to describe 123 SigComp behavior (see section 3.3 of [RFC3320]). For each parameter, 124 [RFC3320] specifies a minimum value that any SigComp endpoint MUST 125 support for ANY/SigComp. Those minimum values were determined with 126 the consideration of all imaginable devices in which SigComp may be 127 implemented. Scalability was also considered as a key factor. 129 However, some of the minimum values specified in [RFC3320] are too 130 small to allow good performance for SIP message compression. 131 Therefore, they are increased for SIP/SigComp as specified in the 132 following sections. For completeness, those parameters that are the 133 same for SIP/SigComp as they are for ANY/SigComp are also listed. 135 The new minimum values are specific to SIP/SigComp and, thus, do not 136 apply to any other application protocols. A SIP/SigComp endpoint MAY 137 offer additional resources over and above the minimum values 138 specified in this document if available; these resources can be 139 advertised to remote endpoints as described in section 9.4.9 of 140 [RFC3320]. 142 4.1. decompression_memory_size (DMS) for SIP/SigComp 144 Minimum value for ANY/SigComp: 2048 bytes, as specified in section 145 3.3.1 of [RFC3320]. 147 Minimum value for SIP/SigComp: 8192 bytes. 149 Reason: a DMS of 2048 bytes is too small for SIP message compression 150 as it seriously limits the compression ratio and even makes 151 compression impossible for certain messages. For example, the 152 condition set by [RFC3320] for SigComp over UDP means: C + 2*B + R + 153 2*S + 128 < DMS (each term is described below). Therefore, if DMs is 154 too small, at least one of C, B, R, or S will be severely restricted. 155 On the other hand, DMS is memory that is only temporarily needed 156 during decompression of a SigComp message (the memory can be 157 reclaimed when the message has been decompressed). Therefore, a 158 requirement of 8 KB should not cause any problem for an endpoint that 159 already implements SIP, SigComp, and applications that use SIP. 161 C size of compressed application message, depending on R 162 B size of bytecode. Note: two copies -- one as part of the SigComp 163 message and one in UDVM (Universal Decompressor Virtual Machine) 164 memory. 165 R size of circular buffer in UDVM memory 166 S any additional state uploaded other than that created from the 167 content of the circular buffer at the end of decompression 168 (similar to B, two copies of S are needed) 169 128 the smallest address in UDVM memory to copy bytecode to 171 4.2. state_memory_size (SMS) for SIP/SigComp 173 Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in 174 section 3.3.1 of [RFC3320]. 176 Minimum value for SIP/SigComp: 2048 bytes. 178 Reason: a non-zero SMS allows an endpoint to upload a state in the 179 first SIP message sent to a remote endpoint without the uncertainty 180 of whether the remote endpoint will have enough memory to store such 181 a state. A non-zero SMS obviously requires the SIP/SigComp 182 implementation to keep state. Based on the observation that there is 183 little gain from stateless SigComp compression, the assumption is 184 that purely stateless SIP implementations are unlikely to provide a 185 SigComp function. Stateful implementations should have little 186 problem to keep 2K additional state for each compartment (see 187 Section 9). 189 Note: SMS is a parameter that applies to each individual compartment. 190 An endpoint MAY offer different SMS values for different compartments 191 as long as the SMS value is not less than 2048 bytes. 193 4.3. cycles_per_bit (CPB) for SIP/SigComp 195 Minimum value for ANY/SigComp: 16, as specified in section 3.3.1 of 196 [RFC3320]. 198 Minimum value for SIP/SigComp: 16 (same as above) 200 4.4. SigComp_version (SV) for SIP/SigComp 202 For ANY/SigComp: 0x01, as specified in section 3.3.2 of [RFC3320]. 204 For SIP/SigComp: >= 0x02 (at least SigComp + NACK) 206 Note that this implies that the provisions of [RFC4077] apply. That 207 is, decompression failures result in SigComp NACK messages sent back 208 to the originating compressor. It also implies that the compressor 209 need not make use of the methods detailed in Section 2.4 of [RFC4077] 210 (Detecting Support for NACK); for example, it can use optimistic 211 compression methods right from the outset. 213 4.5. locally available state (LAS) for SIP/SigComp 215 Minimum LAS for ANY/SigComp: none, see section 3.3.3 of [RFC3320]. 217 Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined 218 in [RFC3485]. 220 Note that, since support for the static SIP/SDP dictionary is 221 mandatory, it does not need to be advertised. 223 5. Delimiting SIP Messages and SigComp Messages on the Same Port 225 In order to limit the number of ports required by a SigComp-aware 226 endpoint, it is possible to allow both SigComp messages and 'vanilla' 227 SIP messages (i.e. uncompressed SIP messages with no SigComp header) 228 to arrive on the same port. 230 For a message-based transport such as UDP or SCTP, distinguishing 231 between SigComp and non-SigComp messages can be done per message. 232 The receiving endpoint checks the first octet of the UDP/SCTP payload 233 to determine whether the message has been compressed using SigComp. 234 If the MSBs (Most Significant Bits) of the octet are "11111" then the 235 message is considered to be a SigComp message and is parsed as per 236 [RFC3320]. If the MSBs of the octet take any other value, then the 237 message is assumed to be an uncompressed SIP message, and is passed 238 directly to the application with no further effect on the SigComp 239 layer. 241 For a stream-based transport such as TCP, distinguishing between 242 SigComp and non-SigComp messages has to be done per connection. The 243 receiving endpoint checks the first octet of the TCP data stream to 244 determine whether the stream has been compressed using SigComp. If 245 the MSBs of the octet are "11111" then the stream is considered to 246 contain SigComp messages and is parsed as per [RFC3320]. If the MSBs 247 of the octet take any other value, then the stream is assumed to 248 contain uncompressed SIP messages, and is passed directly to the 249 application with no further effect on the SigComp layer. Note that 250 SigComp message delimiters MUST NOT be used if the stream contains 251 uncompressed SIP messages. 253 Applications MUST NOT mix SIP messages and SigComp messages on a 254 single TCP connection. If the TCP connection is used to carry 255 SigComp messages then all messages sent over the connection MUST have 256 a SigComp header and be delimited by the use of 0xFFFF as described 257 in [RFC3320]. 259 Section 11 of [RFC4896] details a simple set of bytecodes, intended 260 to be "well-known", that implement a null decompression algorithm. 261 These bytecodes effectively allow SigComp peers to send selected 262 SigComp messages with uncompressed data. If a SIP implementation has 263 reason to send both compressed and uncompressed SIP messages on a 264 single TCP connection, the compressor can be instructed to use these 265 bytecodes to send uncompressed SIP messages that are also valid 266 SigComp messages. 268 6. Continuous Mode over TCP 270 Continuous Mode is a special feature of SigComp, which is designed to 271 improve the overall compression ratio for long-lived connections. 272 Its use requires pre-agreement between the SigComp compressor and 273 decompressor. Continuous mode is not used with SIP/SigComp. 275 Reason: continuous mode requires the transport itself to provide a 276 certain level of protection against denial of service attacks. TCP 277 alone is not considered to provide enough protection. 279 7. Too Large SIP Messages 281 SigComp does not support the compression of messages larger than 64k. 282 Therefore, if a SIP application sending compressed SIP messages to 283 another SIP application over a transport connection (e.g., a TCP 284 connection) needs to send a SIP message larger than 64k, the SIP 285 application MUST NOT send the message over the same TCP connection. 286 The SIP application SHOULD send the message over a different 287 transport connection (to do this, the SIP application may need to 288 establish a new transport connection). 290 8. SIP Retransmissions 292 When SIP messages are retransmitted, they need to be re-compressed, 293 taking into account any SigComp states that may have been created or 294 invalidated since the previous transmission. Implementations MUST 295 NOT cache the result of compressing the message and retransmit such a 296 cached result. 298 The reason for this behavior is that it is impossible to know whether 299 the failure causing the retransmission occurred on the message being 300 retransmitted or on the response to that message. If the response 301 was lost, any state changes effected by the first instance of the 302 retransmitted message would already have taken place. If these state 303 changes removed a state that the previously-transmitted message 304 relied upon, then retransmission of the same compressed message would 305 lead to a decompression failure. 307 Note that a SIP retransmission may be caused by the original message 308 or its response being lost by a decompression failure. In this case, 309 a NACK will have been sent by the decompressor to the compressor, 310 which may use the information in this NACK message to adjust its 311 compression parameters. Note that, on an unreliable transport, such 312 a NACK message may still be lost, so if a compressor used some form 313 of optimistic compression it MAY want to switch to a method less 314 likely to cause any form of decompression failure when compressing a 315 SIP retransmission. 317 9. Compartment and State Management for SIP/SigComp 319 An application exchanging compressed traffic with a remote 320 application has a compartment that contains state information needed 321 to compress outgoing messages and to decompress incoming messages. 322 To increase the compression efficiency, the application must assign 323 distinct compartments to distinct remote applications. 325 9.1. Remote Application Identification 327 SIP/SigComp applications identify remote applications by their SIP/ 328 SigComp identifiers. Each SIP/SigComp application MUST have a SIP/ 329 SigComp identifier URN (Uniform Resource Name) that uniquely 330 identifies the application. Usage of a URN provides a persistent and 331 unique name for the SIP/SigComp identifier. It also provides an easy 332 way to guarantee uniqueness. This URN MUST be persistent as long as 333 the application stores compartment state related to other SIP/SigComp 334 applications. 336 A SIP/Sigcomp application SHOULD use a UUID (Universally Unique 337 IDentifier) URN as its SIP/SigComp identifier, due to the 338 difficulties in equality comparisons for other kinds of URNs. The 339 UUID URN [RFC4122] allows for non-centralized computation of a URN 340 based on time, unique names (such as a MAC address), or a random 341 number generator. If a URN scheme other than UUID is used, the URN 342 MUST be selected such that the application can be certain that no 343 other SIP/SigComp application would choose the same URN value. 345 Note that the definition of SIP/SigComp identifier is similar to the 346 definition of instance identifier in [I-D.ietf-sip-outbound]. One 347 difference is that instance identifiers are only required to be 348 unique within their AoR (Address of Record) while SIP/SigComp 349 identifiers are required to be globally unique. 351 Even if instance identifiers are only required to be unique within 352 their AoR, devices may choose to generate globally unique instance 353 identifiers. A device with a globally unique instance identifier 354 SHOULD use its instance identifier as its SIP/SigComp identifier. 356 Using the same value for an entity's instance and SIP/SigComp 357 identifiers improves the compression ratio of header fields that 358 carry both identifiers (e.g., a Contact header field in a REGISTER 359 request). 361 Server farms that share SIP/SigComp state across servers MUST use the 362 same SIP/SigComp identifier for all their servers. 364 SIP/SigComp identifiers are carried in the 'sigcomp-id' SIP URI 365 (Uniform Resource Identifier) or Via header field parameter. The 366 'sigcomp-id' SIP URI parameter is a 'uri-parameter', as defined by 367 the SIP ABNF (Augmented Backus-Naur Form, Section 25.1 of [RFC3261]). 368 The following is its ABNF [RFC4234]: 370 uri-sip-sigcomp-id = "sigcomp-id=" 1*paramchar 372 The SIP URI 'sigcomp-id' parameter MUST contain a URN [RFC2141]. 374 The Via 'sigcomp-id' parameter is a 'via-extension', as defined by 375 the SIP ABNF (Section 25.1 of [RFC3261]). The following is its ABNF 376 [RFC4234]: 378 via-sip-sigcomp-id = "sigcomp-id" EQUAL 379 LDQUOT *( qdtext / quoted-pair ) RDQUOT 381 The Via 'sigcomp-id' parameter MUST contain a URN [RFC2141]. 383 The following is an example of a 'sigcomp-id' SIP URI parameter: 385 sigcomp-id=urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128 387 The following is an example of a Via header field with a 'sigcomp-id' 388 parameter: 390 Via: SIP/2.0/UDP server1.example.com:5060 391 ;branch=z9hG4bK87a7 392 ;comp=sigcomp 393 ;sigcomp-id="urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128" 395 The following is an example of a REGISTER request that carries 396 'sigcomp-id' parameters in a Via entry and in the Contact header 397 field. Additionally, it also carries a '+sip.instance' Contact 398 header field parameter. 400 REGISTER sip:example.net SIP/2.0 401 Via: SIP/2.0/UDP 192.0.2.247:2078;branch=z9hG4bK-et736vsjirav; 402 rport;sigcomp-id="urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473" 403 From: "Joe User" ;tag=6to4gh7t5j 404 To: "Joe User" 405 Call-ID: 3c26700c1adb-lu1lz5ri5orr 406 CSeq: 215196 REGISTER 407 Max-Forwards: 70 408 Contact: ; 410 q=1.0; expires=3600; 411 +sip.instance="" 412 Content-Length: 0 414 SIP messages are matched with remote application identifiers as 415 follows. 417 Outgoing requests: the remote application identifier is the SIP/ 418 SigComp identifier of the URI to which the request is sent. If 419 the URI does not contain a SIP/SigComp identifier, the remote 420 application identifier is the IP address plus port of the datagram 421 carrying the request for connection-less transport protocols, and 422 the transport connection (e.g., a TCP connection) carrying the 423 request for connection-oriented transport protocols (this is to 424 support legacy SIP/SigComp applications). 426 Incoming responses: the remote application identifier is the same as 427 that of the previously-sent request that initiated the transaction 428 to which the response belongs. 430 Incoming requests: the remote application identifier is the SIP/ 431 SigComp identifier of the top-most Via entry. If the Via header 432 field does not contain a SIP/SigComp identifier, the remote 433 application identifier is the source IP address plus port of the 434 datagram carrying the request for connection-less transport 435 protocols, and the transport connection (e.g., a TCP connection) 436 carrying the request for connection-oriented transport protocols 437 (this is to support legacy SIP/SigComp applications). 439 Outgoing responses: the remote application identifier is the same as 440 that of the previously-received request that initiated the 441 transaction to which the response belongs. Note that, due to 442 standard SIP Via header field processing, this identifier will be 443 present in the top-most Via entry in such responses (as long as it 444 was present in the top-most Via entry of the previously-received 445 request). 447 A SIP/SigComp application placing its URI with the 'comp=sigcomp' 448 parameter in a header field MUST add a 'sigcomp-id' parameter with 449 its SIP/SigComp identifier to that URI. 451 A SIP/SigComp application generating its own Via entry containing the 452 'comp=sigcomp' parameter MUST add a 'sigcomp-id' parameter with its 453 SIP/SigComp identifier to that Via entry. 455 A given remote application identifier is mapped to a particular 456 SigComp compartment ID following the rules given in Section 9.3. 458 9.2. Identifier Comparison Rules 460 Equality comparisons between SIP/SigComp identifiers are performed 461 using the rules for URN equality that are specific to the scheme in 462 the URN. If the element performing the comparisons does not 463 understand the URN scheme, it performs the comparisons using the 464 lexical equality rules defined in RFC 2141 [RFC2141]. Lexical 465 equality may result in two URNs being considered unequal when they 466 are actually equal. In this specific usage of URNs, the only element 467 which provides the URN is the SIP/SigComp application identified by 468 that URN. As a result, the SIP/SigComp application SHOULD provide 469 lexically equivalent URNs in each registration it generates. This is 470 likely to be normal behavior in any case; applications are not likely 471 to modify the value of their SIP/SigComp identifiers so that they 472 remain functionally equivalent yet lexicographically different from 473 previous identifiers. 475 9.3. Compartment Opening and Closure 477 SIP applications need to know when to open a new compartment and when 478 to close it. The lifetime of SIP/SigComp compartments is linked to 479 registration state. Compartments are opened at SIP registration time 480 and are typically closed when the registration expires or is 481 canceled. 483 Note that linking the lifetime of SIP/SigComp compartments to 484 registration state limits the applicability of this specification. 485 In particular, SIP user agents that do not register but, for 486 example, only handle PUBLISH or SUBSCRIBE/NOTIFY transactions are 487 not able create SIP/SigComp compartments following this 488 specification. Previous revisions of this specification also 489 defined compartments valid during a SIP transaction or a SIP 490 dialog. Those compartments covered all possible SIP entities, 491 including those that do not handle REGISTER transactions. 492 However, it was decided to eliminate those types of compartments 493 because the complexity they introduced (e.g., edge proxy servers 494 were required to keep dialog state) was higher than the benefits 495 they brought in most deployment scenarios. 497 Usually, any states created during the lifetime of a compartment will 498 be "logically" deleted when the compartment is closed. As described 499 in section 6.2 of [RFC3320], a logical deletion can become a physical 500 deletion only when no compartment continues to exist that created the 501 (same) state. 503 A SigComp endpoint may offer to keep a state created upon request 504 from a SigComp peer endpoint beyond the default lifetime of a 505 compartment (i.e., beyond the duration of its associated 506 registration). This may be used to improve compression efficiency of 507 subsequent SIP messages generated by the same remote application at 508 the SigComp peer endpoint. To indicate that such state will continue 509 to be available, the SigComp endpoint can inform its peer SigComp 510 endpoint by announcing the (partial) state ID in the returned SigComp 511 parameters at the end of the registration that was supposed to limit 512 the lifetime of the SigComp state. That signals the state will be 513 maintained. The mandatory support for the SigComp Negative 514 Acknowledgement (NACK) Mechanism [RFC4077] in SIP/SigComp ensures 515 that it is possible to recover from synchronization errors regarding 516 compartment lifetimes. 518 As an operational concern, bugs in the compartment management 519 implementation are likely to lead to sporadic, hard to diagnose 520 failures. Decompressors may therefore want to cache old state and, 521 if still available, allow access while logging diagnostic 522 information. Both compressors and decompressors use the SigComp 523 Negative Acknowledgement (NACK) Mechanism [RFC4077] to recover from 524 situations where such old state may no longer be available. 526 A REGISTER transaction causes an application to open a new 527 compartment to be valid for the duration of the registration 528 established by the REGISTER transaction. 530 A SIP application that needs to send a compressed SIP REGISTER (i.e., 531 a user agent generating a REGISTER or a proxy server relaying one to 532 its next hop) SHOULD open a compartment for the request's remote 533 application identifier. A SIP application that receives a compressed 534 SIP REGISTER (i.e., the registrar or a proxy relaying the REGISTER to 535 its next-hop) SHOULD open a compartment for the request's remote 536 application identifier. 538 These compartments MAY be closed if the REGISTER request is responded 539 with a non-2xx final response, or when the registration expires or is 540 canceled. However, applications MAY also choose to keep these 541 compartments open for a longer period of time, as discussed 542 previously. For a given successful registration, applications SHOULD 543 NOT close their associated compartments until the registration is 544 over. 546 A SIP network can be configured so that regular SIP traffic to and 547 from a user agent traverses a different set of proxies than the 548 initial REGISTER transaction. The path the REGISTER transaction 549 follows is typically determined by configuration data. The path 550 subsequent requests traverse is determined by the Path [RFC3327] 551 and the Service-Route [RFC3308] header fields in the REGISTER 552 transaction and by the Record-Route and the Route header fields in 553 dialog-creating transactions. Previous revisions of this document 554 supported the use of different paths for different types of 555 traffic. However, for simplicity reasons, this document now 556 assumes that networks using compression are configured so that 557 subsequent requests follow the same path as the initial REGISTER 558 transaction. Section 10 provides network administrators with 559 recommendations so that they can configure they networks properly. 561 If, following the rules above, a SIP application is supposed to open 562 a compartment for a remote application identifier for which it 563 already has a compartment (e.g., the SIP application registers 564 towards a second registrar using the same edge proxy server as for 565 its registration towards its first registrar), the SIP application 566 MUST use the already existing compartment. That is, the SIP 567 application MUST NOT open a new compartment. 569 9.4. Lack of a Compartment 571 The use of stateless compression (i.e., compression without a 572 compartment) is not typically worthwhile and may even result in 573 message expansion. Therefore, if a SIP application does not have a 574 compartment for a message it needs to send, it MAY choose not to 575 compress it even in the presence of the comp=sigcomp parameter. 576 Section Section 5 describes how a SIP application can send compressed 577 and uncompressed messages over the same TCP connection. Note that 578 RFC 3486 [RFC3486] states the following: 580 "If the next-hop URI contains the parameter comp=sigcomp, the 581 client SHOULD compress the request using SigComp" 583 Experience since RFC 3486 [RFC3486] was written has shown that 584 stateless compression is, in most cases, not worthwhile. That is why 585 now it is not recommended to use it any longer. 587 10. Recommendations for Network Administrators 589 Network administrators can configure their networks so that the 590 compression efficiency achieved is increased. The following 591 recommendations help network administrators perform their task. 593 For a given user agent, the route sets for incoming requests (created 594 by a Path header field) and for outgoing requests (created by a 595 Service-Route header field) are typically the same. However, 596 registrars can, if they wish, insert proxies in the latter route that 597 do not appear in the former route and vice versa. It is RECOMMENDED 598 that registrars are configured so that proxies performing SigComp 599 compression appear in both routes. 601 The routes described previously apply to requests sent outside a 602 dialog. Requests inside a dialog follow a route constructed using 603 Record-Route header fields. It is RECOMMENDED that the proxies 604 performing SigComp that are in the route for requests outside a 605 dialog are configured to place themselves (by inserting themselves in 606 the Record-Route header fields) in the routes used for requests 607 inside dialogs. 609 When a user agent's registration expires, proxy servers performing 610 compression may close their associated SIP/SigComp compartment. If 611 the user agent is involved in a dialog that was established before 612 the registration expired, subsequent requests within the dialog may 613 not be compressed any longer. In order to avoid this situation, it 614 is RECOMMENDED that user agents are registered as long as they are 615 involved in a dialog. 617 11. Private Agreements 619 SIP/SigComp implementations that are subject to private agreements 620 MAY deviate from this specification, if the private agreements 621 unambiguously specify so. Plausible candidates for such deviations 622 include: 624 o Minimum values (Section 4). 625 o Use of continuous mode (Section 6). 626 o Compartment definition (Section 9). 628 12. Backwards Compatibility 630 SigComp has a number of parameters that can be configured per 631 endpoint. This document specifies a profile for SigComp when used 632 for SIP compression that further constrains the range that some of 633 these parameters may take. Examples of this are Decompressor Memory 634 Size, State Memory Size, and SigComp Version (support for NACK). 635 Additionally, this document specifies how SIP/SigComp applications 636 should perform compartment mapping. 638 When this document was written, there already were a few existing 639 SIP/SigComp deployments. The rules in this document have been 640 designed to maximize interoperability with those legacy SIP/SigComp 641 implementations. Nevertheless, implementers should be aware that 642 legacy SIP/SigComp implementations may not conform to this 643 specification. Examples of problems with legacy applications would 644 be smaller DMS than mandated in this document, lack of NACK support, 645 or a different compartment mapping. 647 13. Interactions with TLS 649 Endpoints exchanging SIP traffic over a TLS [RFC4346] connection can 650 use the compression provided by TLS. Two endpoints exchanging SIP/ 651 SigComp traffic over a TLS connection that provides compression need 652 to first compress the SIP messages using SigComp and, then, pass them 653 to the TLS layer, which will compress them again. When receiving 654 data, the processing order is reversed. 656 However, compressing messages twice this way does not typically bring 657 significant gains. Once a message is compressed using SigComp, TLS 658 is not usually able to compress it further. Therefore, TLS will 659 normally only be able to compress SigComp code sent between 660 compressor and decompressor. Since the gain of having SigComp code 661 compressed should be in most cases minimal, it is NOT RECOMMENDED 662 using TLS compression when SigComp compression is being used. 664 14. Example 666 Figure 1 shows an example message flow where the user agent and the 667 outbound proxy exchange compressed SIP traffic. Compressed messages 668 are marked with a (c). 670 User Agent Outbound Proxy Registrar 672 |(1) REGISTER (c) | | 673 |---------------->| | 674 | |(2) REGISTER | 675 | |---------------->| 676 | |(3) 200 OK | 677 | |<----------------| 678 |(4) 200 OK (c) | | 679 |<----------------| | 680 |(5) INVITE (c) | | 681 |---------------->| | 682 | |(6) INVITE | 683 | |------------------------------> 684 | |(7) 200 OK | 685 | |<------------------------------ 686 |(8) 200 OK (c) | | 687 |<----------------| | 688 |(9) ACK (c) | | 689 |---------------->| | 690 | |(10) ACK | 691 | |------------------------------> 692 |(11) BYE (c) | | 693 |---------------->| | 694 | |(12) BYE | 695 | |------------------------------> 696 | |(13) 200 OK | 697 | |<------------------------------ 698 |(14) 200 OK (c) | | 699 |<----------------| | 701 Figure 1: Example message flow 703 The user agent in Figure 1 is initially configured (e.g., using the 704 SIP configuration framework [I-D.ietf-sipping-config-framework]) with 705 the URI of its outbound proxy. That URI contains the outbound 706 proxy's SIP/SigComp identifier, referred to as 'Outbound-id', in a 707 'sigcomp-id' parameter. 709 When the user agent sends an initial REGISTER request (1) to the 710 outbound proxy's URI, the user agent opens a new compartment for 711 'Outbound-id'. This compartment will be valid, at least, for the 712 duration of the registration. 714 On receiving this REGISTER request (1), the outbound proxy opens a 715 new compartment for the SIP/SigComp identifier that appears in the 716 'sigcomp-id' parameter of the top-most Via entry. This identifier, 717 which is the user agent's SIP/SigComp identifier, is referred to as 718 'UA-id'. The compartment opened by the outbound proxy will be valid, 719 at least, for the duration of the registration. The outbound proxy 720 adds Path header field with its own URI, which contains the 721 'Outbound-id' SIP/SigComp identifier, to the REGISTER request and 722 relays it to the registrar (2). 724 When the registrar receives the REGISTER request (2), it constructs 725 the route future incoming requests (to the user agent) will follow 726 using the Contact and the Path header fields. Future incoming 727 requests will traverse the outbound proxy before reaching the user 728 agent. 730 The registrar also constructs the route future outgoing requests 731 (from the user agent) will follow and places it in a Service-Route 732 header field in a 200 (OK) response (3). Future outgoing requests 733 will always traverse the outbound proxy. The registrar has ensured 734 that the outbound proxy performing compression handles both incoming 735 and outgoing requests. 737 When the outbound proxy receives a 200 (OK) response (3), it inspects 738 the top-most Via entry. This entry's SIP/SigComp identifier 'UA-id' 739 matches that of the compartment created before. Therefore, the 740 outbound proxy uses that compartment to compress it and relay it to 741 the user agent. 743 On receiving the 200 (OK) response (4), the user agent stores the 744 Service-Route header field in order to use it to send future outgoing 745 requests. The Service-Route header field contains the outbound 746 proxy's URI, which contains the 'Outbound-id' SIP/SigComp identifier. 748 At a later point, the user agent needs to send an INVITE request (5). 749 According to the Service-Route header field received previously, the 750 user agent sends the INVITE request (5) to the outbound proxy's URI. 752 Since this URI's SIP/SigComp identifier 'Outbound-id' matches that of 753 the compartment created before, this compartment is used to compress 754 the INVITE request. 756 On receiving the INVITE request (5), the outbound proxy Record Routes 757 and relays the INVITE request (6) forward. The outbound proxy Record 758 Routes to ensure that all SIP messages related to this new dialog are 759 routed through the outbound proxy. 761 Finally the dialog is terminated by a BYE transaction (11) that also 762 traverses the outbound proxy. 764 15. Security Considerations 766 The same security considerations as described in [RFC3320] apply to 767 this document. Note that keeping SigComp states longer than the 768 duration of a SIP dialog should not pose new security risks because 769 the state has been allowed to be created in the first place. 771 16. IANA Considerations 773 The IANA is requested to register the 'sigcomp-id' Via header field 774 parameter, which is defined in Section 9.1, under the Header Field 775 Parameters and Parameter Values subregistry within the SIP Parameters 776 registry: 778 Predefined 779 Header Field Parameter Name Values Reference 780 ---------------------------- --------------- --------- --------- 781 Via sigcomp-id No [RFCxxxx] 783 The IANA is requested to register the 'sigcomp-id' SIP URI parameter, 784 which is defined in Section 9.1, under the SIP/SIPS URI Parameters 785 subregistry within the SIP Parameters registry: 787 Parameter Name Predefined Values Reference 788 -------------- ----------------- --------- 789 sigcomp-id No [RFCxxxx] 791 Note to the RFC Editor: please, substitute RFCxxxx with the RFC 792 number this document will get. 794 17. Acknowledgements 796 The authors would like to thank the following people for their 797 comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West, 798 Pekka Pessi, Robert Sugar, Jonathan Rosenberg, Robert Sparks, Juergen 799 Schoenwaelder, and Tuukka Karvonen. Abigail Surtees and Adam Roach 800 performed thorough reviews of this document. 802 18. References 804 18.1. Normative References 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, March 1997. 809 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 811 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 812 A., Peterson, J., Sparks, R., Handley, M., and E. 813 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 814 June 2002. 816 [RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer 817 Two Tunneling Protocol (L2TP) Differentiated Services 818 Extension", RFC 3308, November 2002. 820 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 821 Liu, Z., and J. Rosenberg, "Signaling Compression 822 (SigComp)", RFC 3320, January 2003. 824 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 825 (SIP) Extension Header Field for Registering Non-Adjacent 826 Contacts", RFC 3327, December 2002. 828 [RFC3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A. 829 Roach, "The Session Initiation Protocol (SIP) and Session 830 Description Protocol (SDP) Static Dictionary for Signaling 831 Compression (SigComp)", RFC 3485, February 2003. 833 [RFC3486] Camarillo, G., "Compressing the Session Initiation 834 Protocol (SIP)", RFC 3486, February 2003. 836 [RFC4077] Roach, A., "A Negative Acknowledgement Mechanism for 837 Signaling Compression", RFC 4077, May 2005. 839 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 840 Unique IDentifier (UUID) URN Namespace", RFC 4122, 841 July 2005. 843 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 844 Specifications: ABNF", RFC 4234, October 2005. 846 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 847 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 849 [RFC4896] Surtees, A., West, M., and A. Roach, "Signaling 850 Compression (SigComp) Corrections and Clarifications", 851 RFC 4896, June 2007. 853 18.2. Informative References 855 [I-D.ietf-sipping-config-framework] 856 Petrie, D. and S. Channabasappa, "A Framework for Session 857 Initiation Protocol User Agent Profile Delivery", 858 draft-ietf-sipping-config-framework-12 (work in progress), 859 June 2007. 861 [I-D.ietf-sip-outbound] 862 Jennings, C. and R. Mahy, "Managing Client Initiated 863 Connections in the Session Initiation Protocol (SIP)", 864 draft-ietf-sip-outbound-08 (work in progress), March 2007. 866 Authors' Addresses 868 Carsten Bormann 869 Universitaet Bremen TZI 870 Postfach 330440 871 Bremen D-28334 872 Germany 874 Phone: +49 421 218 7024 875 Fax: +49 421 218 7000 876 Email: cabo@tzi.org 878 Zhigang Liu 879 Nokia Research Center 880 955 Page Mill Road 881 Palo Alto, CA 94304 882 USA 884 Phone: +1 650 796 4578 885 Email: zhigang.c.liu@nokia.com 886 Richard Price 887 EADS Defence and Security Systems Limited 888 Meadows Road 889 Queensway Meadows 890 Newport, Gwent NP19 4SS 892 Phone: +44 (0)1633 637874 893 Email: richard.price@eads.com 895 Gonzalo Camarillo (editor) 896 Ericsson 897 Hirsalantie 11 898 Jorvas 02420 899 Finland 901 Email: Gonzalo.Camarillo@ericsson.com 903 Full Copyright Statement 905 Copyright (C) The IETF Trust (2007). 907 This document is subject to the rights, licenses and restrictions 908 contained in BCP 78, and except as set forth therein, the authors 909 retain all their rights. 911 This document and the information contained herein are provided on an 912 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 913 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 914 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 915 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 916 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 917 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 919 Intellectual Property 921 The IETF takes no position regarding the validity or scope of any 922 Intellectual Property Rights or other rights that might be claimed to 923 pertain to the implementation or use of the technology described in 924 this document or the extent to which any license under such rights 925 might or might not be available; nor does it represent that it has 926 made any independent effort to identify any such rights. Information 927 on the procedures with respect to rights in RFC documents can be 928 found in BCP 78 and BCP 79. 930 Copies of IPR disclosures made to the IETF Secretariat and any 931 assurances of licenses to be made available, or the result of an 932 attempt made to obtain a general license or permission for the use of 933 such proprietary rights by implementers or users of this 934 specification can be obtained from the IETF on-line IPR repository at 935 http://www.ietf.org/ipr. 937 The IETF invites any interested party to bring to its attention any 938 copyrights, patents or patent applications, or other proprietary 939 rights that may cover technology that may be required to implement 940 this standard. Please address the information to the IETF at 941 ietf-ipr@ietf.org. 943 Acknowledgment 945 Funding for the RFC Editor function is provided by the IETF 946 Administrative Support Activity (IASA).