idnits 2.17.1 draft-ietf-sipping-transc-3pcc-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 3667, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 770. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 760. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (September 17, 2004) is 7154 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: 7 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-02.txt 12 September 17, 2004 13 Expires: March, 2005 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 IANA Considerations ................................. 17 60 6 Authors' Addresses .................................. 17 61 7 Normative References ................................ 17 62 8 Informative References .............................. 18 64 1 Introduction 66 The framework for transcoding with SIP [4] describes how two SIP [1] 67 UAs (User Agents) can discover imcompatibilities that prevent them 68 from establishing a session (e.g., lack of support for a common codec 69 or for a common media type). When such incompatibilities are found, 70 the UAs need to invoke transcoding services to successfully establish 71 the session. 3pcc (third party call control) [2] is one way to 72 perform such invocation. 74 2 General Overview 76 In the 3pcc model for transcoding invocation, a transcoding server 77 that provides a particular transcoding service (e.g., speech-to-text) 78 is identified by a URI. A UA that wishes to invoke that service sends 79 an INVITE request to that URI establishing a number of media streams. 80 The way the transcoder manipulates and manages the contents of those 81 media streams (e.g., the text received over the text stream is 82 transformed into speech and sent over the audio stream) is service 83 specific. 85 All the call flows in this document use SDP. The same call 86 flows could be used with another session description 87 protocol that provided similar session description 88 capabilities. 90 3 Third Party Call Control Flows 92 Given two UAs (A and B) and a transcoding server (T), the invocation 93 of a transcoding service consists of establishing two sessions; A-T 94 and T-B. How these sessions are established depends on which party, 95 the caller (A) or the callee (B), invokes the transcoding services. 96 Section 3.2 deals with callee invocation and Section 3.3 deals with 97 caller invocation. 99 In all our 3pcc flows we have followed a general principle; a 200 100 (OK) response from the transcoding service has to be received before 101 contacting the callee. This tries to ensure that the transcoding 102 service will be available when the callee accepts the session. 104 Still, the transcoding service does not know the exact type of 105 transcoding it will be performing until the callee accepts the 106 session. So, there are always chances of failing to provide 107 transcoding services after the callee has accepted the session. A 108 system with tough requirements could use preconditions to avoid this 109 situation. When preconditions are used, the callee is not alerted 110 until everything is ready for the session. 112 3.1 Terminology 114 All the flows in this document follow the naming convention below: 116 SDP A: A session description generated by A. It contains, among 117 other things, the transport address/es (IP address and port 118 number) where A wants to receive media for each particular 119 stream. 121 SDP B: A session description generated by B. It contains, among 122 other things, the transport address/es where B wants to 123 receive media for each particular stream. 125 SDP A+B: A session description that contains, among other 126 things, the transport address/es where A wants to receive 127 media and the transport address/es where B wants to receive 128 media. 130 SDP TA: A session description generated by T and intended for A. 131 It contains, among other things, the transport address/es 132 where T wants to receive media from A. 134 SDP TB: A session description generated by T and intended for B. 135 It contains, among other things, the transport address/es 136 where T wants to receive media from B. 138 SDP TA+TB: A session description generated by T that contains, 139 among other things, the transport address/es where T wants 140 to receive media from A and the transport address/es where 141 T wants to receive media from B. 143 3.2 Callee's Invocation 145 In this scenario, B receives an INVITE from A and B decides to 146 introduce T in the session. Figure 1 shows the call flow for this 147 scenario. 149 In Figure 1, A can both hear and speak and B is a deaf user with a 150 speech impairment. A proposes to establish a session that consists of 151 an audio stream (1). B wants to send and receive only text, so it 152 invokes a transcoding service T that will perform both speech-to-text 153 and text-to-speech conversions (2). The session descriptions of 154 Figure 1 are partially shown below. 156 A T B 158 | | | 159 |--------------------(1) INVITE SDP A-------------------->| 160 | | | 161 | |<---(2) INVITE SDP A+B------| 162 | | | 163 | |---(3) 200 OK SDP TA+TB---->| 164 | | | 165 | |<---------(4) ACK-----------| 166 | | | 167 |<-------------------(5) 200 OK SDP TA--------------------| 168 | | | 169 |------------------------(6) ACK------------------------->| 170 | | | 171 | ************************** | ************************** | 172 |* MEDIA *|* MEDIA *| 173 | ************************** | ************************** | 174 | | | 176 Figure 1: Callee's invocation of a transcoding service 178 (1) INVITE SDP A 180 m=audio 20000 RTP/AVP 0 181 c=IN IP4 A.example.com 183 (2) INVITE SDP A+B 185 m=audio 20000 RTP/AVP 0 186 c=IN IP4 A.example.com 187 m=text 40000 RTP/AVP 96 188 c=IN IP4 B.example.com 189 a=rtpmap:96 t140/1000 191 (3) 200 OK SDP TA+TB 193 m=audio 30000 RTP/AVP 0 194 c=IN IP4 T.example.com 195 m=text 30002 RTP/AVP 96 196 c=IN IP4 T.example.com 197 a=rtpmap:96 t140/1000 199 (5) 200 OK SDP TA 201 m=audio 30000 RTP/AVP 0 202 c=IN IP4 T.example.com 204 Four media streams (i.e., two bi-directional streams) have been 205 established at this point: 207 1. Audio from A to T.example.com:30000 209 2. Text from T to B.example.com:40000 211 3. Text from B to T.example.com:30002 213 4. Audio from T to A.example.com:20000 215 When either A or B decide to terminate the session, they send a BYE 216 indicating that the session is over. 218 If the first INVITE (1) received by B is empty (no session 219 description), the call flow is slightly different. Figure 2 shows the 220 messages involved. 222 B may have different reasons for invoking T before knowing A's 223 session description. B may want to hide its capabilities, and 224 therefore it wants to return a session description with all the 225 codecs B supports plus all the codecs T supports. Or T may provide 226 recording services (besides transcoding), and B wants T to record the 227 conversation, regardless of whether or not transcoding is needed. 229 This scenario (Figure 2) is a bit more complex than the previous one. 230 In INVITE (2), B still does not have SDP A, so it cannot provide T 231 with that information. When B finally receives SDP A in (6), it has 232 to send it to T. B sends an empty INVITE to T (7) and gets a 200 OK 233 with SDP TA+TB (8). In general, this SDP TA+TB can be different than 234 the one that was sent in (3). That is why B needs to send the updated 235 SDP TA to A in (9). A then sends a possibly updated SDP A (10) and B 236 sends it to T in (12). On the other hand, if T happens to return the 237 same SDP TA+TB in (8) as in (3), B can skip messages (9), (10), and 238 (11). So, implementors of transcoding services are encouraged to 239 return the same session description in (8) as in (3) in this type of 240 scenario. The session descriptions of this flow are shown below: 242 A T B 244 | | | 245 |----------------------(1) INVITE------------------------>| 246 | | | 247 | |<-----(2) INVITE SDP B------| 248 | | | 249 | |---(3) 200 OK SDP TA+TB---->| 250 | | | 251 | |<---------(4) ACK-----------| 252 | | | 253 |<-------------------(5) 200 OK SDP TA--------------------| 254 | | | 255 |-----------------------(6) ACK SDP A-------------------->| 256 | | | 257 | |<-------(7) INVITE----------| 258 | | | 259 | |---(8) 200 OK SDP TA+TB---->| 260 | | | 261 |<-----------------(9) INVITE SDP TA----------------------| 262 | | | 263 |------------------(10) 200 OK SDP A--------------------->| 264 | | | 265 |<-----------------------(11) ACK-------------------------| 266 | | | 267 | |<-----(12) ACK SDP A+B------| 268 | | | 269 | ************************** | ************************** | 270 |* MEDIA *|* MEDIA *| 271 | ************************** | ************************** | 273 Figure 2: Callee's invocation after initial INVITE without SDP 275 (2) INVITE SDP A+B 277 m=audio 20000 RTP/AVP 0 278 c=IN IP4 0.0.0.0 279 m=text 40000 RTP/AVP 96 280 c=IN IP4 B.example.com 281 a=rtpmap:96 t140/1000 283 (3) 200 OK SDP TA+TB 285 m=audio 30000 RTP/AVP 0 286 c=IN IP4 T.example.com 287 m=text 30002 RTP/AVP 96 288 c=IN IP4 T.example.com 289 a=rtpmap:96 t140/1000 291 (5) 200 OK SDP TA 293 m=audio 30000 RTP/AVP 0 294 c=IN IP4 T.example.com 296 (6) ACK SDP A 298 m=audio 20000 RTP/AVP 0 299 c=IN IP4 A.example.com 301 (8) 200 OK SDP TA+TB 303 m=audio 30004 RTP/AVP 0 304 c=IN IP4 T.example.com 305 m=text 30006 RTP/AVP 96 306 c=IN IP4 T.example.com 307 a=rtpmap:96 t140/1000 309 (9) INVITE SDP TA 311 m=audio 30004 RTP/AVP 0 312 c=IN IP4 T.example.com 314 (10) 200 OK SDP A 316 m=audio 20002 RTP/AVP 0 317 c=IN IP4 A.example.com 319 (12) ACK SDP A+B 321 m=audio 20002 RTP/AVP 0 322 c=IN IP4 A.example.com 323 m=text 40000 RTP/AVP 96 324 c=IN IP4 B.example.com 325 a=rtpmap:96 t140/1000 327 Four media streams (i.e., two bi-directional streams) have been 328 established at this point: 330 1. Audio from A to T.example.com:30004 332 2. Text from T to B.example.com:40000 334 3. Text from B to T.example.com:30006 336 4. Audio from T to A.example.com:20002 338 3.3 Caller's Invocation 340 In this scenario, A wishes to establish a session with B using a 341 transcoding service. A uses 3pcc to set up the session between T and 342 B. The call flow we provide here is slightly different than the ones 343 in [2]. In [2], the controller establishes a session between two user 344 agents, which are the ones deciding the characteristics of the 345 streams. Here, A wants to establish a session between T and B, but A 346 wants to decide how many and which types of streams are established. 347 That is why A sends its session description in the first INVITE (1) 348 to T, as opposed to the media-less initial INVITE recommended by [2]. 349 Figure 3 shows the call flow for this scenario. 351 We do not include the session descriptions of this flow, since they 352 are very similar to the ones in Figure 2. In this flow, if T returns 353 the same SDP TA+TB in (8) as in (2), messages (9), (10), and (11) can 354 be skipped. 356 3.4 Receiving the Original Stream 358 Sometimes, as pointed out in the requirements for SIP in support of 359 deaf, hard of hearing, and speech-impaired individuals [5], a user 360 wants to receive both the original stream (e.g., audio) and the 361 transcoded stream (e.g., the output of the speech-to-text 362 conversion). There are various possible solutions for this problem. 363 One solution consists of using the SDP group attribute with FID 364 semantics [3]. FID allows requesting that a stream is sent to two 365 different transport addresses in parallel, as shown below: 367 A T B 369 | | | 370 |-------(1) INVITE SDP A---->| | 371 | | | 372 |<----(2) 200 OK SDP TA+TB---| | 373 | | | 374 |----------(3) ACK---------->| | 375 | | | 376 |--------------------(4) INVITE SDP TA------------------->| 377 | | | 378 |<--------------------(5) 200 OK SDP B--------------------| 379 | | | 380 |-------------------------(6) ACK------------------------>| 381 | | | 382 |--------(7) INVITE--------->| | 383 | | | 384 |<---(8) 200 OK SDP TA+TB --| | 385 | | | 386 |--------------------(9) INVITE SDP TA------------------->| 387 | | | 388 |<-------------------(10) 200 OK SDP B--------------------| 389 | | | 390 |-------------------------(11) ACK----------------------->| 391 | | | 392 |------(12) ACK SDP A+B----->| | 393 | | | 394 | ************************** | ************************** | 395 |* MEDIA *|* MEDIA *| 396 | ************************** | ************************** | 397 | | | 399 Figure 3: Caller's invocation of a transcoding service 401 a=group:FID 1 2 402 m=audio 20000 RTP/AVP 0 403 c=IN IP4 A.example.com 404 a=mid:1 405 m=audio 30000 RTP/AVP 0 406 c=IN IP4 T.example.com 407 a=mid:2 409 The problem with this solution is that the majority of the SIP user 410 agents do not support FID. Moreover, only a small fraction of the few 411 UAs that do support FID, support sending simultaneous copies of the 412 same media stream at the same time. In addition, FID forces both 413 copies of the stream to use the same codec. 415 So, we recommend that T (instead of one of the user agent) replicates 416 the media stream. The transcoder T receiving the following session 417 description performs speech-to-text and text-to-speech conversions 418 between the first audio stream and the text stream. In addition, T 419 copies the first audio stream to the second audio stream and sends it 420 to A. 422 m=audio 40000 RTP/AVP 0 423 c=IN IP4 B.example.com 424 m=audio 20000 RTP/AVP 0 425 c=IN IP4 A.example.com 426 a=recvonly 427 m=text 20002 RTP/AVP 96 428 c=IN IP4 A.example.com 429 a=rtpmap:96 t140/1000 431 3.5 Transcoding Services in Parallel 433 Transcoding services sometimes consist of human relays (e.g., a 434 person performing speech-to-text and text-to-speech conversions for a 435 session). If the same person is involved in both conversions (i.e., 436 from A to B and from B to A), he or she has access to all the 437 conversation. In order to provide some degree of privacy, sometimes 438 two different persons are allocated to do the job (i.e., one person 439 handles A->B and the other B->A). This type of disposition is also 440 useful for automated transcoding services, where one machine converts 441 text to synthetic speech (text-to-speech) and a different machine 442 performs voice recognition (speech-to-text). 444 The scenario just described involves four different sessions; A-T1, 445 T1-B, B-T2 and T2-A. Figure 4 shows the call flow where A invokes T1 446 and T2. 448 (1) INVITE SDP AT1 450 m=text 20000 RTP/AVP 96 451 c=IN IP4 A.example.com 452 a=rtpmap:96 t140/1000 453 a=sendonly 454 m=audio 20000 RTP/AVP 0 455 c=IN IP4 0.0.0.0 456 a=recvonly 458 (2) INVITE SDP AT2 460 m=text 20002 RTP/AVP 96 461 c=IN IP4 A.example.com 462 a=rtpmap:96 t140/1000 463 a=recvonly 464 m=audio 20000 RTP/AVP 0 465 c=IN IP4 0.0.0.0 466 a=sendonly 468 (3) 200 OK SDP T1A+T1B 470 m=text 30000 RTP/AVP 96 471 c=IN IP4 T1.example.com 472 a=rtpmap:96 t140/1000 473 a=recvonly 474 m=audio 30002 RTP/AVP 0 475 c=IN IP4 T1.example.com 476 a=sendonly 478 (5) 200 OK SDP T2A+T2B 480 m=text 40000 RTP/AVP 96 481 c=IN IP4 T2.example.com 482 a=rtpmap:96 t140/1000 483 a=sendonly 484 m=audio 40002 RTP/AVP 0 485 c=IN IP4 T2.example.com 486 a=recvonly 488 (7) INVITE SDP T1B+T2B 490 m=audio 30002 RTP/AVP 0 491 c=IN IP4 T1.example.com 492 a=sendonly 493 m=audio 40002 RTP/AVP 0 494 c=IN IP4 T2.example.com 495 a=recvonly 497 A T1 T2 B 499 | | | | 500 |----(1) INVITE SDP AT1--->| | | 501 | | | | 502 |----------------(2) INVITE SDP AT2-------------->| | 503 | | | | 504 |<-(3) 200 OK SDP T1A+T1B--| | | 505 | | | | 506 |---------(4) ACK--------->| | | 507 | | | | 508 |<---------------(5) 200 OK SDP T2A+T2B-----------| | 509 | | | | 510 |----------------------(6) ACK------------------->| | 511 | | | | 512 |-----------------------(7) INVITE SDP T1B+T2B----------------->| 513 | | | | 514 |<----------------------(8) 200 OK SDP BT1+BT2------------------| 515 | | | | 516 |------(9) INVITE--------->| | | 517 | | | | 518 |-------------------(10) INVITE------------------>| | 519 | | | | 520 |<-(11) 200 OK SDP T1A+T1B-| | | 521 | | | | 522 |<------------(12) 200 OK SDP T2A+T2B-------------| | 523 | | | | 524 |------------------(13) INVITE SDP T1B+T2B--------------------->| 525 | | | | 526 |<-----------------(14) 200 OK SDP BT1+BT2----------------------| 527 | | | | 528 |--------------------------(15) ACK---------------------------->| 529 | | | | 530 |---(16) ACK SDP AT1+BT1-->| | | 531 | | | | 532 |------------(17) ACK SDP AT2+BT2---------------->| | 533 | | | | 534 | ************************ | ********************************** | 535 |* MEDIA *|* MEDIA *| 536 | ************************ | ********************************** | 537 | | | | 538 | *********************************************** *********** 539 |* MEDIA *|* MEDIA *| 540 | *********************************************** | *********** | 541 | | | | 543 Figure 4: Transcoding services in parallel 544 (8) 200 OK SDP BT1+BT2 546 m=audio 50000 RTP/AVP 0 547 c=IN IP4 B.example.com 548 a=recvonly 549 m=audio 50002 RTP/AVP 0 550 c=IN IP4 B.example.com 551 a=sendonly 553 (11) 200 OK SDP T1A+T1B 555 m=text 30000 RTP/AVP 96 556 c=IN IP4 T1.example.com 557 a=rtpmap:96 t140/1000 558 a=recvonly 559 m=audio 30002 RTP/AVP 0 560 c=IN IP4 T1.example.com 561 a=sendonly 563 (12) 200 OK SDP T2A+T2B 565 m=text 40000 RTP/AVP 96 566 c=IN IP4 T2.example.com 567 a=rtpmap:96 t140/1000 568 a=sendonly 569 m=audio 40002 RTP/AVP 0 570 c=IN IP4 T2.example.com 571 a=recvonly 573 Since T1 have returned the same SDP in (11) as in (3) and T2 has 574 returned the same SDP in (12) as in (5), messages (13), (14) and (15) 575 can be skipped. 577 (16) ACK SDP AT1+BT1 579 m=text 20000 RTP/AVP 96 580 c=IN IP4 A.example.com 581 a=rtpmap:96 t140/1000 582 a=sendonly 583 m=audio 50000 RTP/AVP 0 584 c=IN IP4 B.example.com 585 a=recvonly 587 (17) ACK SDP AT2+BT2 589 m=text 20002 RTP/AVP 96 590 c=IN IP4 A.example.com 591 a=rtpmap:96 t140/1000 592 a=recvonly 593 m=audio 50002 RTP/AVP 0 594 c=IN IP4 B.example.com 595 a=sendonly 597 Four media streams have been established at this point: 599 1. Text from A to T1.example.com:30000 601 2. Audio from T1 to B.example.com:50000 603 3. Audio from B to T2.example.com:40002 605 4. Text from T2 to A.example.com:20002 607 Note that B, the user agent server, needs to support two media 608 streams; one sendonly and the other recvonly. At present, some user 609 agents, although they support a single sendrecv media stream, they do 610 not support a different media line per direction. Implementers are 611 encouraged to build support for this feature. 613 3.6 Transcoding Services in Serial 615 In a distributed environment, a complex transcoding service (e.g., 616 English text to Spanish speech) is often provided by several servers. 617 For example, one server performs English text to Spanish text 618 translation, and its output is feed into a server that performs 619 text-to-speech conversion. The flow in Figure 5 shows how A invokes 620 T1 and T2. 622 A T1 T2 B 624 | | | | 625 |----(1) INVITE SDP A-----> | | | 626 | | | | 627 |<-(2) 200 OK SDP T1A+T1T2- | | | 628 | | | | 629 |----------(3) ACK--------> | | | 630 | | | | 631 |-----------(4) INVITE SDP T1T2------------------>| | 632 | | | | 633 |<-----------(5) 200 OK SDP T2T1+T2B--------------| | 634 | | | | 635 |---------------------(6) ACK-------------------->| | 636 | | | | 637 |---------------------------(7) INVITE SDP T2B----------------->| 638 | | | | 639 |<--------------------------(8) 200 OK SDP B--------------------| 640 | | | | 641 |--------------------------------(9) ACK----------------------->| 642 | | | | 643 |---(10) INVITE-----------> | | | 644 | | | | 645 |------------------(11) INVITE------------------->| | 646 | | | | 647 |<-(12) 200 OK SDP T1A+T1T2-| | | 648 | | | | 649 |<-------------(13) 200 OK SDP T2T1+T2B-----------| | 650 | | | | 651 |---(14) ACK SDP T1T2+B---> | | | 652 | | | | 653 |-----------------------(15) INVITE SDP T2B-------------------->| 654 | | | | 655 |<----------------------(16) 200 OK SDP B-----------------------| 656 | | | | 657 |----------------(17) ACK SDP T1T2+B------------->| | 658 | | | | 659 |----------------------------(18) ACK-------------------------->| 660 | | | | 661 | ************************* | ******************* *********** | 662 |* MEDIA *|* MEDIA *|* MEDIA *| 663 | ************************* | ******************* | *********** | 664 | | | | 666 Figure 5: Transcoding services in serial 668 4 Security Considerations 670 This document describes how to use third party call control to invoke 671 transcoding services. It does not introduce new security 672 considerations besides the ones discussed in [2]. 674 5 IANA Considerations 676 This document has no actions for IANA. 678 6 Authors' Addresses 680 Gonzalo Camarillo 681 Ericsson 682 Advanced Signalling Research Lab. 683 FIN-02420 Jorvas 684 Finland 685 electronic mail: Gonzalo.Camarillo@ericsson.com 687 Eric Burger 688 Brooktrout Technology, Inc. 689 18 Keewaydin Way 690 Salem, NH 03079 691 USA 692 electronic mail: eburger@ieee.org 694 Henning Schulzrinne 695 Dept. of Computer Science 696 Columbia University 1214 Amsterdam Avenue, MC 0401 697 New York, NY 10027 698 USA 699 electronic mail: schulzrinne@cs.columbia.edu 701 Arnoud van Wijk 702 Viataal 703 Research & Development 704 Afdeling RDS 705 Theerestraat 42 706 5271 GD Sint-Michielsgestel 707 The Netherlands 708 electronic mail: a.vwijk@viataal.nl 710 7 Normative References 712 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 713 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 714 initiation protocol," RFC 3261, Internet Engineering Task Force, June 715 2002. 717 [2] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo, 718 "Best current practices for third party call control (3pcc) in the 719 session initiation protocol (SIP)," RFC 3725, Internet Engineering 720 Task Force, Apr. 2004. 722 [3] G. Camarillo, G. Eriksson, J. Holler, and H. Schulzrinne, 723 "Grouping of media lines in the session description protocol (SDP)," 724 RFC 3388, Internet Engineering Task Force, Dec. 2002. 726 8 Informative References 728 [4] G. Camarillo, "Framework for transcoding with the session 729 initiation protocol," Internet Draft draft-camarillo-sipping-transc- 730 framework-00, Internet Engineering Task Force, Aug. 2003. Work in 731 progress. 733 [5] N. Charlton, M. Gasson, G. Gybels, M. Spanner, and A. van Wijk, 734 "User requirements for the session initiation protocol (SIP) in 735 support of deaf, hard of hearing and speech-impaired individuals," 736 RFC 3351, Internet Engineering Task Force, Aug. 2002. 738 Intellectual Property Statement 740 The IETF takes no position regarding the validity or scope of any 741 Intellectual Property Rights or other rights that might be claimed to 742 pertain to the implementation or use of the technology described in 743 this document or the extent to which any license under such rights 744 might or might not be available; nor does it represent that it has 745 made any independent effort to identify any such rights. Information 746 on the IETF's procedures with respect to rights in IETF Documents can 747 be found in BCP 78 and BCP 79. 749 Copies of IPR disclosures made to the IETF Secretariat and any 750 assurances of licenses to be made available, or the result of an 751 attempt made to obtain a general license or permission for the use of 752 such proprietary rights by implementers or users of this 753 specification can be obtained from the IETF on-line IPR repository at 754 http://www.ietf.org/ipr. 756 The IETF invites any interested party to bring to its attention any 757 copyrights, patents or patent applications, or other proprietary 758 rights that may cover technology that may be required to implement 759 this standard. Please address the information to the IETF at ietf- 760 ipr@ietf.org. 762 Disclaimer of Validity 764 This document and the information contained herein are provided on an 765 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 766 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 767 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 768 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 769 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 770 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 772 Copyright Statement 774 Copyright (C) The Internet Society (2004). This document is subject 775 to the rights, licenses and restrictions contained in BCP 78, and 776 except as set forth therein, the authors retain all their rights. 778 Acknowledgment 780 Funding for the RFC Editor function is currently provided by the 781 Internet Society.