idnits 2.17.1 draft-camarillo-dispatch-precons-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors Copyright Line does not match the current year -- The document date (March 9, 2010) is 5161 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dispatch G. Camarillo 3 Internet-Draft J. Maenpaa 4 Intended status: Standards Track Ericsson 5 Expires: September 10, 2010 G. Yang 6 ZTE 7 March 9, 2010 9 Media State under Preconditions in the Session Initiation Protocol (SIP) 10 draft-camarillo-dispatch-precons-00.txt 12 Abstract 14 In this document, we describe how a UAS (User Agent Server) involved 15 in a session modification can explicitly signal the point where the 16 new session parameters start being used. Explicitly signalling such 17 a change in the session parameters can be useful so that network 18 intermediaries such as B2BUAs (Back-to-back User Agents) have a clear 19 picture of the session's state at every point. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 10, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Starting Using the Media Parameters Subject to 63 Preconditions . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Tradeoff between Being Bandwidth Efficient and Having 66 Explicit Signalling . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 The preconditions mechanism in SIP [RFC3261], as specified in RFC 76 3312 [RFC3312] and RFC 4032 [RFC4032], was designed to allow UAs to 77 reach a common view on the state of the preconditions for a media 78 session. The UAs perform offer/answer exchanges updating each other 79 on the status of their preconditions so that session establishment 80 (in the case of an initial INVITE request) or session modification 81 (in the case of a re-INVITE) can proceed. Once all mandatory 82 preconditions are met, the UAS can proceed with the session 83 establishment or the session modification. 85 2. Starting Using the Media Parameters Subject to Preconditions 87 Preconditions are stream specific. That is, they apply to the media 88 parameters to be used in a media stream. When the mandatory 89 preconditions for a media stream are met, the UAs can start using the 90 media parameters that were subject to the preconditions. 92 However, the fact that the UAs can start using the new media 93 parameters does not mean that they need to start using them 94 immediately. When preconditions are used, the UAS decides when to 95 start using them. During a session establishment, the UAS can wait 96 for using the media parameters until the callee starts being alerted 97 or until the callee accepts the session. During a session 98 modification, the UAS can wait until the callee accepts the changes 99 to the session. 101 The preconditions specifications do not mandate UAs to perform a new 102 offer/answer exchange when the new media parameters start being used. 103 The UAS starts using them and the UAC discovers that the new media 104 parameters are in use at the media level. In a session modification, 105 the UAC stops using the old media parameters at that point. 107 Discovering when the new media parameters start being used at the 108 media level saves an additional offer/answer exchange. However, 109 network intermediaries such as B2BUAs will not know what the current 110 state of the media session is. Therefore, UASs in environments where 111 intermediaries that require knowledge of the current media state of 112 the session may be present should consider performing such additional 113 offer/answer exchanges. The examples in the following section 114 illustrate this point. 116 Note that ICE faced the same issue when it was being designed. ICE 117 was originally designed in a similar way as the preconditions 118 mechanism. That is, endpoints were supposed to agree on the 119 addresses to use for the session at the media level. ICE was 120 eventually redesigned in order to have more explicit signalling 121 (i.e., offer/answer exchanges) about what addresses were being used 122 at the media level. 124 3. Examples 126 UAC UAS 128 | | 129 |-------------(1) INVITE SDP1--------------->| 130 | | 131 |<------------(2) 200 OK SDP2----------------| 132 | | 133 |------------------(3) ACK------------------>| 134 | | 135 | | 136 |-------------(4) INVITE SDP3--------------->| 137 | | 138 |<------(5) 183 Session Progress SDP4--------| 139 | *** *** | 140 |--*R*-----------(6) PRACK-------------*R*-->| 141 | *E* *E* | 142 |<-*S*-------(7) 200 OK (PRACK)--------*S*---| 143 | *E* *E* | 144 | *R* *R* | 145 | *V* *V* | 146 | *A* *A* | 147 | *T* *T* | 148 | *I* *I* | 149 | *O* *O* | 150 | *N* *N* | 151 | *** *** | 152 | *** | 153 | *** | 154 |-------------(8) UPDATE SDP5--------------->| 155 | | 156 |<--------(9) 200 OK (UPDATE) SDP6-----------| 157 | | 158 |<-----------(10) UPDATE SDP7----------------| 159 | | 160 |--------(11) 200 OK (UPDATE) SDP8---------->| 161 | | 162 | | 163 |<-----------(12) UPDATE SDP9----------------| 164 | | 165 |--------(13) 200 OK (UPDATE) SDP10--------->| 166 | | 167 |<-----------(14) 200 OK (INVITE)------------| 168 | | 169 |------------------(15) ACK----------------->| 170 | | 172 Acceptance of a video stream by the user 174 The UAs perform an offer/answer exchange to establish an audio only 175 session: 177 SDP1: 178 m=audio 30000 RTP/AVP 0 179 c=IN IP4 192.0.2.1 181 SDP2: 182 m=audio 31000 RTP/AVP 0 183 c=IN IP4 192.0.2.5 185 At a later point, the UAC sends a re-INVITE (4) in order to change 186 the IP address where it receives the audio stream to a new IP address 187 and add a video stream to the session. Both media streams are 188 subject to preconditions. 190 SDP3: 191 m=audio 30000 RTP/AVP 0 192 c=IN IP4 192.0.2.2 193 a=curr:qos e2e none 194 a=des:qos mandatory e2e sendrecv 195 m=video 30002 RTP/AVP 31 196 c=IN IP4 192.0.2.2 197 a=curr:qos e2e none 198 a=des:qos mandatory e2e sendrecv 200 SDP4 201 m=audio 31000 RTP/AVP 0 202 c=IN IP4 192.0.2.5 203 a=curr:qos e2e none 204 a=des:qos mandatory e2e sendrecv 205 a=conf:qos e2e recv 206 m=video 30002 RTP/AVP 31 207 c=IN IP4 192.0.2.5 208 a=curr:qos e2e none 209 a=des:qos mandatory e2e sendrecv 210 a=conf:qos e2e recv 212 When the UAC finishes resource reservations in its 'send' direction, 213 it sends an UPDATE request (8) indicating so. 215 SDP5: 216 m=audio 30000 RTP/AVP 0 217 c=IN IP4 192.0.2.2 218 a=curr:qos e2e send 219 a=des:qos mandatory e2e sendrecv 220 m=video 30002 RTP/AVP 31 221 c=IN IP4 192.0.2.2 222 a=curr:qos e2e send 223 a=des:qos mandatory e2e sendrecv 225 In its response to the UPDATE request (9), the UAS indicates that all 226 preconditions for both media streams are met. 228 SDP6 229 m=audio 31000 RTP/AVP 0 230 c=IN IP4 192.0.2.5 231 a=curr:qos e2e sendrecv 232 a=des:qos mandatory e2e sendrecv 233 m=video 30002 RTP/AVP 31 234 c=IN IP4 192.0.2.5 235 a=curr:qos e2e sendrecv 236 a=des:qos mandatory e2e sendrecv 238 The UAS is configured to automatically accept changes in IP 239 addresses. Therefore, it starts using the new remote IP address for 240 the audio stream. In order to explicitly signal this at the SIP 241 level, the UAS sends an UPDATE request (10) removing the 242 preconditions from the audio stream. This indicates that the audio 243 stream is now in use. 245 SDP7 246 m=audio 31000 RTP/AVP 0 247 c=IN IP4 192.0.2.5 248 m=video 30002 RTP/AVP 31 249 c=IN IP4 192.0.2.5 250 a=curr:qos e2e sendrecv 251 a=des:qos mandatory e2e sendrecv 253 SDP8: 254 m=audio 30000 RTP/AVP 0 255 c=IN IP4 192.0.2.2 256 m=video 30002 RTP/AVP 31 257 c=IN IP4 192.0.2.2 258 a=curr:qos e2e send 259 a=des:qos mandatory e2e sendrecv 261 When the callee finally accepts the addition of the video stream, the 262 UAS sends an UPDATE request (12) indicating that the video stream is 263 now in use. 265 SDP9 266 m=audio 31000 RTP/AVP 0 267 c=IN IP4 192.0.2.5 268 m=video 30002 RTP/AVP 31 269 c=IN IP4 192.0.2.5 271 SDP10: 272 m=audio 30000 RTP/AVP 0 273 c=IN IP4 192.0.2.2 274 m=video 30002 RTP/AVP 31 275 c=IN IP4 192.0.2.2 277 4. Tradeoff between Being Bandwidth Efficient and Having Explicit 278 Signalling 280 In order to have explicit SIP signalling about the media-level state, 281 UAs need to perform more offer/answer exchanges. Those offer/answer 282 exchanges consume bandwidth. For instance, in the previous example, 283 the price to pay for having explicit SIP signalling was the last two 284 UPDATE transactions. UAs should consider this tradeoff when deciding 285 how to behave in a particular network setting. 287 5. Security Considerations 289 This document does not introduce any new security issues. Security 290 issues related to preconditions are discussed in RFC 3312 [RFC3312] 291 and RFC 4032 [RFC4032]. 293 6. IANA Considerations 295 There are no IANA actions associated with this document. 297 7. Acknowledgements 299 Paul Kyzivat, Christer Holmberg, and Yang Gao provided useful ideas 300 on the topics discussed in this document. 302 8. Normative References 304 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 305 A., Peterson, J., Sparks, R., Handley, M., and E. 307 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 308 June 2002. 310 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 311 "Integration of Resource Management and Session Initiation 312 Protocol (SIP)", RFC 3312, October 2002. 314 [RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session 315 Initiation Protocol (SIP) Preconditions Framework", 316 RFC 4032, March 2005. 318 Authors' Addresses 320 Gonzalo Camarillo 321 Ericsson 322 Hirsalantie 11 323 Jorvas 02420 324 Finland 326 Email: Gonzalo.Camarillo@ericsson.com 328 Jouni Maenpaa 329 Ericsson 330 Hirsalantie 11 331 Jorvas 02420 332 Finland 334 Email: Jouni.Maenpaa@ericsson.com 336 Gao Yang 337 ZTE 338 China 340 Email: gao.yang2@zte.com.cn