idnits 2.17.1 draft-ietf-sipping-transc-conf-02.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 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 484. ** 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 (January 16, 2006) is 6668 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. '6') ** Obsolete normative reference: RFC 3850 (ref. '7') (Obsoleted by RFC 5750) ** Downref: Normative reference to an Informational RFC: RFC 4117 (ref. '8') -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-04 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-uri-list-conferencing-04 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-25 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-consent-framework-03 Summary: 7 errors (**), 0 flaws (~~), 7 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: July 20, 2006 January 16, 2006 6 The Session Initiation Protocol (SIP) Conference Bridge Transcoding 7 Model 8 draft-ietf-sipping-transc-conf-02.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 July 20, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 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. Procedures at the User Agent . . . . . . . . . . . . . . . 4 52 3.2. Procedures at the Transcoder . . . . . . . . . . . . . . . 4 53 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.4. Unsuccessful Session Establishment . . . . . . . . . . . . 7 55 4. Callee's Invocation . . . . . . . . . . . . . . . . . . . . . 8 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 61 8.2. Informational References . . . . . . . . . . . . . . . . . 11 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 Intellectual Property and Copyright Statements . . . . . . . . . . 13 65 1. Introduction 67 The Framework for Transcoding with SIP [9] describes how two SIP [3] 68 UAs (User Agents) can discover imcompatibilities that prevent them 69 from establishing a session (e.g., lack of support for a common codec 70 or for a common media type). When such incompatibilities are found, 71 the UAs need to invoke transcoding services to successfully establish 72 the session. The transcoding framework introduces two models to 73 invoke transcoding services: the 3pcc (third-party call control) 74 model [8] and the conference bridge model. This document specifies 75 the conference bridge model. 77 In the conference bridge model for transcoding invocation, a 78 transcoding server that provides a particular transcoding service 79 (e.g., speech-to-text) behaves as a B2BUA (Back-to-Back User Agent) 80 between both UAs and is identified by a URI. As shown in Figure 1, 81 both UAs, A and B, exchange signalling and media with the transcoder 82 T. The UAs do not exchange any traffic (signalling or media) directly 83 between them. 85 +-------+ 86 | |** 87 | T | ** 88 | |\ ** 89 +-------+ \\ ** 90 ^ * \\ ** 91 | * \\ ** 92 | * SIP ** 93 SIP * \\ ** 94 | * \\ ** 95 | * \\ ** 96 v * \ ** 97 +-------+ +-------+ 98 | | | | 99 | A | | B | 100 | | | | 101 +-------+ +-------+ 103 <-SIP-> Signalling 104 ******* Media 106 Figure 1: Conference bridge model 108 Section 3 and Section 4 specify how the caller A or the callee B, 109 respectively, can use the conference bridge model to invoke 110 transcoding services from T. 112 2. Terminology 114 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 115 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 116 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 117 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 118 compliant implementations. 120 3. Caller's Invocation 122 User agent A needs to perform two operations to invoke transcoding 123 services from T for a session between user agent A and user agent B. 124 User agent A needs to establish a session with T and provide T with 125 user agent B's URI so that T can generate an INVITE towards user 126 agent B. 128 3.1. Procedures at the User Agent 130 User agent A uses the procedures for Conference Establishment Using 131 Request-Contained Lists in SIP [11] to provide T with B's URI using 132 the same INVITE that establishes the session between A and T. That 133 is, user agent A adds to the INVITE a body part whose disposition 134 type is recipient-list [10]. This body part consists of a URI-list 135 that MUST contain a single URI: user agent B's URI. 137 3.2. Procedures at the Transcoder 139 On receiving an INVITE with a URI-list body, the transcoder follows 140 the procedures in [11] to generate an INVITE request towards the URI 141 contained in the URI-list body. Note that the transcoder acts as a 142 B2BUA, not as a proxy. 144 Additionally, the transcoder MUST generate the From header field of 145 the outgoing INVITE request using the same value as the From header 146 field included in the incoming INVITE request, subject to the privacy 147 requirements (see [5] and [6]) expressed in the incoming INVITE 148 request. Note that this does not apply to the "tag" parameter. 150 The session description the transcoder includes in the outgoing 151 INVITE request depends on the type of transcoding service that 152 particular transcoder provides. For example, a transcoder resolving 153 audio codec incompatibilities would generate a session description 154 listing the audio codecs the transcoder supports. 156 When the transcoder receives a final response for the outgoing INVITE 157 requests, it generates a new final response for the incoming INVITE 158 request. This new final response SHOULD have the same status code as 159 the one received in the response for the outgoing INVITE request. 161 If a trancoder receives an INVITE request with a URI-list with more 162 than one URI, it SHOULD return a 488 (Max 1 URI allowed in URI-list) 163 response. 165 3.3. Example 167 Figure 2 shows the message flow for the caller's invocation of a 168 transcoder T. The caller A sends an INVITE (1) to the transcoder (T) 169 to establish the session A-T. Following the procedures in [11], the 170 caller A adds a body part whose disposition type is recipient-list 171 [10]. 173 A T B 174 | | | 175 |-----(1) INVITE SDP A----->| | 176 | | | 177 |<-(2) 183 Session Progress-| | 178 | |-----(3) INVITE SDP TB---->| 179 | | | 180 | |<-----(4) 200 OK SDP B-----| 181 | | | 182 | |---------(5) ACK---------->| 183 |<----(6) 200 OK SDP TA-----| | 184 | | | 185 |---------(7) ACK---------->| | 186 | | | 187 | ************************* | ************************* | 188 |** Media **|** Media **| 189 | ************************* | ************************* | 190 | | | 192 Figure 2: Successful invocation of a transcoder by the caller 194 The following example shows an INVITE with two body parts: an SDP 195 [14] session description and a URI-list. 197 INVITE sip:transcoder@example.com SIP/2.0 198 Via: SIP/2.0/TCP client.chicago.example.com 199 ;branch=z9hG4bKhjhs8ass83 200 Max-Forwards: 70 201 To: Transcoder 202 From: A ;tag=32331 203 Call-ID: d432fa84b4c76e66710 204 CSeq: 1 INVITE 205 Contact: 206 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 207 SUBSCRIBE, NOTIFY 208 Allow-Events: dialog 209 Accept: application/sdp, message/sipfrag 210 Require: recipient-list-invite 211 Content-Type: multipart/mixed;boundary="boundary1" 212 Content-Length: 556 214 --boundary1 215 Content-Type: application/sdp 217 v=0 218 o=example 2890844526 2890842807 IN IP4 chicago.example.com 219 s=- 220 c=IN IP4 192.0.2.1 221 t=0 0 222 m=audio 50000 RTP/AVP 0 223 a=rtpmap:0 PCMU/8000 225 --boundary1 226 Content-Type: application/resource-lists+xml 227 Content-Disposition: recipient-list 229 230 232 233 234 235 236 --boundary1-- 238 On receiving the INVITE, the transcoder generates a new INVITE 239 towards the callee. The transcoder acts as a B2BUA, not as a proxy. 240 Therefore, this new INVITE (3) belongs to a different transaction 241 than the INVITE (1) received by the transcoder. 243 When the transcoder receives a final response (4) from the callee, it 244 generates a new final response (6) for INVITE (1). This new final 245 response (6) has the same status code as the one received in the 246 response from the callee (4). 248 3.4. Unsuccessful Session Establishment 250 Figure 3 shows a similar message flow as the one in Figure 3. 251 Nevertheless, this time the callee generates a non-2xx final response 252 (4). Consequently, the transcoder generates a non-2xx final response 253 (6) towards the caller as well. 255 A T B 256 | | | 257 |-----(1) INVITE SDP A----->| | 258 | | | 259 |<-(2) 183 Session Progress-| | 260 | |-----(3) INVITE SDP TB---->| 261 | | | 262 | |<----(4) 603 Decline-------| 263 | | | 264 | |---------(5) ACK---------->| 265 |<----(6) 603 Decline-------| | 266 | | | 267 |---------(7) ACK---------->| | 268 | | | 270 Figure 3: Unsuccessful session establishment 272 The ambiguity in this flow is that, if the provisional response (2) 273 gets lost, the caller does not know whether the 603 (Decline) 274 response means that the initial INVITE (1) was rejected by the 275 transcoder or that the INVITE generated by the transcoder (4) was 276 rejected by the callee. The use of the "History-Info" header field 277 [12] between the transcoder and the caller resolves the previous 278 ambiguity. 280 Callers that do not support the "History-Info" header field can, 281 alternatively, require the use of the reliable provisional responses 282 [4] SIP extension. If the caller receives a response reporting a 283 reachability problem, the caller can also send an OPTIONS request to 284 the transcoder to check whether or not the transcoder is reachable. 285 If the transcoder is reachable, the party that could not be reached 286 was the callee. 288 Note that this ambiguity problem could also have been resolved by 289 having transcoders act as a pure conference bridge. The transcoder 290 would respond with a 200 (OK) the INVITE request from the caller and 291 generate an outgoing INVITE request towards the callee. The caller 292 would get information about the result of the latter INVITE request 293 by subscribing to the conference event package [15] at the 294 transcoder. Nevertheless, while this flow would have resolved the 295 ambiguity problem without requiring support for the "History-Info" 296 header field, it is more complex, requires a higher number on 297 messages, and introduces higher session setup delays. That is why it 298 was not chosen to implement transcoding services. 300 4. Callee's Invocation 302 If a UA receives an INVITE with a session description that is not 303 acceptable, it can redirect it to the transcoder by using a 302 304 (Moved Temporarily) response. The Contact header field of the 302 305 (Moved Temporarily) response contains the URI of the transcoder plus 306 a "?body=" parameter. This parameter contains a recipient-list body 307 with B's URI. Note that some escaping (e.g., for Carriage Returns 308 and Line Feeds) is needed to encode a recipient-list body in such a 309 parameter. Figure 4 shows the message flow for this scenario. 311 A T B 312 | | | 313 |-------------------(1) INVITE SDP A------------------->| 314 | | | 315 |<--------------(2) 302 Moved Temporarily---------------| 316 | | | 317 |-----------------------(3) ACK------------------------>| 318 | | | 319 |-----(4) INVITE SDP A----->| | 320 | | | 321 |<-(5) 183 Session Progress-| | 322 | |-----(6) INVITE SDP TB---->| 323 | | | 324 | |<-----(7) 200 OK SDP B-----| 325 | | | 326 | |---------(8) ACK---------->| 327 |<----(9) 200 OK SDP TA-----| | 328 | | | 329 |--------(10) ACK---------->| | 330 | | | 331 | ************************* | ************************* | 332 |** Media **|** Media **| 333 | ************************* | ************************* | 335 Figure 4: Callee's invocation of a transcoder 337 Note that A does not necessarily need to be the one performing the 338 recursion on the 302 (Moved Temporarily) response. Any proxy in the 339 path between A and B may perform such a recursion. 341 5. Security Considerations 343 Transcoders implementing this specification behave as a URI-list 344 service as described in [11]. Therefore, the security considerations 345 for URI-list services discussed in [10] apply here as well. 347 In particular, the requirements related to list integrity and 348 unsolicited requests are important for transcoding services. User 349 agents SHOULD integrity protect URI-lists using mechanisms such as 350 S/MIME [7] or TLS [2], which can also provide URI-list 351 confidentiality if needed. Additionally, transcoders MUST 352 authenticate and authorize users and MAY provide information about 353 the identity of the original sender of the request in their outgoing 354 requests by using the SIP identity mechanism [13]. 356 The requirement in [10] to use opt-in lists (e.g., using the 357 Framework for Consent-Based Communications in SIP [16]) deserves 358 special discussion. The type of URI-list service implemented by 359 transcoders following this specification does not produce 360 amplification (only one INVITE request is generated by the transcoder 361 on receiving an INVITE request from a user agent) and does not 362 involve a translation to a URI that may be otherwise unknown to the 363 caller (the caller places the callee's URI in the body of its initial 364 INVITE request). Additionally, the identity of the caller is present 365 in the INVITE request generated by the transcoder. Therefore, there 366 is no requirement for transcoders implementing this specification to 367 use opt-in lists. 369 6. IANA Considerations 371 This document does not contain any IANA actions. 373 7. Contributors 375 This document is the result of discussions amongst the conferencing 376 design team. The members of this team include Eric Burger, Henning 377 Schulzrinne, and Arnoud van Wijk. 379 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] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 393 Responses in Session Initiation Protocol (SIP)", RFC 3262, 394 June 2002. 396 [5] Peterson, J., "A Privacy Mechanism for the Session Initiation 397 Protocol (SIP)", RFC 3323, November 2002. 399 [6] Jennings, C., Peterson, J., and M. Watson, "Private Extensions 400 to the Session Initiation Protocol (SIP) for Asserted Identity 401 within Trusted Networks", RFC 3325, November 2002. 403 [7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 404 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, 405 July 2004. 407 [8] Camarillo, G., Burger, E., Schulzrinne, H., and A. van Wijk, 408 "Transcoding Services Invocation in the Session Initiation 409 Protocol (SIP) Using Third Party Call Control (3pcc)", 410 RFC 4117, June 2005. 412 [9] Camarillo, G., "Framework for Transcoding with the Session 413 Initiation Protocol", 414 draft-camarillo-sipping-transc-framework-00 (work in progress), 415 August 2003. 417 [10] Camarillo, G. and A. Roach, "Framework and Security 418 Considerations for Session Initiation Protocol (SIP) Uniform 419 Resource Identifier (URI)-List Services", 420 draft-ietf-sipping-uri-services-04 (work in progress), 421 October 2005. 423 [11] Camarillo, G. and A. Johnston, "Conference Establishment Using 424 Request-Contained Lists in the Session Initiation Protocol 425 (SIP)", draft-ietf-sipping-uri-list-conferencing-04 (work in 426 progress), October 2005. 428 [12] Barnes, M., "An Extension to the Session Initiation Protocol 429 for Request History Information", 430 draft-ietf-sip-history-info-06 (work in progress), 431 January 2005. 433 [13] Peterson, J. and C. Jennings, "Enhancements for Authenticated 434 Identity Management in the Session Initiation Protocol (SIP)", 435 draft-ietf-sip-identity-06 (work in progress), October 2005. 437 8.2. Informational References 439 [14] Handley, M., "SDP: Session Description Protocol", 440 draft-ietf-mmusic-sdp-new-25 (work in progress), July 2005. 442 [15] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 443 Package for Conference State", 444 draft-ietf-sipping-conference-package-12 (work in progress), 445 July 2005. 447 [16] Rosenberg, J., "A Framework for Consent-Based Communications in 448 the Session Initiation Protocol (SIP)", 449 draft-ietf-sipping-consent-framework-03 (work in progress), 450 October 2005. 452 Author's Address 454 Gonzalo Camarillo 455 Ericsson 456 Hirsalantie 11 457 Jorvas 02420 458 Finland 460 Email: Gonzalo.Camarillo@ericsson.com 462 Intellectual Property Statement 464 The IETF takes no position regarding the validity or scope of any 465 Intellectual Property Rights or other rights that might be claimed to 466 pertain to the implementation or use of the technology described in 467 this document or the extent to which any license under such rights 468 might or might not be available; nor does it represent that it has 469 made any independent effort to identify any such rights. Information 470 on the procedures with respect to rights in RFC documents can be 471 found in BCP 78 and BCP 79. 473 Copies of IPR disclosures made to the IETF Secretariat and any 474 assurances of licenses to be made available, or the result of an 475 attempt made to obtain a general license or permission for the use of 476 such proprietary rights by implementers or users of this 477 specification can be obtained from the IETF on-line IPR repository at 478 http://www.ietf.org/ipr. 480 The IETF invites any interested party to bring to its attention any 481 copyrights, patents or patent applications, or other proprietary 482 rights that may cover technology that may be required to implement 483 this standard. Please address the information to the IETF at 484 ietf-ipr@ietf.org. 486 Disclaimer of Validity 488 This document and the information contained herein are provided on an 489 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 490 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 491 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 492 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 493 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 494 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 496 Copyright Statement 498 Copyright (C) The Internet Society (2006). This document is subject 499 to the rights, licenses and restrictions contained in BCP 78, and 500 except as set forth therein, the authors retain all their rights. 502 Acknowledgment 504 Funding for the RFC Editor function is currently provided by the 505 Internet Society.