idnits 2.17.1 draft-camarillo-sipping-transc-b2bua-01.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 the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 227: '.... So, the callee SHOULD use the reliab...' RFC 2119 keyword, line 230: '...sion, the callee MAY send a 200 (OK) p...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 7, 2004) is 7384 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) -- Missing reference section? '1' on line 325 looks like a reference -- Missing reference section? '2' on line 330 looks like a reference -- Missing reference section? '3' on line 335 looks like a reference -- Missing reference section? '4' on line 339 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft G. Camarillo 4 Ericsson 5 draft-camarillo-sipping-transc-b2bua-01.txt 6 February 7, 2004 7 Expires: August, 2004 9 The Session Initiation Protocol Conference Bridge Transcoding Model 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes how to invoke transcoding services using the 35 conference bridge model. This way of invocation meets the 36 requirements for SIP regarding transcoding services invocation to 37 support deaf, hard of hearing and speech-impaired individuals. 39 Table of Contents 41 1 Introduction ........................................ 3 42 2 Caller's Invocation ................................. 3 43 2.1 Unsuccessful Session Establishment .................. 5 44 3 Callee's Invocation ................................. 6 45 4 Security Considerations ............................. 7 46 5 Contributors ........................................ 7 47 6 OPEN ISSUES ......................................... 7 48 7 Authors' Addresses .................................. 8 49 8 Bibliography ........................................ 9 51 1 Introduction 53 The framework for transcoding with SIP [1] (draft-ietf-sipping- 54 transc-framework) describes how two SIP UAs can discover 55 imcompatibilities that prevent them from establishing a session 56 (e.g., lack of support for a common codec or for a common media 57 type). When such incompatibilities are found, the UAs need to invoke 58 transcoding services to successfully establish the session. Using the 59 conference bridge model is one way to perform such invocation. 61 In the conference bridge model for transcoding invocation, a 62 transcoding server that provides a particular transcoding service 63 (e.g., speech-to-text) behaves as a B2BUA between both UAs and is 64 identified by a URI. 66 2 Caller's Invocation 68 Figure 1 shows the message flow for the caller's invocation of a 69 transcoder T. The caller (A) sends an INVITE (1) to the transcoder 70 (T) to establish the session A-T. The URI in the Request-URI of this 71 INVITE contains a list parameter, as defined in [2] (draft- 72 camarillo-sipping-uri-list-01), with a pointer to a URI list. This 73 URI list contains a single URI: the callee's URI, as shown below: 75 INVITE sip:transcoder@example.com;list=cid:cn35t8@example.com SIP/2.0 76 Via: SIP/2.0/TCP client.chicago.example.com 77 ;branch=z9hG4bKhjhs8ass83 78 Max-Forwards: 70 79 To: "Transcoder" 80 From: Caller ;tag=32331 81 Call-ID: d432fa84b4c76e66710 82 CSeq: 1 INVITE 83 Contact: 84 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 85 SUBSCRIBE, NOTIFY 86 Conten-Type: multipart/mixed;boundary="boundary1" 87 Content-Length: xxx 89 --boundary1 90 Content-Type: application/sdp 91 Content-Length: xxx 93 v=0 94 o=caller 2890844526 2890842807 IN IP4 chicago.example.com 95 s=Example Subject 96 c=IN IP4 192.0.0.1 97 t=0 0 98 m=audio 20000 RTP/AVP 0 100 --boundary1 101 Content-Type: application/resource-lists+xml 102 Content-Length: 367 103 Content-ID: 105 106 107 108 109 110 111 --boundary1-- 113 A T B 114 | | | 115 |-----(1) INVITE SDP A----->| | 116 | | | 117 |<-(2) 183 Session Progress-| | 118 | |-----(3) INVITE SDP TB---->| 119 | | | 120 | |<-----(4) 200 OK SDP B-----| 121 | | | 122 | |---------(5) ACK---------->| 123 |<----(6) 200 OK SDP TA-----| | 124 | | | 125 |---------(7) ACK---------->| | 126 | | | 127 | ************************* | ************************* | 128 |** Media **|** Media **| 129 | ************************* | ************************* | 130 | | | 132 Figure 1: Successful invocation of a transcoder by the caller 134 On reception of the INVITE, the transcoder generates a new INVITE 135 towards the callee. The transcoder acts as a B2BUA, so, this new 136 INVITE (3) belongs to a different transaction than the INVITE (1) 137 received by the transcoder. 139 When the transcoder receives a final response (4) from the callee, it 140 generates a new final response (6) for INVITE (1). This new final 141 response (6) has the same status code as the one received in the 142 response from the callee (4). 144 The advantage of this message flow is that, for both user agents, is 145 indentical to the flow for establishing a regular session (i.e., 146 without transcoder) between them. Additionaly, the only difference in 147 the message contents is that the caller needs to use a list parameter 148 in the Request-URI of the initial INVITE. 150 2.1 Unsuccessful Session Establishment 152 Figure 2 shows a similar message flow as the one in Figure 1. 153 Nevertheless, this time the callee generates a non-2xx final response 154 (4). Consequently, the transcoder generates a non-2xx final response 155 (6) towards the caller as well. 157 A T B 158 | | | 159 |-----(1) INVITE SDP A----->| | 160 | | | 161 |<-(2) 183 Session Progress-| | 162 | |-----(3) INVITE SDP TB---->| 163 | | | 164 | |<----(4) 404 Not Found-----| 165 | | | 166 | |---------(5) ACK---------->| 167 |<----(6) 404 Not Found-----| | 168 | | | 169 |---------(7) ACK---------->| | 170 | | | 172 Figure 2: Unsuccessful session establishment 174 The problem with this flow is that the caller does not know whether 175 the 404 (Not Found) response means that the initial INVITE (1) did 176 not reach the transcoder or that the INVITE generated by the 177 transcoder (4) did not reach the callee. To resolve this, it is 178 recommended that the caller uses the reliable provisional responses 179 [3] SIP extension. 181 Figure 3 shows the resulting message flow when the caller requires 182 the use of the reliable provisional responses [3] SIP extension. The 183 repection of the 183 (Session Progress) reliable provisional response 184 informs the caller that the transcoder was contacted susccessfully. 185 So, the 404 (Not Found) response indicates that the callee could not 186 be reached. 188 A T B 189 | | | 190 |--------(1) INVITE SDP A------>| | 191 | | | 192 |<-(2) 183 S. Prog. SDP on hold-| | 193 | |-----(3) INVITE SDP TB---->| 194 | | | 195 |-----------(4) PRACK---------->| | 196 | | | 197 |<----------(5) 200 OK----------| | 198 | | | 199 | |<----(6) 404 Not Found-----| 200 | | | 201 | |---------(7) ACK---------->| 202 |<-------(8) 404 Not Found------| | 203 | | | 204 |-------------(9) ACK---------->| | 205 | | | 207 Figure 3: Invocation using reliable provisional responses 209 3 Callee's Invocation 211 If a UA receives an INVITE with an offer that is not acceptable, it 212 can only invoke a transcoder if the caller supports the Replaces [4] 213 extension. This support is indicated by the Supported header field in 214 the INVITE. 216 If the caller (A) does not support Replaces, the callee (B) can 217 always reject the session and attempt to establish a new session with 218 A following the procedures in Section 2. This way, B would act as a 219 caller and, consequently, it would follow the procedures for caller's 220 invocation of transcoders. 222 Assuming that the caller (A) supports Replaces, the callee (B) 223 follows the steps shown in Figure 4 to invoke a transcoder. The 224 callee sends a 183 (Session Progress) response (2) to the caller. 225 This response carries a tag in the To header field. The caller needs 226 to receive this To tag so that this early dialog can be replaced 227 later in (5). So, the callee SHOULD use the reliable provisional 228 responses [3] SIP extension. The SDP in the 183 (Session Progress) 229 response may put the media streams on hold. If the caller did not 230 support this extension, the callee MAY send a 200 (OK) putting the 231 media streams on hold. 233 OPEN ISSUE: can we use 0.0.0.0 instead of hold here? 235 After returning a response with a To tag to the caller, the callee 236 sends an INVITE (2) to the Transcoder. The URI in the Request-URI of 237 this INVITE contains a list parameter, as defined in [2] (draft- 238 camarillo-sipping-uri-list-01), with a pointer to a URI list. This 239 URI list contains a single URI: the URI received in the Contact 240 header field of the initial INVITE (1) with an escaped Replaces 241 header field, as shown in the following example: 243 sip:caller@client.chicago.example.com?Replaces=40d432fa84b4c76e66710; 244 ;from-tag=32331 245 ;to-tag=12dr45 247 We recommend the use of the reliable provisional responses between 248 the callee and the transcoder so that the callee is able to 249 distinguish between problems with the transcoder and problems with 250 the caller, as we described in Section 2.1. 252 When A receives this INVITE (5), it replaces the original dialog (1) 253 with this new dialog. The caller sends a CANCEL (10) to cancel the 254 original dialog (1) and receives a 487 (Request Terminated) response 255 (11) from the callee. 257 4 Security Considerations 259 TBD. 261 5 Contributors 263 This document is the result of discussions amongst the conferencing 264 design team. The members of this team include Eric Burger, Henning 265 Schulzrinne and Arnoud van Wijk. 267 6 OPEN ISSUES 269 In SIP, the Route header field is used to traverse proxies, but is 270 seems that using it for traversing B2BUAs would be stretching its 271 semantics too much. 273 A T B 274 | | | 275 |----------------------(1) INVITE SDP A----------------------->| 276 | | | 277 |<-------------(2) 183 Session Progress SDP on hold------------| 278 | | | 279 |--------------------------(3) PRACK-------------------------->| 280 | | | 281 |<-------------------------(4) 200 OK--------------------------| 282 | | | 283 | |<----(5) INVITE SDP TB--------| 284 | | | 285 | |-(6) Session Progress SDP TB->| 286 | | | 287 | |<---------(7) PRACK-----------| 288 | | | 289 | |----------(8) 200 OK--------->| 290 | | | 291 |<------(9) INVITE SDP TA-------| | 292 | | | 293 |-------(10) 200 OK SDP A------>| | 294 | | | 295 |<-----------(11) ACK-----------| | 296 | |---------(12) 200 OK--------->| 297 | | | 298 | |<----------(13) ACK-----------| 299 | | | 300 |-------------------------(14) CANCEL------------------------->| 301 | | | 302 |<------------------------(15) 200 OK--------------------------| 303 | | | 304 |<------------------(16) 407 Request Terminated----------------+ 305 | | | 306 |---------------------------(17) ACK-------------------------->| 307 | | | 308 | ***************************** | **************************** | 309 |** Media **|** Media **| 310 | ***************************** | **************************** | 312 Figure 4: Callee's invocation of a transcoder 314 7 Authors' Addresses 316 Gonzalo Camarillo 317 Ericsson 318 Advanced Signalling Research Lab. 319 FIN-02420 Jorvas 320 Finland 321 electronic mail: Gonzalo.Camarillo@ericsson.com 323 8 Bibliography 325 [1] G. Camarillo, "Framework for transcoding with the session 326 initiation protocol," Internet Draft draft-camarillo-sipping-transc- 327 framework-00, Internet Engineering Task Force, Aug. 2003. Work in 328 progress. 330 [2] G. Camarillo, "Providing a session initiation protocol (SIP) 331 application server with a list of URIs," Internet Draft draft- 332 camarillo-sipping-uri-list-00, Internet Engineering Task Force, Nov. 333 2003. Work in progress. 335 [3] J. Rosenberg and H. Schulzrinne, "Reliability of provisional 336 responses in session initiation protocol (SIP)," RFC 3262, Internet 337 Engineering Task Force, June 2002. 339 [4] B. Biggs, R. W. Dean, and R. Mahy, "The session inititation 340 protocol (SIP) Engineering Task Force, Aug. 2003. Work in progress. 342 The IETF takes no position regarding the validity or scope of any 343 intellectual property or other rights that might be claimed to 344 pertain to the implementation or use of the technology described in 345 this document or the extent to which any license under such rights 346 might or might not be available; neither does it represent that it 347 has made any effort to identify any such rights. Information on the 348 IETF's procedures with respect to rights in standards-track and 349 standards-related documentation can be found in BCP-11. Copies of 350 claims of rights made available for publication and any assurances of 351 licenses to be made available, or the result of an attempt made to 352 obtain a general license or permission for the use of such 353 proprietary rights by implementors or users of this specification can 354 be obtained from the IETF Secretariat. 356 The IETF invites any interested party to bring to its attention any 357 copyrights, patents or patent applications, or other proprietary 358 rights which may cover technology that may be required to practice 359 this standard. Please address the information to the IETF Executive 360 Director. 362 Full Copyright Statement 364 Copyright (c) The Internet Society (2004). All Rights Reserved. 366 This document and translations of it may be copied and furnished to 367 others, and derivative works that comment on or otherwise explain it 368 or assist in its implementation may be prepared, copied, published 369 and distributed, in whole or in part, without restriction of any 370 kind, provided that the above copyright notice and this paragraph are 371 included on all such copies and derivative works. However, this 372 document itself may not be modified in any way, such as by removing 373 the copyright notice or references to the Internet Society or other 374 Internet organizations, except as needed for the purpose of 375 developing Internet standards in which case the procedures for 376 copyrights defined in the Internet Standards process must be 377 followed, or as required to translate it into languages other than 378 English. 380 The limited permissions granted above are perpetual and will not be 381 revoked by the Internet Society or its successors or assigns. 383 This document and the information contained herein is provided on an 384 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 385 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 386 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 387 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 388 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.