idnits 2.17.1 draft-ietf-sipping-transc-conf-03.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 480. ** 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 (May 22, 2006) is 6548 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. '2') (Obsoleted by RFC 4346) ** Downref: Normative reference to an Informational RFC: RFC 3325 (ref. '5') ** Obsolete normative reference: RFC 3850 (ref. '6') (Obsoleted by RFC 5750) ** Downref: Normative reference to an Informational RFC: RFC 4117 (ref. '7') -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-05 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-05) exists of draft-ietf-sipping-consent-framework-04 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: November 23, 2006 May 22, 2006 5 The Session Initiation Protocol (SIP) Conference Bridge Transcoding 6 Model 7 draft-ietf-sipping-transc-conf-03.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 23, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes how to invoke transcoding services using the 41 conference bridge model. This way of invocation meets the 42 requirements for SIP regarding transcoding services invocation to 43 support deaf, hard of hearing and speech-impaired individuals. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. Caller's Invocation . . . . . . . . . . . . . . . . . . . . . 4 50 3.1. Procedures at the User Agent . . . . . . . . . . . . . . . 4 51 3.2. Procedures at the Transcoder . . . . . . . . . . . . . . . 4 52 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.4. Unsuccessful Session Establishment . . . . . . . . . . . . 7 54 4. Callee's Invocation . . . . . . . . . . . . . . . . . . . . . 8 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 60 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 Intellectual Property and Copyright Statements . . . . . . . . . . 13 64 1. Introduction 66 The Framework for Transcoding with SIP [8] describes how two SIP [3] 67 UAs (User Agents) can discover imcompatibilities that prevent them 68 from establishing a session (e.g., lack of support for a common codec 69 or for a common media type). When such incompatibilities are found, 70 the UAs need to invoke transcoding services to successfully establish 71 the session. The transcoding framework introduces two models to 72 invoke transcoding services: the 3pcc (third-party call control) 73 model [7] and the conference bridge model. This document specifies 74 the conference bridge model. 76 In the conference bridge model for transcoding invocation, a 77 transcoding server that provides a particular transcoding service 78 (e.g., speech-to-text) behaves as a B2BUA (Back-to-Back User Agent) 79 between both UAs and is identified by a URI. As shown in Figure 1, 80 both UAs, A and B, exchange signalling and media with the transcoder 81 T. The UAs do not exchange any traffic (signalling or media) directly 82 between them. 84 +-------+ 85 | |** 86 | T | ** 87 | |\ ** 88 +-------+ \\ ** 89 ^ * \\ ** 90 | * \\ ** 91 | * SIP ** 92 SIP * \\ ** 93 | * \\ ** 94 | * \\ ** 95 v * \ ** 96 +-------+ +-------+ 97 | | | | 98 | A | | B | 99 | | | | 100 +-------+ +-------+ 102 <-SIP-> Signalling 103 ******* Media 105 Figure 1: Conference bridge model 107 Section 3 and Section 4 specify how the caller A or the callee B, 108 respectively, can use the conference bridge model to invoke 109 transcoding services from T. 111 2. Terminology 113 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 114 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 115 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 116 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 117 compliant implementations. 119 3. Caller's Invocation 121 User agent A needs to perform two operations to invoke transcoding 122 services from T for a session between user agent A and user agent B. 123 User agent A needs to establish a session with T and provide T with 124 user agent B's URI so that T can generate an INVITE towards user 125 agent B. 127 3.1. Procedures at the User Agent 129 User agent A uses the procedures for Conference Establishment Using 130 Request-Contained Lists in SIP [10] to provide T with B's URI using 131 the same INVITE that establishes the session between A and T. That 132 is, user agent A adds to the INVITE a body part whose disposition 133 type is recipient-list [9]. This body part consists of a URI-list 134 that contains a single URI: user agent B's URI. 136 Note that, as described in the transcoding framework [8], the 137 transcoding model described in this document is modeled as a two- 138 party conference server. Consequently, this document focuses on 139 two-party sessions that need transcoding. Multi-party sessions 140 can be established using INVITE requests with multiple URIs in 141 their bodies, as specified in [10]. 143 3.2. Procedures at the Transcoder 145 On receiving an INVITE with a URI-list body, the transcoder follows 146 the procedures in [10] to generate an INVITE request towards the URI 147 contained in the URI-list body. Note that the transcoder acts as a 148 B2BUA, not as a proxy. 150 Additionally, the transcoder MUST generate the From header field of 151 the outgoing INVITE request using the same value as the From header 152 field included in the incoming INVITE request, subject to the privacy 153 requirements (see [4] and [5]) expressed in the incoming INVITE 154 request. Note that this does not apply to the "tag" parameter. 156 The session description the transcoder includes in the outgoing 157 INVITE request depends on the type of transcoding service that 158 particular transcoder provides. For example, a transcoder resolving 159 audio codec incompatibilities would generate a session description 160 listing the audio codecs the transcoder supports. 162 When the transcoder receives a final response for the outgoing INVITE 163 requests, it generates a new final response for the incoming INVITE 164 request. This new final response SHOULD have the same status code as 165 the one received in the response for the outgoing INVITE request. 167 If a trancoder receives an INVITE request with a URI-list with more 168 than one URI, it SHOULD return a 488 (Max 1 URI allowed in URI-list) 169 response. 171 3.3. Example 173 Figure 2 shows the message flow for the caller's invocation of a 174 transcoder T. The caller A sends an INVITE (1) to the transcoder (T) 175 to establish the session A-T. Following the procedures in [10], the 176 caller A adds a body part whose disposition type is recipient-list 177 [9]. 179 A T B 180 | | | 181 |-----(1) INVITE SDP A----->| | 182 | | | 183 |<-(2) 183 Session Progress-| | 184 | |-----(3) INVITE SDP TB---->| 185 | | | 186 | |<-----(4) 200 OK SDP B-----| 187 | | | 188 | |---------(5) ACK---------->| 189 |<----(6) 200 OK SDP TA-----| | 190 | | | 191 |---------(7) ACK---------->| | 192 | | | 193 | ************************* | ************************* | 194 |** Media **|** Media **| 195 | ************************* | ************************* | 196 | | | 198 Figure 2: Successful invocation of a transcoder by the caller 200 The following example shows an INVITE with two body parts: an SDP 201 [13] session description and a URI-list. 203 INVITE sip:transcoder@example.com SIP/2.0 204 Via: SIP/2.0/TCP client.chicago.example.com 205 ;branch=z9hG4bKhjhs8ass83 206 Max-Forwards: 70 207 To: Transcoder 208 From: A ;tag=32331 209 Call-ID: d432fa84b4c76e66710 210 CSeq: 1 INVITE 211 Contact: 212 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 213 SUBSCRIBE, NOTIFY 214 Allow-Events: dialog 215 Accept: application/sdp, message/sipfrag 216 Require: recipient-list-invite 217 Content-Type: multipart/mixed;boundary="boundary1" 218 Content-Length: 556 220 --boundary1 221 Content-Type: application/sdp 223 v=0 224 o=example 2890844526 2890842807 IN IP4 chicago.example.com 225 s=- 226 c=IN IP4 192.0.2.1 227 t=0 0 228 m=audio 50000 RTP/AVP 0 229 a=rtpmap:0 PCMU/8000 231 --boundary1 232 Content-Type: application/resource-lists+xml 233 Content-Disposition: recipient-list 235 236 238 239 240 241 242 --boundary1-- 244 On receiving the INVITE, the transcoder generates a new INVITE 245 towards the callee. The transcoder acts as a B2BUA, not as a proxy. 246 Therefore, this new INVITE (3) belongs to a different transaction 247 than the INVITE (1) received by the transcoder. 249 When the transcoder receives a final response (4) from the callee, it 250 generates a new final response (6) for INVITE (1). This new final 251 response (6) has the same status code as the one received in the 252 response from the callee (4). 254 3.4. Unsuccessful Session Establishment 256 Figure 3 shows a similar message flow as the one in Figure 3. 257 Nevertheless, this time the callee generates a non-2xx final response 258 (4). Consequently, the transcoder generates a non-2xx final response 259 (6) towards the caller as well. 261 A T B 262 | | | 263 |-----(1) INVITE SDP A----->| | 264 | | | 265 |<-(2) 183 Session Progress-| | 266 | |-----(3) INVITE SDP TB---->| 267 | | | 268 | |<----(4) 603 Decline-------| 269 | | | 270 | |---------(5) ACK---------->| 271 |<----(6) 603 Decline-------| | 272 | | | 273 |---------(7) ACK---------->| | 274 | | | 276 Figure 3: Unsuccessful session establishment 278 The ambiguity in this flow is that, if the provisional response (2) 279 gets lost, the caller does not know whether the 603 (Decline) 280 response means that the initial INVITE (1) was rejected by the 281 transcoder or that the INVITE generated by the transcoder (4) was 282 rejected by the callee. The use of the "History-Info" header field 283 [11] between the transcoder and the caller resolves the previous 284 ambiguity. 286 Note that this ambiguity problem could also have been resolved by 287 having transcoders act as a pure conference bridge. The transcoder 288 would respond with a 200 (OK) the INVITE request from the caller and 289 generate an outgoing INVITE request towards the callee. The caller 290 would get information about the result of the latter INVITE request 291 by subscribing to the conference event package [14] at the 292 transcoder. Nevertheless, while this flow would have resolved the 293 ambiguity problem without requiring support for the "History-Info" 294 header field, it is more complex, requires a higher number on 295 messages, and introduces higher session setup delays. That is why it 296 was not chosen to implement transcoding services. 298 4. Callee's Invocation 300 If a UA receives an INVITE with a session description that is not 301 acceptable, it can redirect it to the transcoder by using a 302 302 (Moved Temporarily) response. The Contact header field of the 302 303 (Moved Temporarily) response contains the URI of the transcoder plus 304 a "?body=" parameter. This parameter contains a recipient-list body 305 with B's URI. Note that some escaping (e.g., for Carriage Returns 306 and Line Feeds) is needed to encode a recipient-list body in such a 307 parameter. Figure 4 shows the message flow for this scenario. 309 A T B 310 | | | 311 |-------------------(1) INVITE SDP A------------------->| 312 | | | 313 |<--------------(2) 302 Moved Temporarily---------------| 314 | | | 315 |-----------------------(3) ACK------------------------>| 316 | | | 317 |-----(4) INVITE SDP A----->| | 318 | | | 319 |<-(5) 183 Session Progress-| | 320 | |-----(6) INVITE SDP TB---->| 321 | | | 322 | |<-----(7) 200 OK SDP B-----| 323 | | | 324 | |---------(8) ACK---------->| 325 |<----(9) 200 OK SDP TA-----| | 326 | | | 327 |--------(10) ACK---------->| | 328 | | | 329 | ************************* | ************************* | 330 |** Media **|** Media **| 331 | ************************* | ************************* | 333 Figure 4: Callee's invocation of a transcoder 335 Note that the syntax resulting from encoding a body into a URI as 336 described earlier is quite complex. It is actually simpler for 337 callees to invoke transcoding services using the 3pcc transcoding 338 model [7] instead. 340 5. Security Considerations 342 Transcoders implementing this specification behave as a URI-list 343 service as described in [10]. Therefore, the security considerations 344 for URI-list services discussed in [9] apply here as well. 346 In particular, the requirements related to list integrity and 347 unsolicited requests are important for transcoding services. User 348 agents SHOULD integrity protect URI-lists using mechanisms such as 349 S/MIME [6] or TLS [2], which can also provide URI-list 350 confidentiality if needed. Additionally, transcoders MUST 351 authenticate and authorize users and MAY provide information about 352 the identity of the original sender of the request in their outgoing 353 requests by using the SIP identity mechanism [12]. 355 The requirement in [9] to use opt-in lists (e.g., using the Framework 356 for Consent-Based Communications in SIP [15]) deserves special 357 discussion. The type of URI-list service implemented by transcoders 358 following this specification does not produce amplification (only one 359 INVITE request is generated by the transcoder on receiving an INVITE 360 request from a user agent) and does not involve a translation to a 361 URI that may be otherwise unknown to the caller (the caller places 362 the callee's URI in the body of its initial INVITE request). 363 Additionally, the identity of the caller is present in the INVITE 364 request generated by the transcoder. Therefore, there is no 365 requirement for transcoders implementing this specification to use 366 opt-in lists. 368 6. IANA Considerations 370 This document does not contain any IANA actions. 372 7. Contributors 374 This document is the result of discussions amongst the conferencing 375 design team. The members of this team include Eric Burger, Henning 376 Schulzrinne, and Arnoud van Wijk. 378 8. References 380 8.1. Normative References 382 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 383 Levels", BCP 14, RFC 2119, March 1997. 385 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 386 RFC 2246, January 1999. 388 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 389 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 390 Session Initiation Protocol", RFC 3261, June 2002. 392 [4] Peterson, J., "A Privacy Mechanism for the Session Initiation 393 Protocol (SIP)", RFC 3323, November 2002. 395 [5] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 396 to the Session Initiation Protocol (SIP) for Asserted Identity 397 within Trusted Networks", RFC 3325, November 2002. 399 [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 400 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, 401 July 2004. 403 [7] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, 404 "Transcoding Services Invocation in the Session Initiation 405 Protocol (SIP) Using Third Party Call Control (3pcc)", 406 RFC 4117, June 2005. 408 [8] Camarillo, G., "Framework for Transcoding with the Session 409 Initiation Protocol", 410 draft-camarillo-sipping-transc-framework-00 (work in progress), 411 August 2003. 413 [9] Camarillo, G. and A. Roach, "Framework and Security 414 Considerations for Session Initiation Protocol (SIP) Uniform 415 Resource Identifier (URI)-List Services", 416 draft-ietf-sipping-uri-services-05 (work in progress), 417 January 2006. 419 [10] Camarillo, G. and A. Johnston, "Conference Establishment Using 420 Request-Contained Lists in the Session Initiation Protocol 421 (SIP)", draft-ietf-sipping-uri-list-conferencing-05 (work in 422 progress), February 2006. 424 [11] Barnes, M., "An Extension to the Session Initiation Protocol 425 for Request History Information", 426 draft-ietf-sip-history-info-06 (work in progress), 427 January 2005. 429 [12] Peterson, J. and C. Jennings, "Enhancements for Authenticated 430 Identity Management in the Session Initiation Protocol (SIP)", 431 draft-ietf-sip-identity-06 (work in progress), October 2005. 433 8.2. Informative References 435 [13] Handley, M., "SDP: Session Description Protocol", 436 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 438 [14] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 439 Package for Conference State", 440 draft-ietf-sipping-conference-package-12 (work in progress), 441 July 2005. 443 [15] Rosenberg, J., "A Framework for Consent-Based Communications in 444 the Session Initiation Protocol (SIP)", 445 draft-ietf-sipping-consent-framework-04 (work in progress), 446 March 2006. 448 Author's Address 450 Gonzalo Camarillo 451 Ericsson 452 Hirsalantie 11 453 Jorvas 02420 454 Finland 456 Email: Gonzalo.Camarillo@ericsson.com 458 Intellectual Property Statement 460 The IETF takes no position regarding the validity or scope of any 461 Intellectual Property Rights or other rights that might be claimed to 462 pertain to the implementation or use of the technology described in 463 this document or the extent to which any license under such rights 464 might or might not be available; nor does it represent that it has 465 made any independent effort to identify any such rights. Information 466 on the procedures with respect to rights in RFC documents can be 467 found in BCP 78 and BCP 79. 469 Copies of IPR disclosures made to the IETF Secretariat and any 470 assurances of licenses to be made available, or the result of an 471 attempt made to obtain a general license or permission for the use of 472 such proprietary rights by implementers or users of this 473 specification can be obtained from the IETF on-line IPR repository at 474 http://www.ietf.org/ipr. 476 The IETF invites any interested party to bring to its attention any 477 copyrights, patents or patent applications, or other proprietary 478 rights that may cover technology that may be required to implement 479 this standard. Please address the information to the IETF at 480 ietf-ipr@ietf.org. 482 Disclaimer of Validity 484 This document and the information contained herein are provided on an 485 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 486 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 487 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 488 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 489 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 490 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 492 Copyright Statement 494 Copyright (C) The Internet Society (2006). This document is subject 495 to the rights, licenses and restrictions contained in BCP 78, and 496 except as set forth therein, the authors retain all their rights. 498 Acknowledgment 500 Funding for the RFC Editor function is currently provided by the 501 Internet Society.