idnits 2.17.1 draft-ietf-mmusic-sip-100rel-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... sends the INVITE request as per RFC2543 [1]. The RAck header MUST be...' RFC 2119 keyword, line 131: '...eived by the server, it MAY send a 100...' RFC 2119 keyword, line 139: '... For these reasons, 100 responses MUST...' RFC 2119 keyword, line 146: '.... Both sn and rn MUST be initialized t...' RFC 2119 keyword, line 148: '... The server MAY send a reliable resp...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 20, 1999) is 9106 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 section? '1' on line 494 looks like a reference -- Missing reference section? '2' on line 498 looks like a reference -- Missing reference section? '3' on line 502 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force MMUSIC WG 2 Internet Draft J.Rosenberg,H.Schulzrinne 3 draft-ietf-mmusic-sip-100rel-01.txt Bell Laboratories,Columbia U. 4 May 20, 1999 5 Expires: November 20, 1999 7 Reliability of Provisional Responses in SIP 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document specifies an extension to the Session Initiation 33 Protocol (SIP) providing reliable provisional response messages. 35 1 Introduction 37 The Session Initiation Protocol (SIP) [1] is a request-response 38 protocol for initiating, maintaining, and terminating multimedia 39 sessions. Each SIP request is followed by one or more provisional 40 responses, followed by a one or more definitive responses. These 41 provisional responses, also called informational responses, have 42 status codes within the 100-199 range. They are most commonly used 43 for responses to an INVITE request. They provide information on call 44 progress, such as trying (100), alerting (180), and queueing (182). 45 However, when run over UDP, SIP does not guarantee that these 46 messages are delivered reliably, or in order. 48 However, a number of applications require reliability and in-order 49 delivery of provisional responses to INVITE. These include gateway 50 applications, wireless phones, ACD servers, and call queueing 51 systems. Generally, these applications make use of the provisional 52 responses to drive state machinery. This is especially true for the 53 180 Ringing provisional response, which maps to the Q.931 ALERTING 54 message. 56 This document provides a simple extension to SIP for ensuring that 57 provisional responses to INVITEs are delivered reliably, independent 58 of the underlying transport mechanism. The extension applies only to 59 the INVITE method. Reliability of provisional responses for other 60 methods is not provided. The extension is simple, requiring two new 61 header fields, and no new methods. It fits well within the generic 62 framework of SIP reliability. It is partly backwards compatible, so 63 that a Require header is not needed (it can be included if the UAC 64 insists on the feature, of course), although a Proxy-Require header 65 is needed. 67 2 Terminology 69 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 70 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 71 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and 72 indicate requirement levels for compliant implementations. 74 3 Overview 76 The reliability mechanism is based on the standard windowed 77 acknowledgement technique. When a server generates a provisional 78 response which is to be delivered reliably, it places a sequence 79 number (via the RSeq header field) in the provisional response. These 80 sequence numbers always start at zero, since they are defined only 81 within the context of a transaction. This elimiates the need for SYN 82 handshakes as in TCP. The provisional response is then retransmitted 83 with an exponential backoff. 85 The UAC maintains a variable, sn, which is the highest sequence 86 number seen in a reliable response. When the client receives a 87 provisional response that has been sent reliably, and this response 88 has a sequence number one higher than sn, sn is incremented, and the 89 request is retransmitted. Otherwise, if the response has a sequence 90 number greater than one higher, sn is not incremented. Either way, 91 the request is retransmitted, and the value of sn is placed in the 92 RAck header in the request. 94 When the server sees a request retransmission with an RAck header 95 with a value equalling the sequence number in the last reliably 96 transmitted response, it stops retransmitting that response, and is 97 free to send the next provisional response, with a higher sequence 98 number. 100 The mechanism is similar to TCP, but with a constant window of one. 101 The use of a fixed size window comes at the penalty of reduced 102 response throughput. The througput of responses is fairly low (1 per 103 RTT without loss, lower with loss). However, as the provisional 104 responses are used to signal changes in phone call states, which 105 generally occur on timescales on the order of hundreds of 106 milliseconds to seconds, such a limited throughput appears 107 acceptable. The mechanism can be extended to support larger window 108 sizes, if necessary. 110 The server can still generate unreliable provisional responses by 111 sending them without an RSeq header. A UAC which receives a 112 provisional response without a RSeq does not retransmit the request. 113 This allows for backwards compatibility; a UAS which doesn't know how 114 to transmit reliable responses will never place an RSeq header in a 115 response, and so the SIP transaction will proceed normally. 117 Similarly, the initial INVITE from the client contains an RAck 118 header. This serves as an indicator to the server than the client 119 supports the reliability mechanism. A UAS which doesn't see this 120 header in a request knows it cannot provide reliable provisional 121 responses. 123 4 Detailed Protocol Semantics 125 A transaction begins when the client sends a request. The client 126 sends the INVITE request as per RFC2543 [1]. The RAck header MUST be 127 placed in the request, with a value of zero, if the client 128 understands and is willing to support this extension for the 129 transaction. 131 When the initial INVITE is received by the server, it MAY send a 100 132 response (depending on whether it is a proxy or not). A 100 response 133 is normally sent reliably according to the current SIP specification. 134 This is because the client retransmits its request until a response 135 (i.e., 100) is received, and the server retransmits the 100 response 136 upon request retransmission. As a result, no additional means is 137 needed to reliably send a 100 response over a single hop. 138 Furthermore, the SIP specification mandates that the 100 response is 139 not forwarded through a proxy. For these reasons, 100 responses MUST 140 NOT contain an RSeq header. 142 The server maintains a window of size 1, which is effectively the 143 value of the highest unacknowledged provisional response that has 144 been transmitted; call this rn. The client maintains a single 145 variable, sn, which represents the highest in order provisional 146 response received so far. Both sn and rn MUST be initialized to 0. 148 The server MAY send a reliable response if the initial INVITE request 149 from the client contained a RAck header with a value of 0. If the 150 request contained a Require header, and the server is a UAS, the UAS 151 SHOULD send all non-100 provisional responses reliably. If the 152 request contained a Proxy-Require header, and the server is a proxy, 153 the server SHOULD send all locally generated non-100 provisional 154 responses reliably. It also SHOULD reliably send upstream any 155 responses received reliably from a downstream server. The server MUST 156 NOT send a reliable response if the initial INVITE request did not 157 contain an RAck header with a value of zero. When the server decides 158 to send a provisional response reliably, it MUST increment rn, and 159 MUST place this incremented value in the RSeq header in the response. 160 The provisional response SHOULD be retransmitted at intervals with an 161 exponential backoff, starting at T1 (default of 500ms), and doubling 162 after each retransmission. 164 When a client receives a provisional response, it checks for the 165 presence of the RSeq header. If it is not present, the response was 166 an unreliable provisional response. The client MUST NOT retransmit 167 the request. As per [1], the client also ceases exponentially backing 168 off request retransmissions when any response (with or without the 169 RSeq header) is received. 171 If the server does not understand this extension, it will 172 behave according to the base SIP specification, and 173 retransmit responses upon request retransmissions. A client 174 which retransmits requests upon response retransmissions 175 would cause a feedback loop of constant request and 176 response retransmissions. By checking for the RSeq header, 177 the client can determine whether the server is supporting 178 this extension for this response. 180 If, however, the provisional response contains an RSeq header, the 181 value is compared against sn. If it is one higher than the current 182 value of sn, sn is incremented, otherwise sn is unchanged. The client 183 SHOULD then resend the original request (independently of whether the 184 value of sn has changed), and MUST include the sequence number sn in 185 the request in the header field RAck. 187 When a request is received at a server, it checks for the presence of 188 the RAck header. If it is not present, the server retransmits the 189 last response that was sent. If the RAck header is present, and the 190 value is lower than the value of rn, the last reliable response is 191 retransmitted. If the RAck header was present in the request, and the 192 value is equal to the current value of rn, the exponentially backing 193 off response retransmissions cease. Additional copies of the request 194 with the same or lower value of RAck that are received by the server 195 SHOULD NOT cause the server to retransmit any response (as they would 196 in the above case if RAck were lower), unless rn is zero. The server 197 always retransmits the last response sent (provisional, reliable 198 provisional, or otherwise) when a request is received with both RAck 199 and rn equal to 0. 201 This handles the case where a proxy server doesn't send a 202 100 response, but transmits a reliable response as the 203 first response. To make sure the initial request is 204 transmitted reliably, the server has to retransmit the 205 first response upon request retransmissions. 207 Once a request has arrived with RAck equal to rn, the server is free 208 to increment rn and transmit another provisional response. The server 209 MUST NOT ever generate an additional reliable response until it has 210 received a request with an RAck header with a value equal to rn. 212 When the server is ready to send a final response, it does so 213 according to [1]. An ACK request causes retransmissions of the final 214 response to cease. The server SHOULD NOT continue to retransmit any 215 reliable provisional responses once a final response has been sent. 217 5 Header Syntax 219 Two new header fields are defined, RSeq and RAck. The BNF for these 220 are: 222 RSeq = "RSeq" ":" 1*DIGIT 223 RAck = "RAck" ":" 1*DIGIT 225 RSeq is a response header field. RAck is a request header field. 227 If a client insists that all provisional responses (those generated 228 by proxies and UAS's) be sent reliably, it MUST include both the 229 Require and Proxy-Require headers in all requests. A UAC MAY 230 alternately send requests only with the Proxy-Require header. This 231 will cause all non-100 provisional responses generated by proxies to 232 be sent reliably. Responses sent by UAS's may, or may not be sent 233 reliably, at the discretion of the UAS. 235 This document specifies the named extension org.ietf.sip.reliable- 236 100. 238 6 Operation with Proxies 240 A SIP request may pass through any number of proxies, some of which 241 may fork the request. The reliability mechanism defined here requires 242 proxies to be aware of the extension. Consider what would happen if a 243 proxy receives a request with a RSeq header, but no Proxy-Require 244 header, and the proxy does not know the extension. As per normal SIP 245 rules, the proxy would forward the request, with the RSeq header in 246 tact, to the downstream proxy. If that proxy did understand the 247 extension, it might try and send a reliable response to the first 248 proxy. The first proxy would see the provisional response 249 retransmissions, but never resend the request. This would cause an 250 excess of network traffic, and block transmission of other 251 provisional responses at the downstream proxy. 253 The situation would be even more catastrophic for a forking proxy. 254 Consider the case where the first proxy forks the request to 255 downstream proxies A and B. Both A and B understand the extension, 256 and each try to send a reliable response. The first proxy forwards 257 both responses upstream. But, since it does not understand the 258 extension, it does not remove or change the value of the RSeq header 259 in either response. Thus, the client receiving these requests will 260 think they are retransmissions, rather than being two separate 261 responses. 263 Implementation of this extension in a stateless proxy is not done 264 according to the rules in section 4. A stateless proxy implementing 265 this extension MUST forward all requests it receives downstream, and 266 MUST forward all responses it receives upstream, including 267 provisional responses. Actual reliability is achieved between the 268 first pair of stateful proxies. 270 A stateful proxy implementing this extension MUST act as a virtual 271 UAS-UAC in the algorithm described in the previous section. When any 272 non-100 provisional response is received reliably at a proxy, the 273 proxy MUST reliably transmit it upstream towards the next stateful 274 proxy. When any non-100 provisional response is received unreliably 275 at the proxy, the proxy MUST send the response unreliably upstream. 276 Any provisional responses generated by the proxy itself (excepting 277 100) MUST be sent reliably upstream. 279 Since a proxy may be receiving reliable provisional responses from 280 several branches of a forked request, it will need to merge the 281 provisional response streams together. There are no requirements 282 about the ordering of provisional responses across branches. However, 283 all provisional responses from a given branch MUST be transmitted 284 reliably upstream in the same order they were received along a 285 branch. For example, consider a forking proxy A which sends a request 286 to UAS's B and C. B sends provisional response 0 towards A, and once 287 it has been received, sends response 1. Similarly, B sends 288 provisional response 2, and once received and acknowledged by A, 289 sends provisional response 3. Proxy A may forward the provisional 290 responses towards the UAS in any one of the following orders: 292 0,1,2,3 293 0,2,1,3 294 2,3,0,1 295 2,0,3,1 296 0,2,3,1 297 2,0,1,3 299 Since responses from several branches may be merged at a forking 300 proxy, a proxy MUST renumber the provisional responses (always 301 starting at zero, however) when forwarding them upstream. As this 302 requires changing the RSeq value, the RSeq header field cannot be 303 protected by either end-to-end encryption or authentication. 304 Similarly, a stateful proxy will need to remove the RAck header from 305 all requests it receives, and insert its own value into proxied 306 requests. 308 7 Examples 310 7.1 Message Formatting 312 In this example, a UAC wishes to send an INVITE message and receive 313 reliable 100-class responses. Such an INVITE might look like: 315 C->S: INVITE sip:watson@bell-tel.com SIP/2.0 316 Via: SIP/2.0/UDP saturn.bell-tel.com 317 RAck: 0 318 From: sip:alexander@bell-tel.com 319 To: sip:watson@bell-tel.com 320 Call-ID: 70710@saturn.bell-tel.com 321 CSeq: 1 INVITE 322 Subject: Come here Watson 323 Require: org.ietf.sip.reliable-100 324 Proxy-Require: org.ietf.sip.reliable-100 326 The server wishes to send a 180 Ringing provisional response 327 reliably. The response will look like: 329 S->C: SIP/2.0 180 Ringing 330 Via: SIP/2.0/UDP saturn.bell-tel.com 331 RSeq: 1 332 From: sip:alexander@bell-tel.com 333 To: sip:watson@bell-tel.com 334 Call-ID: 70710@saturn.bell-tel.com 335 CSeq: 1 INVITE 337 This response is retransmitted with an exponential backoff. When the 338 UAC receives the response, it retransmits the request, but adds the 339 RAck header field: 341 C->S: INVITE sip:watson@bell-tel.com SIP/2.0 342 RAck: 1 343 Via: SIP/2.0/UDP saturn.bell-tel.com 344 From: sip:alexander@bell-tel.com 345 To: sip:watson@bell-tel.com 346 Call-ID: 70710@saturn.bell-tel.com 347 CSeq: 1 INVITE 348 Subject: Come here Watson 349 Require: org.ietf.sip.reliable-100 350 Proxy-Require: org.ietf.sip.reliable-100 352 7.2 Message Flows 354 This section illustrates a number of message flows using this 355 extension. We abbreviate an INVITE request with a RAck header value 356 of N as "INV N", and a provisional response with a RSeq header value 357 of M as "1xx M". Packets which are lost are shown with an "X" in 358 front of them. 360 7.2.1 UAC to UAS, with Require 362 In this case, the UAC sends a request directly to a UAS, and includes 363 the Require header, naming this extension. The extension is supported 364 by the UAS. The UAS sends a 100 response first, and then a 180 365 reliably. 367 UAC UAS 369 -------INV 0--------------> 370 X<.......100......... 371 -------INV 0--->X 372 -------INV 0--------------> 373 (request <..........100............. 374 retransmissions 375 cease) 376 X<...180 1............ (180 retransmits start, sn=1) 378 (rn inc to 1) <.........180 1............ 379 -------INV 1----> 381 <.........180 1............ 382 -------INV 1--------------> (180 retransmits cease) 384 X<....300............... (300 class retransmits start) 385 <........300............... 386 -----------ACK------------> 388 7.2.2 UAC to UAS, without Require, UAS doesn't understand 390 In this case, a UAC sends a request directly to the UAS, and doesn't 391 include the Require header in the request. The UAS doesn't support 392 the extension. The UAS sends a single 180 before sending a final 393 response. 395 UAC UAS 397 -------INV 0--------------> 398 X<.......100......... 399 -------INV 0--->X 400 -------INV 0--------------> 401 (request <..........100............. 402 retransmissions 403 cease) 404 <..........180 ............ 406 X<....300............... (300 class retransmits start) 407 <........300............... 408 -----------ACK------------> 410 Note that after reception of the 180, the request is not 411 retransmitted, since the response did not contain an RSeq header. 413 7.2.3 UAC to proxy to UAS 415 In this case, a UAC sends a request to a proxy, which forwards it to 416 the final UAS. Both the Require and Proxy-Require headers are present 417 in the request. The local proxy generates its own provisional 418 response (188), and the UAS generates a 180: 420 UAC PROXY UAS 422 -----INV 0-------------> ----INV 0-->X 423 -----INV 0-------------> ----INV 0-------------> 424 X<....100........ 425 X<....100........ <....100............... 426 <........100............ 428 X<......188 1....... 429 <...........188 1....... 430 ---------INV 1-->X 431 <...........188 1....... 432 --------INV 1----------> 433 X<....180 1..... 434 <......180 1............. 435 -------INV 1--->X 436 X<....180 2..... <......180 1............. 437 -------INV 1------------> 438 <...........180 2..... 439 -----INV 2------------> 441 Note that the proxy renumbers the two provisional responses before 442 sending them upstream. 444 8 Open Issues 445 There are a number of open issues: 447 1. Currently, SIP requests with the same values of the To, 448 From, Call-ID and CSeq fields are isomorphic. It is 449 possible that certain implementations may discard non- 450 isomorphic requests with identical values for these header 451 fields. By adding the RAck header into a request 452 retransmission, we break the isomorphism of retransmitted 453 requests. Is this a problem? 455 2. The mechanism currently requires proxies to understand it 456 to work. It is possible to hack a solution without this 457 constraint, by placing the RAck value as a parameter in the 458 Via header, rather than its own header. The result would be 459 those pairs of proxies which both understand provisional 460 reliability would provide it, those that don't, would not. 461 Is this useful? 463 9 Security Considerations 465 Since the RSeq value cannot be encrypted or authenticated end-to-end, 466 nor can the RAck, man in the middle attacks are possible which can 467 cause the provisional responses to be reordered at the UAC. This can 468 be alleviated by the use of hop-by-hop encryption and authentication 469 mechanisms, such as IPSEC [3,3]. 471 10 Acknowledgements 473 The authors would like to thank Jonathan Lennox and Adam Roach for 474 the comments on this document. 476 11 Author's Addresses 478 Jonathan Rosenberg 479 Lucent Technologies, Bell Laboratories 480 101 Crawfords Corner Rd. 481 Holmdel, NJ 07733 482 Rm. 4C-526 483 email: jdrosen@bell-labs.com 485 Henning Schulzrinne 486 Columbia University 487 M/S 0401 488 1214 Amsterdam Ave. 489 New York, NY 10027-7003 490 email: schulzrinne@cs.columbia.edu 492 12 Bibliography 494 [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 495 session initiation protocol," Request for Comments (Proposed 496 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 498 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 499 levels," Request for Comments (Best Current Practice) 2119, Internet 500 Engineering Task Force, Mar. 1997. 502 [3] R. Atkinson, "IP encapsulating security payload (ESP)," Request 503 for Comments (Proposed Standard) 1827, Internet Engineering Task 504 Force, Aug. 1995.