idnits 2.17.1 draft-ietf-sipping-transc-3pcc-01.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 3667, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 755. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 19 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.) 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 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 7, 2004) is 7262 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 3388 (ref. '3') (Obsoleted by RFC 5888) Summary: 8 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 E. Burger 6 Brooktrout 7 H. Schulzrinne 8 Columbia University 9 A. van Wijk 10 Viataal 11 draft-ietf-sipping-transc-3pcc-01.txt 12 June 7, 2004 13 Expires: December, 2004 15 Transcoding Services Invocation in the Session Initiation 16 Protocol (SIP) Using Third Party Call Control (3pcc) 18 STATUS OF THIS MEMO 20 By submitting this Internet-Draft, I certify that any applicable 21 patent or other IPR claims of which I am aware have been disclosed, 22 and any of which I become aware will be disclosed, in accordance with 23 RFC 3668. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This document describes how to invoke transcoding services using SIP 43 and third party call control. This way of invocation meets the 44 requirements for SIP regarding transcoding services invocation to 45 support deaf, hard of hearing and speech-impaired individuals. 47 Table of Contents 49 1 Introduction ........................................ 3 50 2 General Overview .................................... 3 51 3 Third Party Call Control Flows ...................... 3 52 3.1 Terminology ......................................... 4 53 3.2 Callee's Invocation ................................. 4 54 3.3 Caller's Invocation ................................. 9 55 3.4 Receiving the Original Stream ....................... 9 56 3.5 Transcoding Services in Parallel .................... 11 57 3.6 Transcoding Services in Serial ...................... 15 58 4 Security Considerations ............................. 17 59 5 Authors' Addresses .................................. 17 60 6 Normative References ................................ 17 61 7 Informative References .............................. 18 63 1 Introduction 65 The framework for transcoding with SIP [4] describes how two SIP [1] 66 UAs (User Agents) can discover imcompatibilities that prevent them 67 from establishing a session (e.g., lack of support for a common codec 68 or for a common media type). When such incompatibilities are found, 69 the UAs need to invoke transcoding services to successfully establish 70 the session. 3pcc (third party call control) [2] is one way to 71 perform such invocation. 73 2 General Overview 75 In the 3pcc model for transcoding invocation, a transcoding server 76 that provides a particular transcoding service (e.g., speech-to-text) 77 is identified by a URI. A UA that wishes to invoke that service sends 78 an INVITE request to that URI establishing a number of media streams. 79 The way the transcoder manipulates and manages the contents of those 80 media streams (e.g., the text received over the text stream is 81 transformed into speech and sent over the audio stream) is service 82 specific. 84 All the call flows in this document use SDP. The same call 85 flows could be used with another session description 86 protocol that provided similar session description 87 capabilities. 89 3 Third Party Call Control Flows 91 Given two UAs (A and B) and a transcoding server (T), the invocation 92 of a transcoding service consists of establishing two sessions; A-T 93 and T-B. How these sessions are established depends on which party, 94 the caller (A) or the callee (B), invokes the transcoding services. 95 Section 3.2 deals with callee invocation and Section 3.3 deals with 96 caller invocation. 98 In all our 3pcc flows we have followed a general principle; a 200 99 (OK) response from the transcoding service has to be received before 100 contacting the callee. This tries to ensure that the transcoding 101 service will be available when the callee accepts the session. 103 Still, the transcoding service does not know the exact type of 104 transcoding it will be performing until the callee accepts the 105 session. So, there are always chances of failing to provide 106 transcoding services after the callee has accepted the session. A 107 system with tough requirements could use preconditions to avoid this 108 situation. When preconditions are used, the callee is not alerted 109 until everything is ready for the session. 111 3.1 Terminology 113 All the flows in this document follow the naming convention below: 115 SDP A: A session description generated by A. It contains, among 116 other things, the transport address/es (IP address and port 117 number) where A wants to receive media for each particular 118 stream. 120 SDP B: A session description generated by B. It contains, among 121 other things, the transport address/es where B wants to 122 receive media for each particular stream. 124 SDP A+B: A session description that contains, among other 125 things, the transport address/es where A wants to receive 126 media and the transport address/es where B wants to receive 127 media. 129 SDP TA: A session description generated by T and intended for A. 130 It contains, among other things, the transport address/es 131 where T wants to receive media from A. 133 SDP TB: A session description generated by T and intended for B. 134 It contains, among other things, the transport address/es 135 where T wants to receive media from B. 137 SDP TA+TB: A session description generated by T that contains, 138 among other things, the transport address/es where T wants 139 to receive media from A and the transport address/es where 140 T wants to receive media from B. 142 3.2 Callee's Invocation 144 In this scenario, B receives an INVITE from A and B decides to 145 introduce T in the session. Figure 1 shows the call flow for this 146 scenario. 148 In Figure 1, A can both hear and speak and B is a deaf user with a 149 speech impairment. A proposes to establish a session that consists of 150 an audio stream (1). B wants to send and receive only text, so it 151 invokes a transcoding service T that will perform both speech-to-text 152 and text-to-speech conversions (2). The session descriptions of 153 Figure 1 are partially shown below. 155 A T B 157 | | | 158 |--------------------(1) INVITE SDP A-------------------->| 159 | | | 160 | |<---(2) INVITE SDP A+B------| 161 | | | 162 | |---(3) 200 OK SDP TA+TB---->| 163 | | | 164 | |<---------(4) ACK-----------| 165 | | | 166 |<-------------------(5) 200 OK SDP TA--------------------| 167 | | | 168 |------------------------(6) ACK------------------------->| 169 | | | 170 | ************************** | ************************** | 171 |* MEDIA *|* MEDIA *| 172 | ************************** | ************************** | 173 | | | 175 Figure 1: Callee's invocation of a transcoding service 177 (1) INVITE SDP A 179 m=audio 20000 RTP/AVP 0 180 c=IN IP4 A.example.com 182 (2) INVITE SDP A+B 184 m=audio 20000 RTP/AVP 0 185 c=IN IP4 A.example.com 186 m=text 40000 RTP/AVP 96 187 c=IN IP4 B.example.com 188 a=rtpmap:96 t140/1000 190 (3) 200 OK SDP TA+TB 192 m=audio 30000 RTP/AVP 0 193 c=IN IP4 T.example.com 194 m=text 30002 RTP/AVP 96 195 c=IN IP4 T.example.com 196 a=rtpmap:96 t140/1000 198 (5) 200 OK SDP TA 200 m=audio 30000 RTP/AVP 0 201 c=IN IP4 T.example.com 203 Four media streams (i.e., two bi-directional streams) have been 204 established at this point: 206 1. Audio from A to T.example.com:30000 208 2. Text from T to B.example.com:40000 210 3. Text from B to T.example.com:30002 212 4. Audio from T to A.example.com:20000 214 When either A or B decide to terminate the session, they send a BYE 215 to T indicating that the session is over. 217 If the first INVITE (1) received by B is empty (no session 218 description), the call flow is slightly different. Figure 2 shows the 219 messages involved. 221 B may have different reasons for invoking T before knowing A's 222 session description. B may want to hide its capabilities, and 223 therefore it wants to return a session description with all the 224 codecs B supports plus all the codecs T supports. Or T may provide 225 recording services (besides transcoding), and B wants T to record the 226 conversation, regardless of whether or not transcoding is needed. 228 This scenario (Figure 2) is a bit more complex than the previous one. 229 In INVITE (2), B still does not have SDP A, so it cannot provide T 230 with that information. When B finally receives SDP A in (6), it has 231 to send it to T. B sends an empty INVITE to T (7) and gets a 200 OK 232 with SDP TA+TB (8). In general, this SDP TA+TB can be different than 233 the one that was sent in (3). That is why B needs to send the updated 234 SDP TA to A in (9). A then sends a possibly updated SDP A (10) and B 235 sends it to T in (12). On the other hand, if T happens to return the 236 same SDP TA+TB in (8) as in (3), B can skip messages (9), (10), and 237 (11). So, implementors of transcoding services are encouraged to 238 return the same session description in (8) as in (3) in this type of 239 scenario. The session descriptions of this flow are shown below: 241 A T B 243 | | | 244 |----------------------(1) INVITE------------------------>| 245 | | | 246 | |<-----(2) INVITE SDP B------| 247 | | | 248 | |---(3) 200 OK SDP TA+TB---->| 249 | | | 250 | |<---------(4) ACK-----------| 251 | | | 252 |<-------------------(5) 200 OK SDP TA--------------------| 253 | | | 254 |-----------------------(6) ACK SDP A-------------------->| 255 | | | 256 | |<-------(7) INVITE----------| 257 | | | 258 | |---(8) 200 OK SDP TA+TB---->| 259 | | | 260 |<-----------------(9) INVITE SDP TA----------------------| 261 | | | 262 |------------------(10) 200 OK SDP A--------------------->| 263 | | | 264 |<-----------------------(11) ACK-------------------------| 265 | | | 266 | |<-----(12) ACK SDP A+B------| 267 | | | 268 | ************************** | ************************** | 269 |* MEDIA *|* MEDIA *| 270 | ************************** | ************************** | 272 Figure 2: Callee's invocation after initial INVITE without SDP 274 (2) INVITE SDP A+B 276 m=audio 20000 RTP/AVP 0 277 c=IN IP4 0.0.0.0 278 m=text 40000 RTP/AVP 96 279 c=IN IP4 B.example.com 280 a=rtpmap:96 t140/1000 282 (3) 200 OK SDP TA+TB 284 m=audio 30000 RTP/AVP 0 285 c=IN IP4 T.example.com 286 m=text 30002 RTP/AVP 96 287 c=IN IP4 T.example.com 288 a=rtpmap:96 t140/1000 290 (5) 200 OK SDP TA 292 m=audio 30000 RTP/AVP 0 293 c=IN IP4 T.example.com 295 (6) ACK SDP A 297 m=audio 20000 RTP/AVP 0 298 c=IN IP4 A.example.com 300 (8) 200 OK SDP TA+TB 302 m=audio 30004 RTP/AVP 0 303 c=IN IP4 T.example.com 304 m=text 30006 RTP/AVP 96 305 c=IN IP4 T.example.com 306 a=rtpmap:96 t140/1000 308 (9) INVITE SDP TA 310 m=audio 30004 RTP/AVP 0 311 c=IN IP4 T.example.com 313 (10) 200 OK SDP A 315 m=audio 20002 RTP/AVP 0 316 c=IN IP4 A.example.com 318 (12) ACK SDP A+B 320 m=audio 20002 RTP/AVP 0 321 c=IN IP4 A.example.com 322 m=text 40000 RTP/AVP 96 323 c=IN IP4 B.example.com 324 a=rtpmap:96 t140/1000 326 Four media streams (i.e., two bi-directional streams) have been 327 established at this point: 329 1. Audio from A to T.example.com:30004 331 2. Text from T to B.example.com:40000 333 3. Text from B to T.example.com:30006 335 4. Audio from T to A.example.com:20002 337 3.3 Caller's Invocation 339 In this scenario, A wishes to establish a session with B using a 340 transcoding service. A uses 3pcc to set up the session between T and 341 B. The call flow we provide here is slightly different than the ones 342 in [2]. In [2], the controller establishes a session between two user 343 agents, which are the ones deciding the characteristics of the 344 streams. Here, A wants to establish a session between T and B, but A 345 wants to decide how many and which types of streams are established. 346 That is why A sends its session description in the first INVITE (1) 347 to T, as opposed to the media-less initial INVITE recommended by [2]. 348 Figure 3 shows the call flow for this scenario. 350 We do not include the session descriptions of this flow, since they 351 are very similar to the ones in Figure 2. In this flow, if T returns 352 the same SDP TA+TB in (8) as in (2), messages (9), (10), and (11) can 353 be skipped. 355 3.4 Receiving the Original Stream 357 Sometimes, as pointed out in the requirements for SIP in support of 358 deaf, hard of hearing, and speech-impaired individuals [5], a user 359 wants to receive both the original stream (e.g., audio) and the 360 transcoded stream (e.g., the output of the speech-to-text 361 conversion). There are various possible solutions for this problem. 362 One solution consists of using the SDP group attribute with FID 363 semantics [3]. FID allows requesting that a stream is sent to two 364 different transport addresses in parallel, as shown below: 366 A T B 368 | | | 369 |-------(1) INVITE SDP A---->| | 370 | | | 371 |<----(2) 200 OK SDP TA+TB---| | 372 | | | 373 |----------(3) ACK---------->| | 374 | | | 375 |--------------------(4) INVITE SDP TA------------------->| 376 | | | 377 |<--------------------(5) 200 OK SDP B--------------------| 378 | | | 379 |-------------------------(6) ACK------------------------>| 380 | | | 381 |--------(7) INVITE--------->| | 382 | | | 383 |<---(8) 200 OK SDP TA+TB --| | 384 | | | 385 |--------------------(9) INVITE SDP TA------------------->| 386 | | | 387 |<-------------------(10) 200 OK SDP B--------------------| 388 | | | 389 |-------------------------(11) ACK----------------------->| 390 | | | 391 |------(12) ACK SDP A+B----->| | 392 | | | 393 | ************************** | ************************** | 394 |* MEDIA *|* MEDIA *| 395 | ************************** | ************************** | 396 | | | 398 Figure 3: Caller's invocation of a transcoding service 400 a=group:FID 1 2 401 m=audio 20000 RTP/AVP 0 402 c=IN IP4 A.example.com 403 a=mid:1 404 m=audio 30000 RTP/AVP 0 405 c=IN IP4 T.example.com 406 a=mid:2 408 The problem with this solution is that the majority of the SIP user 409 agents do not support FID. Moreover, only a small fraction of the few 410 UAs that do support FID, support sending simultaneous copies of the 411 same media stream at the same time. In addition, FID forces both 412 copies of the stream to use the same codec. 414 So, we recommend that T (instead of one of the user agent) replicates 415 the media stream. The transcoder T receiving the following session 416 description performs speech-to-text and text-to-speech conversions 417 between the first audio stream and the text stream. In addition, T 418 copies the first audio stream to the second audio stream and sends it 419 to A. 421 m=audio 40000 RTP/AVP 0 422 c=IN IP4 B.example.com 423 m=audio 20000 RTP/AVP 0 424 c=IN IP4 A.example.com 425 a=recvonly 426 m=text 20002 RTP/AVP 96 427 c=IN IP4 A.example.com 428 a=rtpmap:96 t140/1000 430 3.5 Transcoding Services in Parallel 432 Transcoding services sometimes consist of human relays (e.g., a 433 person performing speech-to-text and text-to-speech conversions for a 434 session). If the same person is involved in both conversions (i.e., 435 from A to B and from B to A), he or she has access to all the 436 conversation. In order to provide some degree of privacy, sometimes 437 two different persons are allocated to do the job (i.e., one person 438 handles A->B and the other B->A). This type of disposition is also 439 useful for automated transcoding services, where one machine converts 440 text to synthetic speech (text-to-speech) and a different machine 441 performs voice recognition (speech-to-text). 443 The scenario just described involves four different sessions; A-T1, 444 T1-B, B-T2 and T2-A. Figure 4 shows the call flow where A invokes T1 445 and T2. 447 (1) INVITE SDP AT1 449 m=text 20000 RTP/AVP 96 450 c=IN IP4 A.example.com 451 a=rtpmap:96 t140/1000 452 a=sendonly 453 m=audio 20000 RTP/AVP 0 454 c=IN IP4 0.0.0.0 455 a=recvonly 457 (2) INVITE SDP AT2 459 m=text 20002 RTP/AVP 96 460 c=IN IP4 A.example.com 461 a=rtpmap:96 t140/1000 462 a=recvonly 463 m=audio 20000 RTP/AVP 0 464 c=IN IP4 0.0.0.0 465 a=sendonly 467 (3) 200 OK SDP T1A+T1B 469 m=text 30000 RTP/AVP 96 470 c=IN IP4 T1.example.com 471 a=rtpmap:96 t140/1000 472 a=recvonly 473 m=audio 30002 RTP/AVP 0 474 c=IN IP4 T1.example.com 475 a=sendonly 477 (5) 200 OK SDP T2A+T2B 479 m=text 40000 RTP/AVP 96 480 c=IN IP4 T2.example.com 481 a=rtpmap:96 t140/1000 482 a=sendonly 483 m=audio 40002 RTP/AVP 0 484 c=IN IP4 T2.example.com 485 a=recvonly 487 (7) INVITE SDP T1B+T2B 489 m=audio 30002 RTP/AVP 0 490 c=IN IP4 T1.example.com 491 a=sendonly 492 m=audio 40002 RTP/AVP 0 493 c=IN IP4 T2.example.com 494 a=recvonly 496 A T1 T2 B 498 | | | | 499 |----(1) INVITE SDP AT1--->| | | 500 | | | | 501 |----------------(2) INVITE SDP AT2-------------->| | 502 | | | | 503 |<-(3) 200 OK SDP T1A+T1B--| | | 504 | | | | 505 |---------(4) ACK--------->| | | 506 | | | | 507 |<---------------(5) 200 OK SDP T2A+T2B-----------| | 508 | | | | 509 |----------------------(6) ACK------------------->| | 510 | | | | 511 |-----------------------(7) INVITE SDP T1B+T2B----------------->| 512 | | | | 513 |<----------------------(8) 200 OK SDP BT1+BT2------------------| 514 | | | | 515 |------(9) INVITE--------->| | | 516 | | | | 517 |-------------------(10) INVITE------------------>| | 518 | | | | 519 |<-(11) 200 OK SDP T1A+T1B-| | | 520 | | | | 521 |<------------(12) 200 OK SDP T2A+T2B-------------| | 522 | | | | 523 |------------------(13) INVITE SDP T1B+T2B--------------------->| 524 | | | | 525 |<-----------------(14) 200 OK SDP BT1+BT2----------------------| 526 | | | | 527 |--------------------------(15) ACK---------------------------->| 528 | | | | 529 |---(16) ACK SDP AT1+BT1-->| | | 530 | | | | 531 |------------(17) ACK SDP AT2+BT2---------------->| | 532 | | | | 533 | ************************ | ********************************** | 534 |* MEDIA *|* MEDIA *| 535 | ************************ | ********************************** | 536 | | | | 537 | *********************************************** *********** 538 |* MEDIA *|* MEDIA *| 539 | *********************************************** | *********** | 540 | | | | 542 Figure 4: Transcoding services in parallel 543 (8) 200 OK SDP BT1+BT2 545 m=audio 50000 RTP/AVP 0 546 c=IN IP4 B.example.com 547 a=recvonly 548 m=audio 50002 RTP/AVP 0 549 c=IN IP4 B.example.com 550 a=sendonly 552 (11) 200 OK SDP T1A+T1B 554 m=text 30000 RTP/AVP 96 555 c=IN IP4 T1.example.com 556 a=rtpmap:96 t140/1000 557 a=recvonly 558 m=audio 30002 RTP/AVP 0 559 c=IN IP4 T1.example.com 560 a=sendonly 562 (12) 200 OK SDP T2A+T2B 564 m=text 40000 RTP/AVP 96 565 c=IN IP4 T2.example.com 566 a=rtpmap:96 t140/1000 567 a=sendonly 568 m=audio 40002 RTP/AVP 0 569 c=IN IP4 T2.example.com 570 a=recvonly 572 Since T1 have returned the same SDP in (11) as in (3) and T2 has 573 returned the same SDP in (12) as in (5), messages (13), (14) and (15) 574 can be skipped. 576 (16) ACK SDP AT1+BT1 578 m=text 20000 RTP/AVP 96 579 c=IN IP4 A.example.com 580 a=rtpmap:96 t140/1000 581 a=sendonly 582 m=audio 50000 RTP/AVP 0 583 c=IN IP4 B.example.com 584 a=recvonly 586 (17) ACK SDP AT2+BT2 588 m=text 20002 RTP/AVP 96 589 c=IN IP4 A.example.com 590 a=rtpmap:96 t140/1000 591 a=recvonly 592 m=audio 50002 RTP/AVP 0 593 c=IN IP4 B.example.com 594 a=sendonly 596 Four media streams have been established at this point: 598 1. Text from A to T1.example.com:30000 600 2. Audio from T1 to B.example.com:50000 602 3. Audio from B to T2.example.com:40002 604 4. Text from T2 to A.example.com:20002 606 Note that B, the user agent server, needs to support two media 607 streams; one sendonly and the other recvonly. At present, some user 608 agents, although they support a single sendrecv media stream, they do 609 not support a different media line per direction. Implementers are 610 encouraged to build support for this feature. 612 3.6 Transcoding Services in Serial 614 In a distributed environment, a complex transcoding service (e.g., 615 English text to Spanish speech) is often provided by several servers. 616 For example, one server performs English text to Spanish text 617 translation, and its output is feed into a server that performs 618 text-to-speech conversion. The flow in Figure 5 shows how A invokes 619 T1 and T2. 621 A T1 T2 B 623 | | | | 624 |----(1) INVITE SDP A-----> | | | 625 | | | | 626 |<-(2) 200 OK SDP T1A+T1T2- | | | 627 | | | | 628 |----------(3) ACK--------> | | | 629 | | | | 630 |-----------(4) INVITE SDP T1T2------------------>| | 631 | | | | 632 |<-----------(5) 200 OK SDP T2T1+T2B--------------| | 633 | | | | 634 |---------------------(6) ACK-------------------->| | 635 | | | | 636 |---------------------------(7) INVITE SDP T2B----------------->| 637 | | | | 638 |<--------------------------(8) 200 OK SDP B--------------------| 639 | | | | 640 |--------------------------------(9) ACK----------------------->| 641 | | | | 642 |---(10) INVITE-----------> | | | 643 | | | | 644 |------------------(11) INVITE------------------->| | 645 | | | | 646 |<-(12) 200 OK SDP T1A+T1T2-| | | 647 | | | | 648 |<-------------(13) 200 OK SDP T2T1+T2B-----------| | 649 | | | | 650 |---(14) ACK SDP T1T2+B---> | | | 651 | | | | 652 |-----------------------(15) INVITE SDP T2B-------------------->| 653 | | | | 654 |<----------------------(16) 200 OK SDP B-----------------------| 655 | | | | 656 |----------------(17) ACK SDP T1T2+B------------->| | 657 | | | | 658 |----------------------------(18) ACK-------------------------->| 659 | | | | 660 | ************************* | ******************* *********** | 661 |* MEDIA *|* MEDIA *|* MEDIA *| 662 | ************************* | ******************* | *********** | 663 | | | | 665 Figure 5: Transcoding services in serial 667 4 Security Considerations 669 This document describes how to use third party call control to invoke 670 transcoding services. It does not introduce new security 671 considerations besides the ones discussed in [2]. 673 5 Authors' Addresses 675 Gonzalo Camarillo 676 Ericsson 677 Advanced Signalling Research Lab. 678 FIN-02420 Jorvas 679 Finland 680 electronic mail: Gonzalo.Camarillo@ericsson.com 682 Eric Burger 683 Brooktrout Technology, Inc. 684 18 Keewaydin Way 685 Salem, NH 03079 686 USA 687 electronic mail: eburger@ieee.org 689 Henning Schulzrinne 690 Dept. of Computer Science 691 Columbia University 1214 Amsterdam Avenue, MC 0401 692 New York, NY 10027 693 USA 694 electronic mail: schulzrinne@cs.columbia.edu 696 Arnoud van Wijk 697 Viataal 698 Research & Development 699 Afdeling RDS 700 Theerestraat 42 701 5271 GD Sint-Michielsgestel 702 The Netherlands 703 electronic mail: a.vwijk@viataal.nl 705 6 Normative References 707 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 708 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 709 initiation protocol," RFC 3261, Internet Engineering Task Force, June 710 2002. 712 [2] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo, 713 "Best current practices for third party call control (3pcc) in the 714 session initiation protocol (SIP)," RFC 3725, Internet Engineering 715 Task Force, Apr. 2004. 717 [3] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne, 718 "Grouping of media lines in the session description protocol (SDP)," 719 RFC 3388, Internet Engineering Task Force, Dec. 2002. 721 7 Informative References 723 [4] G. Camarillo, "Framework for transcoding with the session 724 initiation protocol," Internet Draft draft-camarillo-sipping-transc- 725 framework-00, Internet Engineering Task Force, Aug. 2003. Work in 726 progress. 728 [5] N. Charlton, M. Gasson, G. Gybels, M. Spanner, and A. van Wijk, 729 "User requirements for the session initiation protocol (SIP) in 730 support of deaf, hard of hearing and speech-impaired individuals," 731 RFC 3351, Internet Engineering Task Force, Aug. 2002. 733 Intellectual Property Statement 735 The IETF takes no position regarding the validity or scope of any 736 Intellectual Property Rights or other rights that might be claimed to 737 pertain to the implementation or use of the technology described in 738 this document or the extent to which any license under such rights 739 might or might not be available; nor does it represent that it has 740 made any independent effort to identify any such rights. Information 741 on the IETF's procedures with respect to rights in IETF Documents can 742 be found in BCP 78 and BCP 79. 744 Copies of IPR disclosures made to the IETF Secretariat and any 745 assurances of licenses to be made available, or the result of an 746 attempt made to obtain a general license or permission for the use of 747 such proprietary rights by implementers or users of this 748 specification can be obtained from the IETF on-line IPR repository at 749 http://www.ietf.org/ipr. 751 The IETF invites any interested party to bring to its attention any 752 copyrights, patents or patent applications, or other proprietary 753 rights that may cover technology that may be required to implement 754 this standard. Please address the information to the IETF at ietf- 755 ipr@ietf.org. 757 Disclaimer of Validity 759 This document and the information contained herein are provided on an 760 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 761 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 762 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 763 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 764 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 765 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 767 Copyright Statement 769 Copyright (C) The Internet Society (2004). This document is subject 770 to the rights, licenses and restrictions contained in BCP 78, and 771 except as set forth therein, the authors retain all their rights. 773 Acknowledgment 775 Funding for the RFC Editor function is currently provided by the 776 Internet Society.