idnits 2.17.1 draft-ietf-sipping-transc-3pcc-00.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 18 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 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 3, 2004) is 7386 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 659 looks like a reference -- Missing reference section? '2' on line 664 looks like a reference -- Missing reference section? '3' on line 669 looks like a reference -- Missing reference section? '4' on line 674 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 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 SnowShore Networks 7 H. Schulzrinne 8 Columbia University 9 A. van Wijk 10 Viataal 11 draft-ietf-sipping-transc-3pcc-00.txt 12 February 3, 2004 13 Expires: August, 2004 15 Transcoding Services Invocation in the 16 Session Initiation Protocol Using Third Party Call Control 18 STATUS OF THIS MEMO 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 To view the list Internet-Draft Shadow Directories, see 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document describes how to invoke transcoding services using SIP 42 and third party call control. 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 General Overview .................................... 3 50 3 Third Party Call Control Flows ...................... 3 51 3.1 Terminology ......................................... 4 52 3.2 Callee's Invocation ................................. 4 53 3.3 Caller's Invocation ................................. 9 54 3.4 Receiving the Original Stream ....................... 9 55 3.5 Transcoding Services in Parallel .................... 11 56 3.6 Transcoding Services in Serial ...................... 15 57 4 Security Considerations ............................. 15 58 5 Authors' Addresses .................................. 15 59 6 Bibliography ........................................ 16 61 1 Introduction 63 The framework for transcoding with SIP [1] describes how two SIP UAs 64 can discover imcompatibilities that prevent them from establishing a 65 session (e.g., lack of support for a common codec or for a common 66 media type). When such incompatibilities are found, the UAs need to 67 invoke transcoding services to successfully establish the session. 68 3pcc (third party call control) [2] is one way to perform such 69 invocation. 71 2 General Overview 73 In the 3pcc model for transcoding invocation, a transcoding server 74 that provides a particular transcoding service (e.g., speech-to-text) 75 is identified by a URI. A UA that wishes to invoke that service sends 76 an INVITE request to that URI establishing a number of media streams. 77 The way the transcoder manipulates and manages the contents of those 78 media streams (e.g., the text received over the text stream is 79 transformed into speech and sent over the audio stream) is service 80 specific. 82 All the call flows in this document use SDP. The same call 83 flows could be used with another session description 84 protocol that provided similar session description 85 capabilities. 87 3 Third Party Call Control Flows 89 Given two UAs (A and B) and a transcoding server (T), the invocation 90 of a transcoding service consists of establishing two sessions; A-T 91 and T-B. How these sessions are established depends on which party, 92 the caller (A) or the callee (B), invokes the transcoding services. 93 Section 3.2 deals with callee invocation and Section 3.3 deals with 94 caller invocation. 96 In all our 3pcc flows we have followed a general principle; a 200 97 (OK) response from the transcoding service has to be received before 98 contacting the callee. This tries to ensure that the transcoding 99 service will be available when the callee accepts the session. 101 Still, the transcoding service does not know the exact type of 102 transcoding it will be performing until the callee accepts the 103 session. So, there are always chances of failing to provide 104 transcoding services after the callee has accepted the session. A 105 system with tough requirements could use preconditions to avoid this 106 situation. When preconditions are used, the callee is not alerted 107 until everything is ready for the session. 109 3.1 Terminology 111 All the flows in this document follow the naming convention below: 113 SDP A: A session description generated by A. It contains, among 114 other things, the transport address/es (IP address and port 115 number) where A wants to receive media for each particular 116 stream. 118 SDP B: A session description generated by B. It contains, among 119 other things, the transport address/es where B wants to 120 receive media for each particular stream. 122 SDP A+B: A session description that contains, among other 123 things, the transport address/es where A wants to receive 124 media and the transport address/es where B wants to receive 125 media. 127 SDP TA: A session description generated by T and intended for A. 128 It contains, among other things, the transport address/es 129 where T wants to receive media from A. 131 SDP TB: A session description generated by T and intended for B. 132 It contains, among other things, the transport address/es 133 where T wants to receive media from B. 135 SDP TA+TB: A session description generated by T that contains, 136 among other things, the transport address/es where T wants 137 to receive media from A and the transport address/es where 138 T wants to receive media from B. 140 3.2 Callee's Invocation 142 In this scenario, B receives an INVITE from A, and B decides to 143 introduce T in the session. Figure 1 shows the call flow for this 144 scenario. 146 In Figure 1, A can both hear and speak and B is a deaf user with a 147 speech impairment. A proposes to establish a session that consists of 148 an audio stream (1). B wants to send and receive only text, so it 149 invokes a transcoding service T that will perform both speech-to-text 150 and text-to-speech conversions (2). The session descriptions of 151 Figure 1 are partially shown below. 153 (1) INVITE SDP A 155 m=audio 20000 RTP/AVP 0 157 A T B 159 | | | 160 |--------------------(1) INVITE SDP A-------------------->| 161 | | | 162 | |<---(2) INVITE SDP A+B------| 163 | | | 164 | |---(3) 200 OK SDP TA+TB---->| 165 | | | 166 | |<---------(4) ACK-----------| 167 | | | 168 |<-------------------(5) 200 OK SDP TA--------------------| 169 | | | 170 |------------------------(6) ACK------------------------->| 171 | | | 172 | ************************** | ************************** | 173 |* MEDIA *|* MEDIA *| 174 | ************************** | ************************** | 175 | | | 177 Figure 1: Callee's invocation of a transcoding service 179 c=IN IP4 A.domain.com 181 (2) INVITE SDP A+B 183 m=audio 20000 RTP/AVP 0 184 c=IN IP4 A.domain.com 185 m=text 40000 RTP/AVP 96 186 c=IN IP4 B.domain.com 187 a=rtpmap:96 t140/1000 189 (3) 200 OK SDP TA+TB 191 m=audio 30000 RTP/AVP 0 192 c=IN IP4 T.domain.com 193 m=text 30002 RTP/AVP 96 194 c=IN IP4 T.domain.com 195 a=rtpmap:96 t140/1000 197 (5) 200 OK SDP TA 199 m=audio 30000 RTP/AVP 0 200 c=IN IP4 T.domain.com 202 Four media streams (i.e., two bi-directional streams) have been 203 established at this point: 205 1. Audio from A to T.domain.com:30000 207 2. Text from T to B.domain.com:40000 209 3. Text from B to T.domain.com:30002 211 4. Audio from T to A.domain.com:20000 213 When either A or B decide to terminate the session, B will send a BYE 214 to T indicating that the session is over. 216 If the first INVITE (1) received by B is empty (no session 217 description), the call flow is slightly different. Figure 2 shows the 218 messages involved. 220 B may have different reasons for invoking T before knowing A's 221 session description. B may want to hide its capabilities, and 222 therefore it wants to return a session description with all the 223 codecs B supports plus all the codecs T supports. Or T may provide 224 recording services (besides transcoding), and B wants T to record the 225 conversation, regardless of whether or not transcoding is needed. 227 This scenario (Figure 2) is a bit more complex than the previous one. 228 In INVITE (2), B still does not have SDP A, so it cannot provide T 229 with that information. When B finally receives SDP A in (6), it has 230 to send it to T. B sends an empty INVITE to T (7) and gets a 200 OK 231 with SDP TA+TB (8). In general, this SDP TA+TB can be different than 232 the one that was sent in (3). That is why B needs to send the updated 233 SDP TA to A in (9). A then sends a possibly updated SDP A (10) and B 234 sends it to T in (12). On the other hand, if T happens to return the 235 same SDP TA+TB in (8) as in (3), B can skip messages (9), (10) and 236 (11). So, implementors of transcoding services are encouraged to 237 return the same session description in (8) as in (3) in this type of 238 scenario. The session descriptions of this flow are shown below: 240 (2) INVITE SDP A+B 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 m=audio 20000 RTP/AVP 0 275 c=IN IP4 0.0.0.0 276 m=text 40000 RTP/AVP 96 277 c=IN IP4 B.domain.com 278 a=rtpmap:96 t140/1000 280 (3) 200 OK SDP TA+TB 282 m=audio 30000 RTP/AVP 0 283 c=IN IP4 T.domain.com 284 m=text 30002 RTP/AVP 96 285 c=IN IP4 T.domain.com 286 a=rtpmap:96 t140/1000 288 (5) 200 OK SDP TA 290 m=audio 30000 RTP/AVP 0 291 c=IN IP4 T.domain.com 293 (6) ACK SDP A 295 m=audio 20000 RTP/AVP 0 296 c=IN IP4 A.domain.com 298 (8) 200 OK SDP TA+TB 300 m=audio 30004 RTP/AVP 0 301 c=IN IP4 T.domain.com 302 m=text 30006 RTP/AVP 96 303 c=IN IP4 T.domain.com 304 a=rtpmap:96 t140/1000 306 (9) INVITE SDP TA 308 m=audio 30004 RTP/AVP 0 309 c=IN IP4 T.domain.com 311 (10) 200 OK SDP A 313 m=audio 20002 RTP/AVP 0 314 c=IN IP4 A.domain.com 316 (12) ACK SDP A+B 318 m=audio 20002 RTP/AVP 0 319 c=IN IP4 A.domain.com 320 m=text 40000 RTP/AVP 96 321 c=IN IP4 B.domain.com 322 a=rtpmap:96 t140/1000 324 Four media streams (i.e., two bi-directional streams) have been 325 established at this point: 327 1. Audio from A to T.domain.com:30004 329 2. Text from T to B.domain.com:40000 331 3. Text from B to T.domain.com:30006 333 4. Audio from T to A.domain.com:20002 335 3.3 Caller's Invocation 337 In this scenario, A wishes to establish a session with B using a 338 transcoding service. A uses 3pcc to set up the session between T and 339 B. The call flow we provide here is slightly different than the ones 340 in [2]. In [2], the controller establishes a session between two user 341 agents, which are the ones deciding the characteristics of the 342 streams. Here, A wants to establish a session between T and B, but A 343 wants to decide how many and which types of streams are established. 344 That is why A sends its session description in the first INVITE (1) 345 to T, as opposed to the media-less initial INVITE recommended by [2]. 346 Figure 3 shows the call flow for this scenario. 348 We do not include the session descriptions of this flow, since they 349 are very similar to the ones in Figure 2. In this flow, if T returns 350 the same SDP TA+TB in (8) as in (2), messages (9), (10) and (11) can 351 be skipped. 353 3.4 Receiving the Original Stream 355 Sometimes, as pointed out in the requirements for SIP in support of 356 deaf, hard of hearing and speech-impaired individuals [3], a user 357 wants to receive both the original stream (e.g., audio) and the 358 transcoded stream (e.g., the output of the speech-to-text 359 conversion). There are various possible solutions for this problem. 360 One solution consists of using the SDP group attribute with FID 361 semantics [4]. FID allows requesting that a stream is sent to two 362 different transport addresses in parallel, as shown below: 364 a=group:FID 1 2 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 m=audio 20000 RTP/AVP 0 401 c=IN IP4 A.domain.com 402 a=mid:1 403 m=audio 30000 RTP/AVP 0 404 c=IN IP4 T.domain.com 405 a=mid:2 407 The problem with this solution is that the majority of the SIP user 408 agents do not support FID. Moreover, only a small fraction of the few 409 UAs that do support FID, support sending simultaneous copies of the 410 same media stream at the same time. In addition, FID forces both 411 copies of the stream to use the same codec. 413 So, we recommend that T (instead of a user agent) replicates the 414 media stream. The transcoder T receiving the following session 415 description performs speech-to-text and text-to-speech conversions 416 between the first audio stream and the text stream. In addition, T 417 copies the first audio stream to the second audio stream and sends it 418 to A. 420 m=audio 40000 RTP/AVP 0 421 c=IN IP4 B.domain.com 422 m=audio 20000 RTP/AVP 0 423 c=IN IP4 A.domain.com 424 a=recvonly 425 m=text 20002 RTP/AVP 96 426 c=IN IP4 A.domain.com 427 a=rtpmap:96 t140/1000 429 3.5 Transcoding Services in Parallel 431 Transcoding services sometimes consist of human relays (e.g., a 432 person performing speech-to-text and text-to-speech conversions for a 433 session). If the same person is involved in both conversions (i.e., 434 from A to B and from B to A), he or she has access to all the 435 conversation. In order to provide some degree of privacy, sometimes 436 two different persons are allocated to do the job (i.e., one person 437 handles A->B and the other B->A). This type of disposition is also 438 useful for automated transcoding services, where one machine converts 439 text to synthetic speech (text-to-speech) and a different machine 440 performs voice recognition (speech-to-text). 442 The scenario just described involves four different sessions; A-T1, 443 T1-B, B-T2 and T2-A. Figure 4 shows the call flow where A invokes T1 444 and T2. 446 (1) INVITE SDP AT1 448 m=text 20000 RTP/AVP 96 449 c=IN IP4 A.domain.com 450 a=rtpmap:96 t140/1000 451 a=sendonly 452 m=audio 20000 RTP/AVP 0 453 c=IN IP4 0.0.0.0 454 a=recvonly 456 (2) INVITE SDP AT2 458 m=text 20002 RTP/AVP 96 459 c=IN IP4 A.domain.com 460 a=rtpmap:96 t140/1000 461 a=recvonly 462 m=audio 20000 RTP/AVP 0 463 c=IN IP4 0.0.0.0 464 a=sendonly 466 (3) 200 OK SDP T1A+T1B 468 m=text 30000 RTP/AVP 96 469 c=IN IP4 T1.domain.com 470 a=rtpmap:96 t140/1000 471 a=recvonly 472 m=audio 30002 RTP/AVP 0 473 c=IN IP4 T1.domain.com 474 a=sendonly 476 (5) 200 OK SDP T2A+T2B 478 m=text 40000 RTP/AVP 96 479 c=IN IP4 T2.domain.com 480 a=rtpmap:96 t140/1000 481 a=sendonly 482 m=audio 40002 RTP/AVP 0 483 c=IN IP4 T2.domain.com 484 a=recvonly 486 (7) INVITE SDP T1B+T2B 488 m=audio 30002 RTP/AVP 0 489 c=IN IP4 T1.domain.com 490 a=sendonly 491 m=audio 40002 RTP/AVP 0 492 c=IN IP4 T2.domain.com 493 a=recvonly 495 A T1 T2 B 497 | | | | 498 |----(1) INVITE SDP AT1--->| | | 499 | | | | 500 |----------------(2) INVITE SDP AT2-------------->| | 501 | | | | 502 |<-(3) 200 OK SDP T1A+T1B--| | | 503 | | | | 504 |---------(4) ACK--------->| | | 505 | | | | 506 |<---------------(5) 200 OK SDP T2A+T2B-----------| | 507 | | | | 508 |----------------------(6) ACK------------------->| | 509 | | | | 510 |-----------------------(7) INVITE SDP T1B+T2B----------------->| 511 | | | | 512 |<----------------------(8) 200 OK SDP BT1+BT2------------------| 513 | | | | 514 |------(9) INVITE--------->| | | 515 | | | | 516 |-------------------(10) INVITE------------------>| | 517 | | | | 518 |<-(11) 200 OK SDP T1A+T1B-| | | 519 | | | | 520 |<------------(12) 200 OK SDP T2A+T2B-------------| | 521 | | | | 522 |------------------(13) INVITE SDP T1B+T2B--------------------->| 523 | | | | 524 |<-----------------(14) 200 OK SDP BT1+BT2----------------------| 525 | | | | 526 |--------------------------(15) ACK---------------------------->| 527 | | | | 528 |---(16) ACK SDP AT1+BT1-->| | | 529 | | | | 530 |------------(17) ACK SDP AT2+BT2---------------->| | 531 | | | | 532 | ************************ | ********************************** | 533 |* MEDIA *|* MEDIA *| 534 | ************************ | ********************************** | 535 | | | | 536 | *********************************************** *********** 537 |* MEDIA *|* MEDIA *| 538 | *********************************************** | *********** | 539 | | | | 541 Figure 4: Transcoding services in parallel 542 (8) 200 OK SDP BT1+BT2 544 m=audio 50000 RTP/AVP 0 545 c=IN IP4 B.domain.com 546 a=recvonly 547 m=audio 50002 RTP/AVP 0 548 c=IN IP4 B.domain.com 549 a=sendonly 551 (11) 200 OK SDP T1A+T1B 553 m=text 30000 RTP/AVP 96 554 c=IN IP4 T1.domain.com 555 a=rtpmap:96 t140/1000 556 a=recvonly 557 m=audio 30002 RTP/AVP 0 558 c=IN IP4 T1.domain.com 559 a=sendonly 561 (12) 200 OK SDP T2A+T2B 563 m=text 40000 RTP/AVP 96 564 c=IN IP4 T2.domain.com 565 a=rtpmap:96 t140/1000 566 a=sendonly 567 m=audio 40002 RTP/AVP 0 568 c=IN IP4 T2.domain.com 569 a=recvonly 571 Since T1 have returned the same SDP in (11) as in (3) and T2 has 572 returned the same SDP in (12) as in (5), messages (13), (14) and (15) 573 can be skipped. 575 (16) ACK SDP AT1+BT1 577 m=text 20000 RTP/AVP 96 578 c=IN IP4 A.domain.com 579 a=rtpmap:96 t140/1000 580 a=sendonly 581 m=audio 50000 RTP/AVP 0 582 c=IN IP4 B.domain.com 583 a=recvonly 585 (17) ACK SDP AT2+BT2 587 m=text 20002 RTP/AVP 96 588 c=IN IP4 A.domain.com 589 a=rtpmap:96 t140/1000 590 a=recvonly 591 m=audio 50002 RTP/AVP 0 592 c=IN IP4 B.domain.com 593 a=sendonly 595 Four media streams have been established at this point: 597 1. Text from A to T1.domain.com:30000 599 2. Audio from T1 to B.domain.com:50000 601 3. Audio from B to T2.domain.com:40002 603 4. Text from T2 to A.domain.com:20002 605 Note that B, the user agent server, needs to support two media 606 streams; one sendonly and the other recvonly. At present, some user 607 agents, although they support a single sendrecv media stream, they do 608 not support a different media line per direction. Implementers are 609 encouraged to build support for this feature. 611 3.6 Transcoding Services in Serial 613 In a distributed environment, a complex transcoding service (e.g., 614 English text to Spanish speech) is often provided by several servers. 615 For example, one server performs English text to Spanish text 616 translation, and its output is feed into a server that performs 617 text-to-speech conversion. The flow in Figure 5 shows how A invokes 618 T1 and T2. 620 4 Security Considerations 622 This document describes how to use third party call control to invoke 623 transcoding services. It does not introduce new security 624 considerations besides the ones discussed in [2]. 626 5 Authors' Addresses 628 Gonzalo Camarillo 629 Ericsson 630 Advanced Signalling Research Lab. 631 FIN-02420 Jorvas 632 Finland 633 electronic mail: Gonzalo.Camarillo@ericsson.com 635 Eric W. Burger 636 SnowShore Networks, Inc. 637 Chelmsford, MA 638 USA 639 electronic mail: eburger@snowshore.com 641 Henning Schulzrinne 642 Dept. of Computer Science 643 Columbia University 1214 Amsterdam Avenue, MC 0401 644 New York, NY 10027 645 USA 646 electronic mail: schulzrinne@cs.columbia.edu 648 Arnoud van Wijk 649 Viataal 650 Research & Development 651 Afdeling RDS 652 Theerestraat 42 653 5271 GD Sint-Michielsgestel 654 The Netherlands 655 electronic mail: a.vwijk@viataal.nl 657 6 Bibliography 659 [1] G. Camarillo, "Framework for transcoding with the session 660 initiation protocol," Internet Draft draft-camarillo-sipping-transc- 661 framework-00, Internet Engineering Task Force, Aug. 2003. Work in 662 progress. 664 [2] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo, 665 "Best current practices for third party call control in the session 666 initiation protocol," Internet Draft draft-ietf-sipping-3pcc-06, 667 Internet Engineering Task Force, Jan. 2004. Work in progress. 669 [3] N. Charlton, M. Gasson, G. Gybels, M. Spanner, and A. van Wijk, 670 "User requirements for the session initiation protocol (SIP) in 671 support of deaf, hard of hearing and speech-impaired individuals," 672 RFC 3351, Internet Engineering Task Force, Aug. 2002. 674 [4] G. Camarillo, J. Holler, G. Eriksson, and H. Schulzrinne, 675 "Grouping of m lines in SDP," internet draft, Internet Engineering 676 Task Force, Feb. 2002. Work in progress. 678 A T1 T2 B 680 | | | | 681 |----(1) INVITE SDP A-----> | | | 682 | | | | 683 |<-(2) 200 OK SDP T1A+T1T2- | | | 684 | | | | 685 |----------(3) ACK--------> | | | 686 | | | | 687 |-----------(4) INVITE SDP T1T2------------------>| | 688 | | | | 689 |<-----------(5) 200 OK SDP T2T1+T2B--------------| | 690 | | | | 691 |---------------------(6) ACK-------------------->| | 692 | | | | 693 |---------------------------(7) INVITE SDP T2B----------------->| 694 | | | | 695 |<--------------------------(8) 200 OK SDP B--------------------| 696 | | | | 697 |--------------------------------(9) ACK----------------------->| 698 | | | | 699 |---(10) INVITE-----------> | | | 700 | | | | 701 |------------------(11) INVITE------------------->| | 702 | | | | 703 |<-(12) 200 OK SDP T1A+T1T2-| | | 704 | | | | 705 |<-------------(13) 200 OK SDP T2T1+T2B-----------| | 706 | | | | 707 |---(14) ACK SDP T1T2+B---> | | | 708 | | | | 709 |-----------------------(15) INVITE SDP T2B-------------------->| 710 | | | | 711 |<----------------------(16) 200 OK SDP B-----------------------| 712 | | | | 713 |----------------(17) ACK SDP T1T2+B------------->| | 714 | | | | 715 |----------------------------(18) ACK-------------------------->| 716 | | | | 717 | ************************* | ******************* *********** | 718 |* MEDIA *|* MEDIA *|* MEDIA *| 719 | ************************* | ******************* | *********** | 720 | | | | 722 Figure 5: Transcoding services in serial 724 The IETF takes no position regarding the validity or scope of any 725 intellectual property or other rights that might be claimed to 726 pertain to the implementation or use of the technology described in 727 has made any effort to identify any such rights. Information on the 728 IETF's procedures with respect to rights in standards-track and 729 standards-related documentation can be found in BCP-11. Copies of 730 claims of rights made available for publication and any assurances of 731 licenses to be made available, or the result of an attempt made to 732 obtain a general license or permission for the use of such 733 proprietary rights by implementors or users of this specification can 734 be obtained from the IETF Secretariat. 736 The IETF invites any interested party to bring to its attention any 737 copyrights, patents or patent applications, or other proprietary 738 rights which may cover technology that may be required to practice 739 this standard. Please address the information to the IETF Executive 740 Director. 742 Full Copyright Statement 744 Copyright (c) The Internet Society (2004). All Rights Reserved. 746 This document and translations of it may be copied and furnished to 747 others, and derivative works that comment on or otherwise explain it 748 or assist in its implementation may be prepared, copied, published 749 and distributed, in whole or in part, without restriction of any 750 kind, provided that the above copyright notice and this paragraph are 751 included on all such copies and derivative works. However, this 752 document itself may not be modified in any way, such as by removing 753 the copyright notice or references to the Internet Society or other 754 Internet organizations, except as needed for the purpose of 755 developing Internet standards in which case the procedures for 756 copyrights defined in the Internet Standards process must be 757 followed, or as required to translate it into languages other than 758 English. 760 The limited permissions granted above are perpetual and will not be 761 revoked by the Internet Society or its successors or assigns. 763 This document and the information contained herein is provided on an 764 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 765 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 766 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 767 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 768 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.