idnits 2.17.1 draft-johnston-mmusic-offer-answer-examples-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (March 2, 2003) is 7726 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) -- Looks like a reference, but probably isn't: 'Offer' on line 832 -- Looks like a reference, but probably isn't: 'Answer' on line 842 -- Looks like a reference, but probably isn't: 'Second-Offer' on line 852 -- Looks like a reference, but probably isn't: 'Second-Answer' on line 862 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '2') (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 2833 (ref. '4') (Obsoleted by RFC 4733, RFC 4734) == Outdated reference: A later version (-06) exists of draft-ietf-sipping-3pcc-02 == Outdated reference: A later version (-05) exists of draft-ietf-avt-rtp-ilbc-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group A. Johnston 3 Internet-Draft WorldCom 4 Expires: August 31, 2003 R. Sparks 5 dynamicsoft 6 March 2, 2003 8 Session Description Protocol Offer Answer Examples 9 draft-johnston-mmusic-offer-answer-examples-01 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 other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 31, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document gives examples of Session Description Protocol (SDP) 40 offer answer exchanges. Examples include codec negotiation and 41 selection, hold and resume, and addition and deletion of media 42 streams. The examples show multiple media types, bidirectional, 43 unidirectional, inactive streams and dynamic payload types. Common 44 Third Party Call Control (3pcc) examples are also given. 46 Table of Contents 48 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Codec Negotiation and Selection . . . . . . . . . . . . . . . 3 50 2.1 Audio and Video 1 . . . . . . . . . . . . . . . . . . . . . . 3 51 2.2 Audio and Video 2 . . . . . . . . . . . . . . . . . . . . . . 4 52 2.3 Audio and Video 3 . . . . . . . . . . . . . . . . . . . . . . 6 53 2.4 Two Audio Steams . . . . . . . . . . . . . . . . . . . . . . . 6 54 2.5 Audio and Video 4 . . . . . . . . . . . . . . . . . . . . . . 7 55 2.6 Audio Only 1 . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 2.7 Audio and Video 5 . . . . . . . . . . . . . . . . . . . . . . 9 57 2.8 Audio and Video 6 . . . . . . . . . . . . . . . . . . . . . . 11 58 3. Hold and Resume Scenarios . . . . . . . . . . . . . . . . . . 11 59 3.1 Hold and Unhold 1 . . . . . . . . . . . . . . . . . . . . . . 11 60 3.2 Hold with Two Streams . . . . . . . . . . . . . . . . . . . . 13 61 4. Addition and Deletion of Media Streams . . . . . . . . . . . . 14 62 4.1 Second Audio Stream Added . . . . . . . . . . . . . . . . . . 14 63 4.2 Audio then Video Added . . . . . . . . . . . . . . . . . . . . 15 64 4.3 Audio and Video, then Video Deleted . . . . . . . . . . . . . 16 65 5. Third Party Call Control (3pcc) . . . . . . . . . . . . . . . 18 66 5.1 No Media, then Audio Added . . . . . . . . . . . . . . . . . . 18 67 5.2 Hold and Unhold 2 . . . . . . . . . . . . . . . . . . . . . . 19 68 5.3 Hold and Unhold 3 . . . . . . . . . . . . . . . . . . . . . . 20 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 70 Informative References . . . . . . . . . . . . . . . . . . . . 21 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 72 Intellectual Property and Copyright Statements . . . . . . . . 23 74 1. Overview 76 This document describes offer answer examples of Session Description 77 Protocol (SDP) based on RFC 3264 [1]. The SDP in these examples are 78 defined by RFC 2327 [2]. The offers and answers are assumed to be 79 transported using a protocol such as Session Initiation Protocol 80 (SIP) [3]. 82 Examples include codec negotiation and selection, hold and resume, 83 and addition and deletion of media streams. The examples show 84 multiple media types, bidirectional, unidirectional, inactive streams 85 and dynamic payload types. Common Third Party Call Control (3pcc) 86 [5] examples are also given. 88 The following sections contain examples in which two parties, Alice 89 and Bob, exchange SDP offers, answers, and, in some cases, additional 90 offers and answers. 92 2. Codec Negotiation and Selection 94 2.1 Audio and Video 1 96 This common scenario shows a video and audio session in which 97 multiple codecs are offered but only one is accepted. As a result of 98 the exchange shown below, Alice and Bob may send only PCMU audio and 99 MPV video. Note: Dynamic payload type 97 is used for iLBC codec [6]. 101 [Offer] 103 v=0 104 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 105 s= 106 c=IN IP4 host.atlanta.example.com 107 t=0 0 108 m=audio 49170 RTP/AVP 0 8 97 109 a=rtpmap:0 PCMU/8000 110 a=rtpmap:8 PCMA/8000 111 a=rtpmap:97 iLBC 112 m=video 51372 RTP/AVP 31 32 113 a=rtpmap:31 H261/90000 114 a=rtpmap:32 MPV/90000 116 [Answer] 118 v=0 119 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 120 s= 121 c=IN IP4 host.biloxi.example.com 122 t=0 0 123 m=audio 49174 RTP/AVP 0 124 a=rtpmap:0 PCMU/8000 125 m=video 49170 RTP/AVP 32 126 a=rtpmap:32 MPV/90000 128 2.2 Audio and Video 2 130 Alice can support PCMU, PCMA, and iLBC codecs, but not more than one 131 at the same time. Alice offers all three to maximize chances of a 132 successful exchange and Bob accepts two of them. Audio only session 133 is established in initial exchange between Alice and Bob using either 134 PCMU or PCMA codecs (payload type in RTP packet tells which is being 135 used). Since Alice only supports one audio codec at a time, a second 136 offer is made with just that one codec to limit the codec choice to 137 just one. 139 Note: the version number is incremented in both SDP messages in the 140 second exchange. Now only the PCMU codec may be used for media 141 session between Alice and Bob. 143 Note: The declined video stream still present in the second exchange 144 of SDP with ports set to zero. 146 [Offer] 148 v=0 149 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 150 s= 151 c=IN IP4 host.atlanta.example.com 152 t=0 0 153 m=audio 49170 RTP/AVP 0 8 97 154 a=rtpmap:0 PCMU/8000 155 a=rtpmap:8 PCMA/8000 156 a=rtpmap:97 iLBC 157 m=video 51372 RTP/AVP 31 32 158 a=rtpmap:31 H261/90000 159 a=rtpmap:32 MPV/90000 161 [Answer] 163 v=0 164 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 165 s= 166 c=IN IP4 host.biloxi.example.com 167 t=0 0 168 m=audio 49172 RTP/AVP 0 8 169 a=rtpmap:0 PCMU/8000 170 a=rtpmap:8 PCMA/8000 171 m=video 0 RTP/AVP 31 172 a=rtpmap:31 H261/90000 174 [Second-Offer] 176 v=0 177 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 178 s= 179 c=IN IP4 host.atlanta.example.com 180 t=0 0 181 m=audio 51372 RTP/AVP 0 182 a=rtpmap:0 PCMU/8000 183 m=video 0 RTP/AVP 31 184 a=rtpmap:31 H261/90000 186 [Second-Answer] 188 v=0 189 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 190 s= 191 c=IN IP4 host.biloxi.example.com 192 t=0 0 193 m=audio 49172 RTP/AVP 0 194 a=rtpmap:0 PCMU/8000 195 m=video 0 RTP/AVP 31 196 a=rtpmap:31 H261/90000 198 2.3 Audio and Video 3 200 As a result of this exchange, Bob can send with either PCMU, PCMA, or 201 iLBC for audio and H261 or MPV for video. Alice can send with iLBC 202 and H261. 204 Note: change of dynamic payload type from 97 to 99 between the offer 205 and the answer is OK since it references same codec. 207 [Offer] 209 v=0 210 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 211 s= 212 c=IN IP4 host.atlanta.example.com 213 t=0 0 214 m=audio 49170 RTP/AVP 0 8 97 215 a=rtpmap:0 PCMU/8000 216 a=rtpmap:8 PCMA/8000 217 a=rtpmap:97 iLBC 218 m=video 51372 RTP/AVP 31 32 219 a=rtpmap:31 H261/90000 220 a=rtpmap:32 MPV/90000 222 [Answer] 224 v=0 225 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 226 s= 227 c=IN IP4 host.biloxi.example.com 228 t=0 0 229 m=audio 49172 RTP/AVP 99 230 a=rtpmap:99 iLBC 231 m=video 51374 RTP/AVP 31 232 a=rtpmap:31 H261/90000 234 2.4 Two Audio Steams 236 Alice sends but can not receive RFC 2833 tones [4] in a separate 237 audio stream. Bob accepts both audio streams. 239 [Offer] 241 v=0 242 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 243 s= 244 c=IN IP4 host.atlanta.example.com 245 t=0 0 246 m=audio 49170 RTP/AVP 0 97 247 a=rtpmap:0 PCMU/8000 248 a=rtpmap:97 iLBC 249 m=audio 49172 RTP/AVP 98 250 a=rtpmap:98 telephone-event 251 a=sendonly 253 [Answer] 255 v=0 256 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 257 s= 258 c=IN IP4 host.biloxi.example.com 259 t=0 0 260 m=audio 49172 RTP/AVP 97 261 a=rtpmap:97 iLBC 262 m=audio 49174 RTP/AVP 98 263 a=rtpmap:98 telephone-event 264 a=recvonly 266 2.5 Audio and Video 4 268 Alice and Bob establish an audio and video session. In a second 269 exchange, Bob changes his address for media and Alice accepts with 270 the same SDP as the initial exchange (and does not increment the 271 version number). 273 [Offer] 275 v=0 276 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 277 s= 278 c=IN IP4 host.atlanta.example.com 279 t=0 0 280 m=audio 49170 RTP/AVP 97 281 a=rtpmap:97 iLBC 282 m=video 51372 RTP/AVP 31 283 a=rtpmap:31 H261/90000 285 [Answer] 287 v=0 288 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 289 s= 290 c=IN IP4 host.biloxi.example.com 291 t=0 0 292 m=audio 49174 RTP/AVP 97 293 a=rtpmap:97 iLBC 294 m=video 49170 RTP/AVP 31 295 a=rtpmap:31 H261/90000 297 [Second-Offer] 299 v=0 300 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 301 s= 302 c=IN IP4 newhost.biloxi.example.com 303 t=0 0 304 m=audio 49178 RTP/AVP 97 305 a=rtpmap:97 iLBC 306 m=video 49188 RTP/AVP 31 307 a=rtpmap:31 H261/90000 309 [Second-Answer] 311 v=0 312 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 313 s= 314 c=IN IP4 host.atlanta.example.com 315 t=0 0 316 m=audio 49170 RTP/AVP 97 317 a=rtpmap:97 iLBC 318 m=video 51372 RTP/AVP 31 319 a=rtpmap:31 H261/90000 321 2.6 Audio Only 1 323 Alice wishes to establish an audio session with Bob using either PCMU 324 codec or iLBC codec with RFC2833 tones, but not both at the same 325 time. The offer contains these two media streams. Bob declines the 326 first one and accepts the second one. If both media streams had been 327 accepted, Alice would have sent a second declining one of the 328 streams, as shown in Section 4.3. 330 [Offer] 332 v=0 333 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 334 s= 335 c=IN IP4 host.atlanta.example.com 336 t=0 0 337 m=audio 49170 RTP/AVP 0 338 a=rtpmap:0 PCMU/8000 339 m=audio 51372 RTP/AVP 97 101 340 a=rtpmap:97 iLBC 341 a=rtpmap:101 telephone-events 343 [Answer] 345 v=0 346 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 347 s= 348 c=IN IP4 host.biloxi.example.com 349 t=0 0 350 m=audio 0 RTP/AVP 0 351 a=rtpmap:0 PCMU/8000 352 m=audio 49170 RTP/AVP 97 101 353 a=rtpmap:97 iLBC 354 a=rtpmap:101 telephone-events 356 2.7 Audio and Video 5 358 Alice and Bob establish an audio and video session in the first 359 exchange. In the second exchange, Alice adds a second video codec 360 which Bob accepts. 362 [Offer] 364 v=0 365 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 366 s= 367 c=IN IP4 host.atlanta.example.com 368 t=0 0 369 m=audio 49170 RTP/AVP 99 370 a=rtpmap:99 iLBC 371 m=video 51372 RTP/AVP 31 372 a=rtpmap:31 H261/90000 374 [Answer] 376 v=0 377 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 378 s= 379 c=IN IP4 host.biloxi.example.com 380 t=0 0 381 m=audio 49172 RTP/AVP 99 382 a=rtpmap:99 iLBC 383 m=video 51374 RTP/AVP 31 384 a=rtpmap:31 H261/90000 386 [Second-Offer] 388 v=0 389 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 390 s= 391 c=IN IP4 host.atlanta.example.com 392 t=0 0 393 m=audio 49170 RTP/AVP 99 394 a=rtpmap:99 iLBC 395 m=video 51372 RTP/AVP 31 32 396 a=rtpmap:31 H261/90000 397 a=rtpmap:32 MPV/90000 399 [Second-Answer] 401 v=0 402 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 403 s= 404 c=IN IP4 host.biloxi.example.com 405 t=0 0 406 m=audio 49172 RTP/AVP 99 407 a=rtpmap:99 iLBC 408 m=video 51374 RTP/AVP 31 32 409 a=rtpmap:31 H261/90000 410 a=rtpmap:32 MPV/90000 412 2.8 Audio and Video 6 414 This scenario shows an audio and video offer that is accepted, but 415 the answerer wants the video sent to a different address than the 416 audio. This is a common scenario in conferencing where the video and 417 audio mixing utilizes different servers. In this example, Alice 418 offers audio and video and Bob accepts. 420 [Offer] 422 v=0 423 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 424 s= 425 c=IN IP4 host.atlanta.example.com 426 t=0 0 427 m=audio 49170 RTP/AVP 0 8 97 428 a=rtpmap:0 PCMU/8000 429 a=rtpmap:8 PCMA/8000 430 a=rtpmap:97 iLBC 431 m=video 51372 RTP/AVP 31 32 432 a=rtpmap:31 H261/90000 433 a=rtpmap:32 MPV/90000 435 [Answer] 437 v=0 438 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 439 s= 440 c=IN IP4 host.biloxi.example.com 441 t=0 0 442 m=audio 49174 RTP/AVP 0 443 a=rtpmap:0 PCMU/8000 444 m=video 49172 RTP/AVP 32 445 c=IN IP4 otherhost.biloxi.example.com 446 a=rtpmap:32 MPV/90000 448 3. Hold and Resume Scenarios 450 3.1 Hold and Unhold 1 452 Alice calls Bob, but Bob answers placing Alice on hold. Bob then 453 takes Alice off hold in the second offer. Alice changes port number 454 in the second exchange. The media session between Alice and Bob is 455 now active after Alice's second answer. Note that a=sendrecv could 456 be present in both second offer and answer exchange. This is a 457 common flow in 3pcc [5] scenarios. 459 [Offer] 461 v=0 462 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 463 s= 464 c=IN IP4 host.atlanta.example.com 465 t=0 0 466 m=audio 49170 RTP/AVP 0 97 467 a=rtpmap:0 PCMU/8000 468 a=rtpmap:97 iLBC 470 [Answer] 472 v=0 473 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 474 s= 475 c=IN IP4 placeholder.biloxi.example.com 476 t=0 0 477 m=audio 49172 RTP/AVP 97 478 a=rtpmap:97 iLBC 479 a=sendonly 481 [Second-Offer] 483 v=0 484 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 485 s= 486 c=IN IP4 host.biloxi.example.com 487 t=0 0 488 m=audio 49170 RTP/AVP 97 489 a=rtpmap:97 iLBC 491 [Second-Answer] 493 v=0 494 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 495 s= 496 c=IN IP4 host.atlanta.example.com 497 t=0 0 498 m=audio 49178 RTP/AVP 97 499 a=rtpmap:97 iLBC 501 3.2 Hold with Two Streams 503 Alice sends but can not receive RFC2833 tones in a separate audio 504 stream. Bob accepts both audio streams. Bob then puts Alice's audio 505 stream on hold but not the tone stream. Alice responds with 506 identical SDP to the initial offer. 508 [Offer] 510 v=0 511 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 512 s= 513 c=IN IP4 host.atlanta.example.com 514 t=0 0 515 m=audio 49170 RTP/AVP 0 97 516 a=rtpmap:0 PCMU/8000 517 a=rtpmap:97 iLBC 518 m=audio 49172 RTP/AVP 98 519 a=rtpmap:98 telephone-event 520 a=sendonly 522 [Answer] 524 v=0 525 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 526 s= 527 c=IN IP4 host.biloxi.example.com 528 t=0 0 529 m=audio 49172 RTP/AVP 97 530 a=rtpmap:97 iLBC 531 m=audio 49174 RTP/AVP 98 532 a=rtpmap:98 telephone-event 533 a=recvonly 535 [Second-Offer] 537 v=0 538 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 539 s= 540 c=IN IP4 host.biloxi.example.com 541 t=0 0 542 m=audio 49172 RTP/AVP 97 543 a=rtpmap:97 iLBC 544 a=sendonly 545 m=audio 49174 RTP/AVP 98 546 a=rtpmap:98 telephone-event 547 a=recvonly 549 [Second-Answer] 551 v=0 552 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 553 s= 554 c=IN IP4 host.atlanta.example.com 555 t=0 0 556 m=audio 49170 RTP/AVP 0 97 557 a=rtpmap:0 PCMU/8000 558 a=rtpmap:97 iLBC 559 m=audio 49172 RTP/AVP 98 560 a=rtpmap:98 telephone-event 561 a=sendonly 563 4. Addition and Deletion of Media Streams 565 This section shows addition and deletion of media streams. 567 4.1 Second Audio Stream Added 569 The second stream is added by Bob's media server (different 570 connection address) to receive RFC 2833 telephone-events (DTMF 571 digits, typically) from Alice. Alice accepts. Even though the 2nd 572 stream is unidirectional, Alice receives RTCP packets on port 49173 573 from the media server. 575 [Offer] 577 v=0 578 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 579 s= 580 c=IN IP4 host.atlanta.example.com 581 t=0 0 582 m=audio 49170 RTP/AVP 0 97 583 a=rtpmap:0 PCMU/8000 584 a=rtpmap:97 iLBC 586 [Answer] 588 v=0 589 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 590 s= 591 c=IN IP4 host.biloxi.example.com 592 t=0 0 593 m=audio 49170 RTP/AVP 97 594 a=rtpmap:97 iLBC 596 [Second-Offer] 598 v=0 599 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 600 s= 601 c=IN IP4 host.biloxi.example.com 602 t=0 0 603 m=audio 49170 RTP/AVP 97 604 a=rtpmap:97 iLBC 605 m=audio 48282 RTP/AVP 98 606 c=IN IP4 mediaserver.biloxi.example.com 607 a=rtpmap:98 telephone-events 608 a=recvonly 610 [Second-Answer] 612 v=0 613 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 614 s= 615 c=IN IP4 host.atlanta.example.com 616 t=0 0 617 m=audio 49170 RTP/AVP 97 618 a=rtpmap:97 iLBC 619 c=IN IP4 host.atlanta.example.com 620 m=audio 49172 RTP/AVP 98 621 a=rtpmap:98 telephone-events 622 a=sendonly 624 4.2 Audio then Video Added 626 Audio only session is established in initial exchange between Alice 627 and Bob using PCMU codec. Alice adds a video stream which is 628 accepted by Bob. 630 [Offer] 632 v=0 633 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 634 s= 635 c=IN IP4 host.atlanta.example.com 636 t=0 0 637 m=audio 49170 RTP/AVP 0 638 a=rtpmap:0 PCMU/800 640 [Answer] 642 v=0 643 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 644 s= 645 c=IN IP4 host.biloxi.example.com 646 t=0 0 647 m=audio 49172 RTP/AVP 0 648 a=rtpmap:0 PCMU/8000 650 [Second-Offer] 652 v=0 653 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 654 s= 655 c=IN IP4 host.atlanta.example.com 656 t=0 0 657 m=audio 49170 RTP/AVP 0 658 a=rtpmap:0 PCMU/8000 659 m=video 49172 RTP/AVP 31 660 a=rtpmap:31 H261/90000 662 [Second-Answer] 664 v=0 665 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 666 s= 667 c=IN IP4 host.biloxi.example.com 668 t=0 0 669 m=audio 49172 RTP/AVP 0 670 a=rtpmap:0 PCMU/8000 671 m=video 49168 RTP/AVP 31 672 a=rtpmap:31 H261/90000 674 4.3 Audio and Video, then Video Deleted 676 Alice and Bob establish an audio and video session. In a second 677 exchange, Bob deletes the video session resulting in an audio only 678 session. 680 [Offer] 682 v=0 683 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 684 s= 685 c=IN IP4 host.atlanta.example.com 686 t=0 0 687 m=audio 49170 RTP/AVP 97 688 a=rtpmap:97 iLBC 689 m=video 51372 RTP/AVP 31 690 a=rtpmap:31 H261/90000 692 [Answer] 694 v=0 695 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 696 s= 697 c=IN IP4 host.biloxi.example.com 698 t=0 0 699 m=audio 49174 RTP/AVP 97 700 a=rtpmap:0 PCMU/8000 701 m=video 49170 RTP/AVP 31 702 a=rtpmap:31 H261/90000 704 [Second-Offer] 706 v=0 707 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 708 s= 709 c=IN IP4 host.biloxi.example.com 710 t=0 0 711 m=audio 49174 RTP/AVP 97 712 a=rtpmap:97 iLBC 713 m=video 0 RTP/AVP 31 714 a=rtpmap:31 H261/90000 716 [Second-Answer] 718 v=0 719 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 720 s= 721 c=IN IP4 host.atlanta.example.com 722 t=0 0 723 m=audio 49170 RTP/AVP 97 724 a=rtpmap:97 iLBC 725 m=video 0 RTP/AVP 31 726 a=rtpmap:31 H261/90000 728 5. Third Party Call Control (3pcc) 730 This section shows examples common in Third Party Call Control (3pcc) 731 flows [5]. Call hold and resume flows are also common in 3pcc. 733 5.1 No Media, then Audio Added 735 The first offer from Alice contains no media lines, so Bob accepts 736 with no media lines. In the second exchange, Alice adds an audio 737 stream which Bob accepts. 739 [Offer] 741 v=0 742 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 743 s= 744 c=IN IP4 host.atlanta.example.com 745 t=0 0 747 [Answer] 749 v=0 750 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 751 s= 752 c=IN IP4 host.biloxi.example.com 753 t=0 0 755 [Second-Offer] 757 v=0 758 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 759 s= 760 c=IN IP4 host.atlanta.example.com 761 t=0 0 762 m=audio 49170 RTP/AVP 97 763 a=rtpmap:97 iLBC 765 [Second-Answer] 767 v=0 768 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 769 s= 770 c=IN IP4 host.biloxi.example.com 771 t=0 0 772 m=audio 49172 RTP/AVP 97 773 a=rtpmap:97 iLBC 775 5.2 Hold and Unhold 2 777 The first offer from Alice contains the connection address 0.0.0.0 778 and a random port number, which means that Bob can not send media to 779 Alice (the media stream is "black holed" or "bh"). Bob accepts with 780 normal SDP. In the second exchange, Alice changes the connection 781 address, Bob accepts, and a media session is established. 783 [Offer] 785 v=0 786 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 787 s= 788 c=IN IP4 0.0.0.0 789 t=0 0 790 m=audio 23442 RTP/AVP 97 791 a=rtpmap:97 iLBC 793 [Answer] 795 v=0 796 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 797 s= 798 c=IN IP4 host.biloxi.example.com 799 t=0 0 800 m=audio 49170 RTP/AVP 97 801 a=rtpmap:97 iLBC 803 [Second-Offer] 805 v=0 806 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 807 s= 808 c=IN IP4 host.atlanta.example.com 809 t=0 0 810 m=audio 49170 RTP/AVP 97 811 a=rtpmap:97 iLBC 813 [Second-Answer] 815 v=0 816 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 817 s= 818 c=IN IP4 host.biloxi.example.com 819 t=0 0 820 m=audio 49170 RTP/AVP 97 821 a=rtpmap:97 iLBC 823 5.3 Hold and Unhold 3 825 The first offer from Alice contains an audio stream, but the answer 826 from Bob contains the connection address 0.0.0.0 and a random port 827 number, which means that Alice can not send media to Bob (the media 828 stream is "black holed" or "bh"). In the second exchange, Bob changes 829 the connection address, Alice accepts, and a media session is 830 established. 832 [Offer] 834 v=0 835 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 836 s= 837 c=IN IP4 host.atlanta.example.com 838 t=0 0 839 m=audio 49170 RTP/AVP 97 840 a=rtpmap:97 iLBC 842 [Answer] 844 v=0 845 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 846 s= 847 c=IN IP4 0.0.0.0 848 t=0 0 849 m=audio 9322 RTP/AVP 97 850 a=rtpmap:97 iLBC 852 [Second-Offer] 854 v=0 855 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 856 s= 857 c=IN IP4 host.biloxi.example.com 858 t=0 0 859 m=audio 49172 RTP/AVP 97 860 a=rtpmap:97 iLBC 862 [Second-Answer] 864 v=0 865 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 866 s= 867 c=IN IP4 host.atlanta.example.com 868 t=0 0 869 m=audio 49170 RTP/AVP 97 870 a=rtpmap:97 iLBC 872 6. Security Considerations 874 SDP offer and answer messages can contain private information about 875 addresses and sessions to be established between parties. If this 876 information needs to be kept private, some security mechanism in the 877 protocol used to carry the offers and answers must be used. For SIP, 878 this means using TLS transport and/or S/MIME encryption of the SDP 879 message body. 881 Informative References 883 [1] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 884 Session Description Protocol (SDP)", RFC 3264, June 2002. 886 [2] Handley, M. and V. Jacobson, "SDP: Session Description 887 Protocol", RFC 2327, April 1998. 889 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 890 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 891 Session Initiation Protocol", RFC 3261, June 2002. 893 [4] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 894 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 896 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G. and J. Peterson, 897 "Best Current Practices for Third Party Call Control in the 898 Session Initiation Protocol", draft-ietf-sipping-3pcc-02 (work 899 in progress), June 2002. 901 [6] Duric, A. and S. Andersen, "RTP Payload Format for iLBC Speech", 902 draft-ietf-avt-rtp-ilbc-00 (work in progress), October 2002. 904 Authors' Addresses 906 Alan Johnston 907 WorldCom 908 100 South 4th Street 909 St. Louis, MO 63102 911 EMail: alan.johnston@wcom.com 912 Robert J. Sparks 913 dynamicsoft 914 5100 Tennyson Parkway 915 Suite 1200 916 Plano, TX 75024 918 EMail: rsparks@dynamicsoft.com 920 Intellectual Property Statement 922 The IETF takes no position regarding the validity or scope of any 923 intellectual property or other rights that might be claimed to 924 pertain to the implementation or use of the technology described in 925 this document or the extent to which any license under such rights 926 might or might not be available; neither does it represent that it 927 has made any effort to identify any such rights. Information on the 928 IETF's procedures with respect to rights in standards-track and 929 standards-related documentation can be found in BCP-11. Copies of 930 claims of rights made available for publication and any assurances of 931 licenses to be made available, or the result of an attempt made to 932 obtain a general license or permission for the use of such 933 proprietary rights by implementors or users of this specification can 934 be obtained from the IETF Secretariat. 936 The IETF invites any interested party to bring to its attention any 937 copyrights, patents or patent applications, or other proprietary 938 rights which may cover technology that may be required to practice 939 this standard. Please address the information to the IETF Executive 940 Director. 942 Full Copyright Statement 944 Copyright (C) The Internet Society (2003). All Rights Reserved. 946 This document and translations of it may be copied and furnished to 947 others, and derivative works that comment on or otherwise explain it 948 or assist in its implementation may be prepared, copied, published 949 and distributed, in whole or in part, without restriction of any 950 kind, provided that the above copyright notice and this paragraph are 951 included on all such copies and derivative works. However, this 952 document itself may not be modified in any way, such as by removing 953 the copyright notice or references to the Internet Society or other 954 Internet organizations, except as needed for the purpose of 955 developing Internet standards in which case the procedures for 956 copyrights defined in the Internet Standards process must be 957 followed, or as required to translate it into languages other than 958 English. 960 The limited permissions granted above are perpetual and will not be 961 revoked by the Internet Society or its successors or assignees. 963 This document and the information contained herein is provided on an 964 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 965 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 966 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 967 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 968 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 970 Acknowledgement 972 Funding for the RFC Editor function is currently provided by the 973 Internet Society.