idnits 2.17.1 draft-ietf-mmusic-offer-answer-examples-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 967. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 973. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 989), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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 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 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 30, 2004) is 7234 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 840 -- Looks like a reference, but probably isn't: 'Answer' on line 850 -- Looks like a reference, but probably isn't: 'Second-Offer' on line 860 -- Looks like a reference, but probably isn't: 'Second-Answer' on line 870 -- 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 (-05) exists of draft-ietf-avt-rtp-ilbc-04 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MMUSIC Working Group A. Johnston 2 Internet-Draft MCI 3 Expires: December 29, 2004 R. Sparks 4 dynamicsoft 5 June 30, 2004 7 Session Description Protocol Offer Answer Examples 8 draft-ietf-mmusic-offer-answer-examples-03 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 29, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document gives examples of Session Description Protocol (SDP) 42 offer answer exchanges. Examples include codec negotiation and 43 selection, hold and resume, and addition and deletion of media 44 streams. The examples show multiple media types, bidirectional, 45 unidirectional, inactive streams and dynamic payload types. Common 46 Third Party Call Control (3pcc) examples are also given. 48 Table of Contents 50 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Codec Negotiation and Selection . . . . . . . . . . . . . . . 3 52 2.1 Audio and Video 1 . . . . . . . . . . . . . . . . . . . . 3 53 2.2 Audio and Video 2 . . . . . . . . . . . . . . . . . . . . 4 54 2.3 Audio and Video 3 . . . . . . . . . . . . . . . . . . . . 6 55 2.4 Two Audio Streams . . . . . . . . . . . . . . . . . . . . 6 56 2.5 Audio and Video 4 . . . . . . . . . . . . . . . . . . . . 7 57 2.6 Audio Only 1 . . . . . . . . . . . . . . . . . . . . . . . 8 58 2.7 Audio and Video 5 . . . . . . . . . . . . . . . . . . . . 9 59 2.8 Audio and Video 6 . . . . . . . . . . . . . . . . . . . . 11 60 3. Hold and Resume Scenarios . . . . . . . . . . . . . . . . . . 11 61 3.1 Hold and Unhold 1 . . . . . . . . . . . . . . . . . . . . 11 62 3.2 Hold with Two Streams . . . . . . . . . . . . . . . . . . 13 63 4. Addition and Deletion of Media Streams . . . . . . . . . . . . 14 64 4.1 Second Audio Stream Added . . . . . . . . . . . . . . . . 14 65 4.2 Audio then Video Added . . . . . . . . . . . . . . . . . . 15 66 4.3 Audio and Video, then Video Deleted . . . . . . . . . . . 16 67 5. Third Party Call Control (3pcc) . . . . . . . . . . . . . . . 18 68 5.1 No Media, then Audio Added . . . . . . . . . . . . . . . . 18 69 5.2 Hold and Unhold 2 . . . . . . . . . . . . . . . . . . . . 19 70 5.3 Hold and Unhold 3 . . . . . . . . . . . . . . . . . . . . 20 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 72 7. Changes since -00 . . . . . . . . . . . . . . . . . . . . . . 21 73 8. Changes since -01 . . . . . . . . . . . . . . . . . . . . . . 21 74 9. Changes since -02 . . . . . . . . . . . . . . . . . . . . . . 21 75 10. Informative References . . . . . . . . . . . . . . . . . . . 21 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 77 Intellectual Property and Copyright Statements . . . . . . . . 23 79 1. Overview 81 This document describes offer answer examples of Session Description 82 Protocol (SDP) based on RFC 3264 [1]. The SDP in these examples are 83 defined by RFC 2327 [2]. The offers and answers are assumed to be 84 transported using a protocol such as Session Initiation Protocol 85 (SIP) [3]. 87 Examples include codec negotiation and selection, hold and resume, 88 and addition and deletion of media streams. The examples show 89 multiple media types, bidirectional, unidirectional, inactive streams 90 and dynamic payload types. Common Third Party Call Control (3pcc) 91 [5] examples are also given. 93 The following sections contain examples in which two parties, Alice 94 and Bob, exchange SDP offers, answers, and, in some cases, additional 95 offers and answers. 97 2. Codec Negotiation and Selection 99 2.1 Audio and Video 1 101 This common scenario shows a video and audio session in which 102 multiple codecs are offered but only one is accepted. As a result of 103 the exchange shown below, Alice and Bob may send only PCMU audio and 104 MPV video. Note: Dynamic payload type 97 is used for iLBC codec [6]. 106 [Offer] 108 v=0 109 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 110 s= 111 c=IN IP4 host.atlanta.example.com 112 t=0 0 113 m=audio 49170 RTP/AVP 0 8 97 114 a=rtpmap:0 PCMU/8000 115 a=rtpmap:8 PCMA/8000 116 a=rtpmap:97 iLBC/8000 117 m=video 51372 RTP/AVP 31 32 118 a=rtpmap:31 H261/90000 119 a=rtpmap:32 MPV/90000 121 [Answer] 123 v=0 124 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 125 s= 126 c=IN IP4 host.biloxi.example.com 127 t=0 0 128 m=audio 49174 RTP/AVP 0 129 a=rtpmap:0 PCMU/8000 130 m=video 49170 RTP/AVP 32 131 a=rtpmap:32 MPV/90000 133 2.2 Audio and Video 2 135 Alice can support PCMU, PCMA, and iLBC codecs, but not more than one 136 at the same time. Alice offers all three to maximize chances of a 137 successful exchange and Bob accepts two of them. Audio only session 138 is established in initial exchange between Alice and Bob using either 139 PCMU or PCMA codecs (payload type in RTP packet tells which is being 140 used). Since Alice only supports one audio codec at a time, a second 141 offer is made with just that one codec to limit the codec choice to 142 just one. 144 Note: the version number is incremented in both SDP messages in the 145 second exchange. Now only the PCMU codec may be used for media 146 session between Alice and Bob. 148 Note: The declined video stream still present in the second exchange 149 of SDP with ports set to zero. 151 [Offer] 153 v=0 154 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 155 s= 156 c=IN IP4 host.atlanta.example.com 157 t=0 0 158 m=audio 49170 RTP/AVP 0 8 97 159 a=rtpmap:0 PCMU/8000 160 a=rtpmap:8 PCMA/8000 161 a=rtpmap:97 iLBC/8000 162 m=video 51372 RTP/AVP 31 32 163 a=rtpmap:31 H261/90000 164 a=rtpmap:32 MPV/90000 166 [Answer] 168 v=0 169 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 170 s= 171 c=IN IP4 host.biloxi.example.com 172 t=0 0 173 m=audio 49172 RTP/AVP 0 8 174 a=rtpmap:0 PCMU/8000 175 a=rtpmap:8 PCMA/8000 176 m=video 0 RTP/AVP 31 177 a=rtpmap:31 H261/90000 179 [Second-Offer] 181 v=0 182 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 183 s= 184 c=IN IP4 host.atlanta.example.com 185 t=0 0 186 m=audio 51372 RTP/AVP 0 187 a=rtpmap:0 PCMU/8000 188 m=video 0 RTP/AVP 31 189 a=rtpmap:31 H261/90000 191 [Second-Answer] 193 v=0 194 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 195 s= 196 c=IN IP4 host.biloxi.example.com 197 t=0 0 198 m=audio 49172 RTP/AVP 0 199 a=rtpmap:0 PCMU/8000 200 m=video 0 RTP/AVP 31 201 a=rtpmap:31 H261/90000 203 2.3 Audio and Video 3 205 Alice offers three audio and two video codecs, while Bob accepts with 206 a single audio and video codec. As a result of this exchange, Bob 207 and Alice use iLBC for audio and H261 for video. 209 Note: change of dynamic payload type from 97 to 99 between the offer 210 and the answer is OK since it references same codec. 212 [Offer] 214 v=0 215 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 216 s= 217 c=IN IP4 host.atlanta.example.com 218 t=0 0 219 m=audio 49170 RTP/AVP 0 8 97 220 a=rtpmap:0 PCMU/8000 221 a=rtpmap:8 PCMA/8000 222 a=rtpmap:97 iLBC/8000 223 m=video 51372 RTP/AVP 31 32 224 a=rtpmap:31 H261/90000 225 a=rtpmap:32 MPV/90000 227 [Answer] 229 v=0 230 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 231 s= 232 c=IN IP4 host.biloxi.example.com 233 t=0 0 234 m=audio 49172 RTP/AVP 99 235 a=rtpmap:99 iLBC/8000 236 m=video 51374 RTP/AVP 31 237 a=rtpmap:31 H261/90000 239 2.4 Two Audio Streams 241 Alice offers two separate streams, one audio with two codecs and the 242 other with RFC 2833 [4] tones (for DTMF). Bob accepts both audio 243 streams choosing the iLBC codec and telephone-events. 245 [Offer] 247 v=0 248 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 249 s= 250 c=IN IP4 host.atlanta.example.com 251 t=0 0 252 m=audio 49170 RTP/AVP 0 97 253 a=rtpmap:0 PCMU/8000 254 a=rtpmap:97 iLBC/8000 255 m=audio 49172 RTP/AVP 98 256 a=rtpmap:98 telephone-event/8000 257 a=sendonly 259 [Answer] 261 v=0 262 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 263 s= 264 c=IN IP4 host.biloxi.example.com 265 t=0 0 266 m=audio 49172 RTP/AVP 97 267 a=rtpmap:97 iLBC/8000 268 m=audio 49174 RTP/AVP 98 269 a=rtpmap:98 telephone-event/8000 270 a=recvonly 272 2.5 Audio and Video 4 274 Alice and Bob establish an audio and video session with a single 275 audio and video codec. In a second exchange, Bob changes his address 276 for media and Alice accepts with the same SDP as the initial exchange 277 (and as a result does not increment the version number). 279 [Offer] 281 v=0 282 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 283 s= 284 c=IN IP4 host.atlanta.example.com 285 t=0 0 286 m=audio 49170 RTP/AVP 97 287 a=rtpmap:97 iLBC/8000 288 m=video 51372 RTP/AVP 31 289 a=rtpmap:31 H261/90000 291 [Answer] 293 v=0 294 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 295 s= 296 c=IN IP4 host.biloxi.example.com 297 t=0 0 298 m=audio 49174 RTP/AVP 97 299 a=rtpmap:97 iLBC/8000 300 m=video 49170 RTP/AVP 31 301 a=rtpmap:31 H261/90000 303 [Second-Offer] 305 v=0 306 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 307 s= 308 c=IN IP4 newhost.biloxi.example.com 309 t=0 0 310 m=audio 49178 RTP/AVP 97 311 a=rtpmap:97 iLBC/8000 312 m=video 49188 RTP/AVP 31 313 a=rtpmap:31 H261/90000 315 [Second-Answer] 317 v=0 318 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 319 s= 320 c=IN IP4 host.atlanta.example.com 321 t=0 0 322 m=audio 49170 RTP/AVP 97 323 a=rtpmap:97 iLBC/8000 324 m=video 51372 RTP/AVP 31 325 a=rtpmap:31 H261/90000 327 2.6 Audio Only 1 329 Alice wishes to establish an audio session with Bob using either PCMU 330 codec or iLBC codec with RFC2833 tones, but not both at the same 331 time. The offer contains these two media streams. Bob declines the 332 first one and accepts the second one. If both media streams had been 333 accepted, Alice would have sent a second declining one of the 334 streams, as shown in Section 4.3. 336 [Offer] 338 v=0 339 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 340 s= 341 c=IN IP4 host.atlanta.example.com 342 t=0 0 343 m=audio 49170 RTP/AVP 0 344 a=rtpmap:0 PCMU/8000 345 m=audio 51372 RTP/AVP 97 101 346 a=rtpmap:97 iLBC/8000 347 a=rtpmap:101 telephone-event/8000 349 [Answer] 351 v=0 352 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 353 s= 354 c=IN IP4 host.biloxi.example.com 355 t=0 0 356 m=audio 0 RTP/AVP 0 357 a=rtpmap:0 PCMU/8000 358 m=audio 49170 RTP/AVP 97 101 359 a=rtpmap:97 iLBC/8000 360 a=rtpmap:101 telephone-event/8000 362 2.7 Audio and Video 5 364 Alice and Bob establish an audio and video session in the first 365 exchange with a single audio and video codec. In the second 366 exchange, Alice adds a second video codec which Bob accepts which 367 allows Alice and Bob to switch between the two video codecs without 368 another offer/answer exchange. 370 [Offer] 372 v=0 373 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 374 s= 375 c=IN IP4 host.atlanta.example.com 376 t=0 0 377 m=audio 49170 RTP/AVP 99 378 a=rtpmap:99 iLBC/8000 379 m=video 51372 RTP/AVP 31 380 a=rtpmap:31 H261/90000 382 [Answer] 384 v=0 385 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 386 s= 387 c=IN IP4 host.biloxi.example.com 388 t=0 0 389 m=audio 49172 RTP/AVP 99 390 a=rtpmap:99 iLBC/8000 391 m=video 51374 RTP/AVP 31 392 a=rtpmap:31 H261/90000 394 [Second-Offer] 396 v=0 397 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 398 s= 399 c=IN IP4 host.atlanta.example.com 400 t=0 0 401 m=audio 49170 RTP/AVP 99 402 a=rtpmap:99 iLBC/8000 403 m=video 51372 RTP/AVP 31 32 404 a=rtpmap:31 H261/90000 405 a=rtpmap:32 MPV/90000 407 [Second-Answer] 409 v=0 410 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 411 s= 412 c=IN IP4 host.biloxi.example.com 413 t=0 0 414 m=audio 49172 RTP/AVP 99 415 a=rtpmap:99 iLBC/8000 416 m=video 51374 RTP/AVP 31 32 417 a=rtpmap:31 H261/90000 418 a=rtpmap:32 MPV/90000 420 2.8 Audio and Video 6 422 This scenario shows an audio and video offer that is accepted, but 423 the answerer wants the video sent to a different address than the 424 audio. This is a common scenario in conferencing where the video and 425 audio mixing utilizes different servers. In this example, Alice 426 offers audio and video and Bob accepts. 428 [Offer] 430 v=0 431 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 432 s= 433 c=IN IP4 host.atlanta.example.com 434 t=0 0 435 m=audio 49170 RTP/AVP 0 8 97 436 a=rtpmap:0 PCMU/8000 437 a=rtpmap:8 PCMA/8000 438 a=rtpmap:97 iLBC/8000 439 m=video 51372 RTP/AVP 31 32 440 a=rtpmap:31 H261/90000 441 a=rtpmap:32 MPV/90000 443 [Answer] 445 v=0 446 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 447 s= 448 c=IN IP4 host.biloxi.example.com 449 t=0 0 450 m=audio 49174 RTP/AVP 0 451 a=rtpmap:0 PCMU/8000 452 m=video 49172 RTP/AVP 32 453 c=IN IP4 otherhost.biloxi.example.com 454 a=rtpmap:32 MPV/90000 456 3. Hold and Resume Scenarios 458 3.1 Hold and Unhold 1 460 Alice calls Bob, but Bob answers placing Alice on hold. Bob then 461 takes Alice off hold in the second offer. Alice changes port number 462 in the second exchange. The media session between Alice and Bob is 463 now active after Alice's second answer. Note that a=sendrecv could 464 be present in both second offer and answer exchange. This is a 465 common flow in 3pcc [5] scenarios. 467 [Offer] 469 v=0 470 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 471 s= 472 c=IN IP4 host.atlanta.example.com 473 t=0 0 474 m=audio 49170 RTP/AVP 0 97 475 a=rtpmap:0 PCMU/8000 476 a=rtpmap:97 iLBC/8000 478 [Answer] 480 v=0 481 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 482 s= 483 c=IN IP4 placeholder.biloxi.example.com 484 t=0 0 485 m=audio 49172 RTP/AVP 97 486 a=rtpmap:97 iLBC/8000 487 a=sendonly 489 [Second-Offer] 491 v=0 492 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 493 s= 494 c=IN IP4 host.biloxi.example.com 495 t=0 0 496 m=audio 49170 RTP/AVP 97 497 a=rtpmap:97 iLBC/8000 499 [Second-Answer] 501 v=0 502 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 503 s= 504 c=IN IP4 host.atlanta.example.com 505 t=0 0 506 m=audio 49178 RTP/AVP 97 507 a=rtpmap:97 iLBC/8000 509 3.2 Hold with Two Streams 511 Alice sends but can not receive RFC2833 tones in a separate audio 512 stream. Bob accepts both audio streams. Bob then puts Alice's audio 513 stream on hold but not the tone stream. Alice responds with 514 identical SDP to the initial offer. 516 [Offer] 518 v=0 519 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 520 s= 521 c=IN IP4 host.atlanta.example.com 522 t=0 0 523 m=audio 49170 RTP/AVP 0 97 524 a=rtpmap:0 PCMU/8000 525 a=rtpmap:97 iLBC/8000 526 m=audio 49172 RTP/AVP 98 527 a=rtpmap:98 telephone-event/8000 528 a=sendonly 530 [Answer] 532 v=0 533 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 534 s= 535 c=IN IP4 host.biloxi.example.com 536 t=0 0 537 m=audio 49172 RTP/AVP 97 538 a=rtpmap:97 iLBC/8000 539 m=audio 49174 RTP/AVP 98 540 a=rtpmap:98 telephone-event/8000 541 a=recvonly 543 [Second-Offer] 545 v=0 546 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 547 s= 548 c=IN IP4 host.biloxi.example.com 549 t=0 0 550 m=audio 49172 RTP/AVP 97 551 a=rtpmap:97 iLBC/8000 552 a=sendonly 553 m=audio 49174 RTP/AVP 98 554 a=rtpmap:98 telephone-event/8000 555 a=recvonly 557 [Second-Answer] 559 v=0 560 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 561 s= 562 c=IN IP4 host.atlanta.example.com 563 t=0 0 564 m=audio 49170 RTP/AVP 0 97 565 a=rtpmap:0 PCMU/8000 566 a=rtpmap:97 iLBC/8000 567 m=audio 49172 RTP/AVP 98 568 a=rtpmap:98 telephone-event/8000 569 a=sendonly 571 4. Addition and Deletion of Media Streams 573 This section shows addition and deletion of media streams. 575 4.1 Second Audio Stream Added 577 The second stream is added by Bob's media server (different 578 connection address) to receive RFC 2833 telephone-events (DTMF 579 digits, typically) from Alice. Alice accepts. Even though the 2nd 580 stream is unidirectional, Alice receives RTCP packets on port 49173 581 from the media server. 583 [Offer] 585 v=0 586 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 587 s= 588 c=IN IP4 host.atlanta.example.com 589 t=0 0 590 m=audio 49170 RTP/AVP 0 97 591 a=rtpmap:0 PCMU/8000 592 a=rtpmap:97 iLBC/8000 594 [Answer] 596 v=0 597 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 598 s= 599 c=IN IP4 host.biloxi.example.com 600 t=0 0 601 m=audio 49170 RTP/AVP 97 602 a=rtpmap:97 iLBC/8000 604 [Second-Offer] 606 v=0 607 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 608 s= 609 c=IN IP4 host.biloxi.example.com 610 t=0 0 611 m=audio 49170 RTP/AVP 97 612 a=rtpmap:97 iLBC/8000 613 m=audio 48282 RTP/AVP 98 614 c=IN IP4 mediaserver.biloxi.example.com 615 a=rtpmap:98 telephone-event/8000 616 a=recvonly 618 [Second-Answer] 620 v=0 621 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 622 s= 623 c=IN IP4 host.atlanta.example.com 624 t=0 0 625 m=audio 49170 RTP/AVP 97 626 a=rtpmap:97 iLBC/8000 627 m=audio 49172 RTP/AVP 98 628 c=IN IP4 host.atlanta.example.com 629 a=rtpmap:98 telephone-event/8000 630 a=sendonly 632 4.2 Audio then Video Added 634 Audio only session is established in initial exchange between Alice 635 and Bob using PCMU codec. Alice adds a video stream which is 636 accepted by Bob. 638 [Offer] 640 v=0 641 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 642 s= 643 c=IN IP4 host.atlanta.example.com 644 t=0 0 645 m=audio 49170 RTP/AVP 0 646 a=rtpmap:0 PCMU/800 648 [Answer] 650 v=0 651 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 652 s= 653 c=IN IP4 host.biloxi.example.com 654 t=0 0 655 m=audio 49172 RTP/AVP 0 656 a=rtpmap:0 PCMU/8000 658 [Second-Offer] 660 v=0 661 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 662 s= 663 c=IN IP4 host.atlanta.example.com 664 t=0 0 665 m=audio 49170 RTP/AVP 0 666 a=rtpmap:0 PCMU/8000 667 m=video 49172 RTP/AVP 31 668 a=rtpmap:31 H261/90000 670 [Second-Answer] 672 v=0 673 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 674 s= 675 c=IN IP4 host.biloxi.example.com 676 t=0 0 677 m=audio 49172 RTP/AVP 0 678 a=rtpmap:0 PCMU/8000 679 m=video 49168 RTP/AVP 31 680 a=rtpmap:31 H261/90000 682 4.3 Audio and Video, then Video Deleted 684 Alice and Bob establish an audio and video session. In a second 685 exchange, Bob deletes the video session resulting in an audio only 686 session. 688 [Offer] 690 v=0 691 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 692 s= 693 c=IN IP4 host.atlanta.example.com 694 t=0 0 695 m=audio 49170 RTP/AVP 97 696 a=rtpmap:97 iLBC/8000 697 m=video 51372 RTP/AVP 31 698 a=rtpmap:31 H261/90000 700 [Answer] 702 v=0 703 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 704 s= 705 c=IN IP4 host.biloxi.example.com 706 t=0 0 707 m=audio 49174 RTP/AVP 97 708 a=rtpmap:97 iLBC/8000 709 m=video 49170 RTP/AVP 31 710 a=rtpmap:31 H261/90000 712 [Second-Offer] 714 v=0 715 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 716 s= 717 c=IN IP4 host.biloxi.example.com 718 t=0 0 719 m=audio 49174 RTP/AVP 97 720 a=rtpmap:97 iLBC/8000 721 m=video 0 RTP/AVP 31 722 a=rtpmap:31 H261/90000 724 [Second-Answer] 726 v=0 727 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 728 s= 729 c=IN IP4 host.atlanta.example.com 730 t=0 0 731 m=audio 49170 RTP/AVP 97 732 a=rtpmap:97 iLBC/8000 733 m=video 0 RTP/AVP 31 734 a=rtpmap:31 H261/90000 736 5. Third Party Call Control (3pcc) 738 This section shows examples common in Third Party Call Control (3pcc) 739 flows [5]. Call hold and resume flows are also common in 3pcc. 741 5.1 No Media, then Audio Added 743 The first offer from Alice contains no media lines, so Bob accepts 744 with no media lines. In the second exchange, Alice adds an audio 745 stream which Bob accepts. 747 [Offer] 749 v=0 750 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 751 s= 752 c=IN IP4 host.atlanta.example.com 753 t=0 0 755 [Answer] 757 v=0 758 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 759 s= 760 c=IN IP4 host.biloxi.example.com 761 t=0 0 763 [Second-Offer] 765 v=0 766 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 767 s= 768 c=IN IP4 host.atlanta.example.com 769 t=0 0 770 m=audio 49170 RTP/AVP 97 771 a=rtpmap:97 iLBC/8000 773 [Second-Answer] 775 v=0 776 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 777 s= 778 c=IN IP4 host.biloxi.example.com 779 t=0 0 780 m=audio 49172 RTP/AVP 97 781 a=rtpmap:97 iLBC/8000 783 5.2 Hold and Unhold 2 785 The first offer from Alice contains the connection address 0.0.0.0 786 and a random port number, which means that Bob can not send media to 787 Alice (the media stream is "black holed" or "bh"). Bob accepts with 788 normal SDP. In the second exchange, Alice changes the connection 789 address, Bob accepts, and a media session is established. 791 [Offer] 793 v=0 794 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 795 s= 796 c=IN IP4 0.0.0.0 797 t=0 0 798 m=audio 23442 RTP/AVP 97 799 a=rtpmap:97 iLBC/8000 801 [Answer] 803 v=0 804 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 805 s= 806 c=IN IP4 host.biloxi.example.com 807 t=0 0 808 m=audio 49170 RTP/AVP 97 809 a=rtpmap:97 iLBC/8000 811 [Second-Offer] 813 v=0 814 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com 815 s= 816 c=IN IP4 host.atlanta.example.com 817 t=0 0 818 m=audio 49170 RTP/AVP 97 819 a=rtpmap:97 iLBC/8000 821 [Second-Answer] 823 v=0 824 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 825 s= 826 c=IN IP4 host.biloxi.example.com 827 t=0 0 828 m=audio 49170 RTP/AVP 97 829 a=rtpmap:97 iLBC/8000 831 5.3 Hold and Unhold 3 833 The first offer from Alice contains an audio stream, but the answer 834 from Bob contains the connection address 0.0.0.0 and a random port 835 number, which means that Alice can not send media to Bob (the media 836 stream is "black holed" or "bh"). In the second exchange, Bob 837 changes the connection address, Alice accepts, and a media session is 838 established. 840 [Offer] 842 v=0 843 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 844 s= 845 c=IN IP4 host.atlanta.example.com 846 t=0 0 847 m=audio 49170 RTP/AVP 97 848 a=rtpmap:97 iLBC/8000 850 [Answer] 852 v=0 853 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com 854 s= 855 c=IN IP4 0.0.0.0 856 t=0 0 857 m=audio 9322 RTP/AVP 97 858 a=rtpmap:97 iLBC/8000 860 [Second-Offer] 862 v=0 863 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com 864 s= 865 c=IN IP4 host.biloxi.example.com 866 t=0 0 867 m=audio 49172 RTP/AVP 97 868 a=rtpmap:97 iLBC/8000 870 [Second-Answer] 872 v=0 873 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com 874 s= 875 c=IN IP4 host.atlanta.example.com 876 t=0 0 877 m=audio 49170 RTP/AVP 97 878 a=rtpmap:97 iLBC/8000 880 6. Security Considerations 882 SDP offer and answer messages can contain private information about 883 addresses and sessions to be established between parties. If this 884 information needs to be kept private, some security mechanism in the 885 protocol used to carry the offers and answers must be used. For SIP, 886 this means using TLS transport and/or S/MIME encryption of the SDP 887 message body. 889 7. Changes since -00 891 - Added asymmetrical codec and attribute examples 893 8. Changes since -01 895 - Removed asymmetrical codec and attribute examples 897 - Updated references 899 9. Changes since -02 901 - Updated references 903 - Added sampling rate to iLBC rtmap lines 905 - Added sampling rate to telephone-event rtmap lines 907 - Fixed order of c= line in 4.1 Second Answer 909 - Fixed a= line in 4.3 Answer 911 10 Informative References 913 [1] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 914 Session Description Protocol (SDP)", RFC 3264, June 2002. 916 [2] Handley, M. and V. Jacobson, "SDP: Session Description 917 Protocol", RFC 2327, April 1998. 919 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 920 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 921 Session Initiation Protocol", RFC 3261, June 2002. 923 [4] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, 924 Telephony Tones and Telephony Signals", RFC 2833, May 2000. 926 [5] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, 927 "Best Current Practices for Third Party Call Control (3pcc) in 928 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 929 2004. 931 [6] Duric, A. and S. Andersen, "RTP Payload Format for iLBC Speech", 932 draft-ietf-avt-rtp-ilbc-04 (work in progress), December 2003. 934 Authors' Addresses 936 Alan Johnston 937 MCI 938 100 South 4th Street 939 St. Louis, MO 63102 941 EMail: alan.johnston@mci.com 943 Robert J. Sparks 944 dynamicsoft 945 5100 Tennyson Parkway 946 Suite 1200 947 Plano, TX 75024 949 EMail: rsparks@dynamicsoft.com 951 Intellectual Property Statement 953 The IETF takes no position regarding the validity or scope of any 954 Intellectual Property Rights or other rights that might be claimed to 955 pertain to the implementation or use of the technology described in 956 this document or the extent to which any license under such rights 957 might or might not be available; nor does it represent that it has 958 made any independent effort to identify any such rights. Information 959 on the procedures with respect to rights in RFC documents can be 960 found in BCP 78 and BCP 79. 962 Copies of IPR disclosures made to the IETF Secretariat and any 963 assurances of licenses to be made available, or the result of an 964 attempt made to obtain a general license or permission for the use of 965 such proprietary rights by implementers or users of this 966 specification can be obtained from the IETF on-line IPR repository at 967 http://www.ietf.org/ipr. 969 The IETF invites any interested party to bring to its attention any 970 copyrights, patents or patent applications, or other proprietary 971 rights that may cover technology that may be required to implement 972 this standard. Please address the information to the IETF at 973 ietf-ipr@ietf.org. 975 Disclaimer of Validity 977 This document and the information contained herein are provided on an 978 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 979 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 980 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 981 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 982 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 983 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 985 Copyright Statement 987 Copyright (C) The Internet Society (2004). This document is subject 988 to the rights, licenses and restrictions contained in BCP 78, and 989 except as set forth therein, the authors retain all their rights. 991 Acknowledgment 993 Funding for the RFC Editor function is currently provided by the 994 Internet Society.