idnits 2.17.1 draft-camarillo-manyfolks-confirm-00.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: ---------------------------------------------------------------------------- ** 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? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 14 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 337 has weird spacing: '... recv sendr...' -- 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 (June 2001) is 8351 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) -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Gonzalo Camarillo 3 Internet draft Ericsson 4 October 2000 5 Expires June 2001 6 8 Confirmation of SDP preconditions 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes certain functionality that is missing in the 32 current "Integration of Resource Management and SIP" [1] (a.k.a. 33 manyfolks draft). An extension to add this functionality is 34 outlined. 36 This functionality is needed in general to provide richer signalling 37 capabilities and can be employed in several scenarios. This draft 38 describes its use in third party call control applications. 40 If this extension is accepted it is foreseen that this draft would 41 be merged with [1]. 43 1. Introduction 45 "Integration of Resource Management in SIP" [1] provides a mechanism 46 that allows a UA issuing a SIP message with SDP preconditions to ask 47 the other party to confirm that the preconditions are met. The 48 "confirm" attribute together with the COMET method are used for that 49 purpose. 51 A typical situation where the "confirm" attribute is used is a two 52 party session with QoS preconditions. The callee will request a 54 Camarillo 1 55 Confirmation of SDP preconditions 57 confirmation message (COMET) from the caller by including a 58 "confirm" attribute in a 183 response. As soon as the callee�s UA 59 has finished the resource reservation in the callee-caller direction 60 (using RSVP for instance) and a COMET arrives from the caller 61 (confirming that resources are also available in the caller-callee 62 direction) the callee will be alerted. 64 The "confirm" attribute in (b) triggers the COMET in (e). 66 Caller Callee 68 | (a) INVITE | 69 |------------------>| 70 | (b) 183 | 71 |<------------------| 72 | (c) PRACK | 73 |------------------>| 74 |(d) 200 OK (PRACK) | 75 |<------------------| 76 | (e) COMET | 77 |------------------>| 78 | (f) 200 OK (COMET)| 79 |<------------------| 80 |(g) 200 OK (INVITE)| 81 |<------------------| 82 | (h) ACK | 83 |------------------>| 85 (a) 86 INVITE sip:callee@ws4321.provider2.com SIP/2.0 87 Via: SIP/2.0/UDP ws1234.provider1.com:5060 88 Require: 100rel 89 From: Caller 90 To: Calee 91 Call-ID: 12345678@ws1234.provider1.com 92 CSeq: 1 INVITE 93 Contact: Caller 94 Content-Type: application/sdp 95 Content-Length: 155 97 v=0 98 o=Caller 2891234526 2891234526 IN IP4 ws1234.provider1.com 99 s=Session SDP 100 c=IN IP4 10.0.0.1 101 t=0 0 102 m=audio 20002 RTP/AVP 0 103 a=qos:mandatory sendrecv 105 (b) 106 SIP/2.0 183 Session Progress 108 Camarillo 2 109 Confirmation of SDP preconditions 111 Via: SIP/2.0/UDP ws1234.provider1.com:5060 112 Require: 100rel 113 RSeq: 112233 114 From: Caller 115 To: Callee ;tag=314159 116 Call-ID: 12345678@ws1234.provider1.com 117 CSeq: 1 INVITE 118 Contact: Callee 119 Content-Type: application/sdp 120 Content-Length: 163 122 v=0 123 o=Callee 2891234526 2891234526 IN IP4 ws4321.provider2.com 124 s=Session SDP 125 c=IN IP4 10.0.0.3 126 t=0 0 127 m=audio 30000 RTP/AVP 0 128 a=qos:mandatory sendrecv confirm 130 (c) 131 PRACK sip:callee@ws4321.provider2.com SIP/2.0 132 RAck: 112233 1 INVITE 133 Via: SIP/2.0/UDP ws1234.provider1.com:5060 134 From: Caller 135 To: Callee ;tag=314159 136 Call-ID: 12345678@ws1234.provider1.com 137 CSeq: 2 PRACK 139 (d) 140 SIP/2.0 200 OK 141 Via: SIP/2.0/UDP ws1234.provider1.com:5060 142 From: Caller 143 To: Callee ;tag=314159 144 Call-ID: 12345678@ws1234.provider1.com 145 CSeq: 2 PRACK 147 (e) 148 COMET sip:callee@ws4321.provider2.com SIP/2.0 149 Via: SIP/2.0/UDP ws1234.provider1.com:5060 150 From: Caller 151 To: Callee ;tag=314159 152 Call-ID: 12345678@ws1234.provider1.com 153 CSeq: 3 COMET 154 Content-Type: application/sdp 155 Content-Length: 149 157 v=0 158 o=Caller 2891234526 2891234526 IN IP4 ws1234.provider1.com 159 s=Session SDP 160 c=IN IP4 10.0.0.1 161 t=0 0 162 m=audio 20002 RTP/AVP 0 163 a=qos:success send 165 Camarillo 3 166 Confirmation of SDP preconditions 168 (f) 169 SIP/2.0 200 OK 170 Via: SIP/2.0/UDP ws1234.provider1.com:5060 171 From: Caller 172 To: Callee ;tag=314159 173 Call-ID: 12345678@ws1234.provider1.com 174 CSeq: 3 COMET 176 (g) 177 SIP/2.0 200 OK 178 Via: SIP/2.0/UDP ws1234.provider1.com:5060 179 From: Caller 180 To: Callee ;tag=314159 181 Call-ID: 12345678@ws1234.provider1.com 182 CSeq: 1 INVITE 183 Contact: Callee 184 Content-Type: application/sdp 185 Content-Length: 129 187 v=0 188 o=Callee 2891234526 2891234526 IN IP4 ws4321.provider2.com 189 s=Session SDP 190 c=IN IP4 10.0.0.3 191 t=0 0 192 m=audio 30000 RTP/AVP 0 194 (h) 195 ACK sip:callee@ws4321.provider2.com SIP/2.0 196 Via: SIP/2.0/UDP ws1234.provider1.com:5060 197 From: Caller 198 To: Callee ;tag=314159 199 Call-ID: 12345678@ws1234.provider1.com 200 CSeq: 1 ACK 201 Contact: Caller 203 2. Caller triggering COMETs 205 Note that in the previous example, the COMET in (e) is sent because 206 the callee wanted it to be sent - (b) contained a "confirm" 207 parameter. If the caller included a "confirm" attribute in the 208 INVITE (a), it would trigger a COMET from the callee to the caller. 210 The caller does not have a means for triggering COMETs from the 211 caller to the callee. Similarly, the callee cannot trigger COMETs 212 from the callee to the caller. 214 This mechanism is needed is certain situations, such as the ones 215 described in [2]. The need of this mechanism is described in the 216 "open issues" section of [2] and it was presented in the SIP WG 217 meeting in Pittsburgh [3]. 219 Camarillo 4 220 Confirmation of SDP preconditions 222 When third party call control is performed, the controller wants to 223 be sure that the session establishment does not go on until it sends 224 a COMET. The following example, taken from [2], helps understand 225 this need. 227 Controller A B 229 | (1) INVITE | | 230 |------------------>| | 231 | (2) 183 SDP A | | 232 |<------------------| | 233 | (3) INVITE SDP A | | 234 |------------------------------------->| 235 | (4) 183 SDP B | | 236 |<-------------------------------------| 237 | (5) PRACK SDP B | | 238 |------------------>| | 239 | (6) 200 OK (PRACK)| | 240 |<------------------| | 241 | (7) PRACK | | 242 |------------------------------------->| 243 | (8) 200 OK (PRACK)| | 244 |<-------------------------------------| 245 | (9) COMET | | 246 |<-------------------------------------| 247 |(10) 200 OK (COMET)| | 248 |------------------------------------->| 249 | (11) COMET | | 250 |<------------------| | 251 |(12) 200 OK (COMET)| | 252 |------------------>| | 253 | (13) COMET | | 254 |------------------>| | 255 |(14) 200 OK (COMET)| | 256 |<------------------| | 257 |(15) 200 OK (INVITE) | 258 |<------------------| | 259 | (16) COMET | | 260 |------------------------------------->| 261 |(17) 200 OK (COMET)| | 262 |<-------------------------------------| 263 |(18) 200 OK (INVITE) | 264 |<-------------------------------------| 265 | (19) ACK | | 266 |------------------>| | 267 | (20) ACK | | 268 |------------------------------------->| 269 | | | 271 Controller A B 273 Camarillo 5 274 Confirmation of SDP preconditions 276 After (12), all the preconditions are met. However, the controller 277 does not send a COMET to B (16) until A has answered the INVITE 278 (15). Therefore, if A relied on mechanisms different than COMET 279 (such as ResvConf in RSVP) to check if the resource reservation was 280 already done third party call control mechanisms would fail, since A 281 would go on with the session establishment after (12), instead of 282 waiting for (15). Preconditions met confirmations must rely solely 283 on application layer mechanisms - SIP. 285 Thus, a mechanism that allows the controller to ask A to wait for 286 the COMET before continuing with the session is needed. 288 3. Solution 290 A direction attribute is needed in order to indicate to which 291 direction the "confirm" attribute applies. That is, which party 292 sends the COMET. 294 Section 4 of [1] would look as follows: 296 qos-attribute = "a=qos:" strength-tag SP direction-tag 297 [SP confirmation-tag] 298 strength-tag = ("mandatory" | "optional" | "success" | 299 "failure") 300 direction-tag = ("send" | "recv" | "sendrecv") 301 confirmation-tag = "confirm" SP direction-tag 303 The SDP contained in INVITE (a) would look as follows: 305 v=0 306 o=Caller 2891234526 2891234526 IN IP4 ws1234.provider1.com 307 s=Session SDP 308 c=IN IP4 10.0.0.1 309 t=0 0 310 m=audio 20002 RTP/AVP 0 311 a=qos:mandatory sendrecv confirm send 313 The SDP in (b) would be then: 315 v=0 316 o=Callee 2891234526 2891234526 IN IP4 ws4321.provider2.com 317 s=Session SDP 318 c=IN IP4 10.0.0.3 319 t=0 0 320 m=audio 30000 RTP/AVP 0 321 a=qos:mandatory sendrecv confirm recv 323 The following table illustrates the allowed values for the direction 324 attribute in the response. Each row represents a value of the 325 direction in the SIP INVITE, and each column the value in the 326 response. An entry of N/A means that this combination is not 327 allowed. A value of A->B (B->A) implies that the COMET will be sent 328 from A to B (B to A). A value of A<->B means that the will be two 330 Camarillo 6 331 Confirmation of SDP preconditions 333 COMETs, one in each direction. The value in the response is the one 334 used by both parties. 336 B: response 337 A: request send recv sendrecv none 338 send N/A A->B A<->B N/A 339 recv B->A N/A A<->B N/A 340 sendrecv N/A N/A A<->B N/A 341 none B->A A->B A<->B No COMETs 343 This table assumes that the preconditions suggested in the INVITE 344 (e.g. mandatory sendrecv) are accepted and thus included in the 345 response. If the response does not include all of them (e.g. 346 mandatory recv) there are interactions with the direction attribute 347 regarding COMETs and this table would not be valid. Some N/A entries 348 would become valid combinations. These interactions are already 349 present in the current approach [1]. 351 4. Backward compatibility 353 An implementation that does not understand the direction attribute 354 introduced by this draft would find the "a=qos" line malformed and 355 it will thus return an error to the UA issuing the INVITE. The UA 356 can then fall back to the previous syntax (defined by [1]) if it 357 wishes to proceed anyway. 359 5. References 361 [1] W. Marshall et al, "Integration of Resource Management and SIP", 362 draft-manyfolks-sip-resource-01.txt, IETF; June 2000. Work in 363 progress. 365 [2] G. Camarillo, "Third party call control with SDP preconditions", 366 draft-camarillo-3pcc-qos-00.txt, IETF; July 2000. Work in progress. 368 [3] http://www.softarmor.com/sipwg/meets/IETF48/slides/pres- 369 camarillo-3pccprecon-sip-48.ppt 371 6. Author's Addresses 373 Gonzalo Camarillo 374 Ericsson 375 Advanced Signalling Research Lab. 376 FIN-02420 Jorvas 377 Finland 379 Phone: +358 9 299 3371 380 Fax: +358 9 299 3052 381 Email: Gonzalo.Camarillo@ericsson.com 383 Camarillo 7