idnits 2.17.1 draft-ietf-sipping-transc-conf-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 385. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 1, 2005) is 6897 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) ** Obsolete normative reference: RFC 2246 (ref. '1') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3850 (ref. '2') (Obsoleted by RFC 5750) -- Possible downref: Normative reference to a draft: ref. '6' ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-transc-3pcc (ref. '7') == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-02 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-uri-list-conferencing-02 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-24 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: December 3, 2005 June 1, 2005 6 The Session Initiation Protocol (SIP) Conference Bridge Transcoding 7 Model 8 draft-ietf-sipping-transc-conf-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 3, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes how to invoke transcoding services using the 42 conference bridge model. This way of invocation meets the 43 requirements for SIP regarding transcoding services invocation to 44 support deaf, hard of hearing and speech-impaired individuals. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Caller's Invocation . . . . . . . . . . . . . . . . . . . . . 4 51 3.1 Unsuccessful Session Establishment . . . . . . . . . . . . 6 52 4. Callee's Invocation . . . . . . . . . . . . . . . . . . . . . 6 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 55 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 58 8.2 Informational References . . . . . . . . . . . . . . . . . 9 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 60 Intellectual Property and Copyright Statements . . . . . . . . 10 62 1. Introduction 64 The Framework for Transcoding with SIP [6] describes how two SIP [4] 65 UAs (User Agents) can discover imcompatibilities that prevent them 66 from establishing a session (e.g., lack of support for a common codec 67 or for a common media type). When such incompatibilities are found, 68 the UAs need to invoke transcoding services to successfully establish 69 the session. The transcoding framework introduces two models to 70 invoke transcoding services: the 3pcc (third-party call control) 71 model [7] and the conference bridge model. This document specifies 72 the conference bridge model. 74 In the conference bridge model for transcoding invocation, a 75 transcoding server that provides a particular transcoding service 76 (e.g., speech-to-text) behaves as a B2BUA (Back-to-Back User Agent) 77 between both UAs and is identified by a URI. As shown in Figure 1, 78 both UAs, A and B, exchange signalling and media with the transcoder 79 T. The UAs do not exchange any traffic (signalling or media) directly 80 between them. 82 +-------+ 83 | |** 84 | T | ** 85 | |\ ** 86 +-------+ \\ ** 87 ^ * \\ ** 88 | * \\ ** 89 | * SIP ** 90 SIP * \\ ** 91 | * \\ ** 92 | * \\ ** 93 v * \ ** 94 +-------+ +-------+ 95 | | | | 96 | A | | B | 97 | | | | 98 +-------+ +-------+ 100 <-SIP-> Signalling 101 ******* Media 103 Figure 1: Conference bridge model 105 Section 3 and Section 4 specify how the caller A or the callee B, 106 respectively, can use the conference bridge model to invoke 107 transcoding services from T. 109 2. Terminology 111 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 112 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 113 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 114 described in BCP 14, RFC 2119 [3] and indicate requirement levels for 115 compliant implementations. 117 3. Caller's Invocation 119 A needs to perform two operations to invoke transcoding services from 120 T for a session between A and B. A needs to establish a session with 121 T and provide T with B's URI so that T can generate an INVITE towards 122 B. A uses the procedures for Conference Establishment Using Request- 123 Contained Lists in SIP [9] to provide T with B's URI using the same 124 INVITE that establishes the session between A and T. 126 Figure 2 shows the message flow for the caller's invocation of a 127 transcoder T. The caller (A) sends an INVITE (1) to the transcoder 128 (T) to establish the session A-T. Following the procedures in [9], A 129 adds a body part whose disposition type is recipient-list [8]. This 130 body part consists of a URI-list that MUST contain a single URI: B's 131 URI. 133 If a trancoder receives a URI-list with more than one URI, it SHOULD 134 return a 488 (Max 1 URI allowed in URI-list) response. 136 A T B 137 | | | 138 |-----(1) INVITE SDP A----->| | 139 | | | 140 |<-(2) 183 Session Progress-| | 141 | |-----(3) INVITE SDP TB---->| 142 | | | 143 | |<-----(4) 200 OK SDP B-----| 144 | | | 145 | |---------(5) ACK---------->| 146 |<----(6) 200 OK SDP TA-----| | 147 | | | 148 |---------(7) ACK---------->| | 149 | | | 150 | ************************* | ************************* | 151 |** Media **|** Media **| 152 | ************************* | ************************* | 153 | | | 155 Figure 2: Successful invocation of a transcoder by the caller 157 The following example shows an INVITE with two body parts: an SDP 158 [10] session description and a URI-list. 160 INVITE sip:transcoder@example.com SIP/2.0 161 Via: SIP/2.0/TCP client.chicago.example.com 162 ;branch=z9hG4bKhjhs8ass83 163 Max-Forwards: 70 164 To: Transcoder 165 From: A ;tag=32331 166 Call-ID: d432fa84b4c76e66710 167 CSeq: 1 INVITE 168 Contact: 169 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 170 SUBSCRIBE, NOTIFY 171 Allow-Events: dialog 172 Accept: application/sdp, message/sipfrag 173 Require: recipient-list-invite 174 Conten-Type: multipart/mixed;boundary="boundary1" 175 Content-Length: xxx 177 --boundary1 178 Content-Type: application/sdp 180 v=0 181 o=example 2890844526 2890842807 IN IP4 chicago.example.com 182 s=- 183 c=IN IP4 192.0.2.1 184 t=0 0 185 m=audio 20000 RTP/AVP 0 186 a=rtpmap:0 PCMU/8000 188 --boundary1 189 Content-Type: application/resource-lists+xml 190 Content-Disposition: recipient-list 192 193 195 196 197 198 199 --boundary1-- 201 On receiving the INVITE, the transcoder generates a new INVITE 202 towards the callee. The transcoder acts as a B2BUA, not as a proxy. 203 Therefore, this new INVITE (3) belongs to a different transaction 204 than the INVITE (1) received by the transcoder. 206 When the transcoder receives a final response (4) from the callee, it 207 generates a new final response (6) for INVITE (1). This new final 208 response (6) SHOULD have the same status code as the one received in 209 the response from the callee (4). 211 3.1 Unsuccessful Session Establishment 213 Figure 3 shows a similar message flow as the one in Figure 3. 214 Nevertheless, this time the callee generates a non-2xx final response 215 (4). Consequently, the transcoder generates a non-2xx final response 216 (6) towards the caller as well. 218 A T B 219 | | | 220 |-----(1) INVITE SDP A----->| | 221 | | | 222 |<-(2) 183 Session Progress-| | 223 | |-----(3) INVITE SDP TB---->| 224 | | | 225 | |<----(4) 404 Not Found-----| 226 | | | 227 | |---------(5) ACK---------->| 228 |<----(6) 404 Not Found-----| | 229 | | | 230 |---------(7) ACK---------->| | 231 | | | 233 Figure 3: Unsuccessful session establishment 235 The ambiguity in this flow is that, if the provisional response (2) 236 gets lost, the caller does not know whether the 404 (Not Found) 237 response means that the initial INVITE (1) did not reach the 238 transcoder or that the INVITE generated by the transcoder (4) did not 239 reach the callee. To resolve this ambiguity, the callee can either 240 require the use of the reliable provisional responses [5] SIP 241 extension or send an OPTIONS request to the transcoder to check 242 whether it is reachable. 244 4. Callee's Invocation 246 If a UA receives an INVITE with an offer that is not acceptable, it 247 can redirect it to the transcoder by using a 302 (Moved Temporarily) 248 response. The Contact header field of the 302 (Moved Temporarily) 249 response contains the URI of the transcoder plus a "?body=" 250 parameter. This parameter contains a recipient-list body with B's 251 URI. Note that some escaping (e.g., for Carriage Returns and Line 252 Feeds) is needed to encode a recipient-list body in such a parameter. 253 Figure 4 shows the message flow for this scenario. 255 256 Please view in a fixed-width font such as Courier. 258 A T B 259 | | | 260 |-------------------(1) INVITE SDP A------------------->| 261 | | | 262 |<--------------(2) 302 Moved Temporarily---------------| 263 | | | 264 |-----------------------(3) ACK------------------------>| 265 | | | 266 |-----(4) INVITE SDP A----->| | 267 | | | 268 |<-(5) 183 Session Progress-| | 269 | |-----(6) INVITE SDP TB---->| 270 | | | 271 | |<-----(7) 200 OK SDP B-----| 272 | | | 273 | |---------(8) ACK---------->| 274 |<----(9) 200 OK SDP TA-----| | 275 | | | 276 |--------(10) ACK---------->| | 277 | | | 278 | ************************* | ************************* | 279 |** Media **|** Media **| 280 | ************************* | ************************* | 282 Figure 4: \{Callee's invocation of a transcoder 284 Note that A does not necessarily need to be the one performing the 285 recursion on the 302 (Moved Temporarily) response. Any proxy in the 286 path between A and B may perform such a recursion. 288 5. Security Considerations 290 TBD. 292 Need to mention how consent applies to this work when consent is more 293 mature. 295 Need to mention TLS [1] and S/MIME [2]. 297 6. IANA Considerations 299 This document does not contain any IANA actions. 301 7. Contributors 303 This document is the result of discussions amongst the conferencing 304 design team. The members of this team include Eric Burger, Henning 305 Schulzrinne and Arnoud van Wijk. 307 8. References 309 8.1 Normative References 311 [1] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 312 RFC 2246, January 1999. 314 [2] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 315 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004. 317 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 318 Levels", BCP 14, RFC 2119, March 1997. 320 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 321 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 322 Session Initiation Protocol", RFC 3261, June 2002. 324 [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 325 Responses in Session Initiation Protocol (SIP)", RFC 3262, 326 June 2002. 328 [6] Camarillo, G., "Framework for Transcoding with the Session 329 Initiation Protocol", 330 draft-camarillo-sipping-transc-framework-00 (work in progress), 331 August 2003. 333 [7] Camarillo, G., "Transcoding Services Invocation in the Session 334 Initiation Protocol (SIP) Using Third Party Call Control 335 (3pcc)", draft-ietf-sipping-transc-3pcc-02 (work in progress), 336 September 2004. 338 [8] Camarillo, G. and A. Roach, "Requirements and Framework for 339 Session Initiation Protocol (SIP)Uniform Resource Identifier 340 (URI)-List Services", draft-ietf-sipping-uri-services-02 (work 341 in progress), December 2004. 343 [9] Camarillo, G. and A. Johnston, "Conference Establishment Using 344 Request-Contained Lists in the Session Initiation Protocol 345 (SIP)", draft-ietf-sipping-uri-list-conferencing-02 (work in 346 progress), December 2004. 348 8.2 Informational References 350 [10] Handley, M., "SDP: Session Description Protocol", 351 draft-ietf-mmusic-sdp-new-24 (work in progress), February 2005. 353 Author's Address 355 Gonzalo Camarillo 356 Ericsson 357 Hirsalantie 11 358 Jorvas 02420 359 Finland 361 Email: Gonzalo.Camarillo@ericsson.com 363 Intellectual Property Statement 365 The IETF takes no position regarding the validity or scope of any 366 Intellectual Property Rights or other rights that might be claimed to 367 pertain to the implementation or use of the technology described in 368 this document or the extent to which any license under such rights 369 might or might not be available; nor does it represent that it has 370 made any independent effort to identify any such rights. Information 371 on the procedures with respect to rights in RFC documents can be 372 found in BCP 78 and BCP 79. 374 Copies of IPR disclosures made to the IETF Secretariat and any 375 assurances of licenses to be made available, or the result of an 376 attempt made to obtain a general license or permission for the use of 377 such proprietary rights by implementers or users of this 378 specification can be obtained from the IETF on-line IPR repository at 379 http://www.ietf.org/ipr. 381 The IETF invites any interested party to bring to its attention any 382 copyrights, patents or patent applications, or other proprietary 383 rights that may cover technology that may be required to implement 384 this standard. Please address the information to the IETF at 385 ietf-ipr@ietf.org. 387 Disclaimer of Validity 389 This document and the information contained herein are provided on an 390 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 391 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 392 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 393 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 394 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 395 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 397 Copyright Statement 399 Copyright (C) The Internet Society (2005). This document is subject 400 to the rights, licenses and restrictions contained in BCP 78, and 401 except as set forth therein, the authors retain all their rights. 403 Acknowledgment 405 Funding for the RFC Editor function is currently provided by the 406 Internet Society.