diff options
Diffstat (limited to 'doc/rfc/rfc4317.txt')
| -rw-r--r-- | doc/rfc/rfc4317.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc4317.txt b/doc/rfc/rfc4317.txt new file mode 100644 index 0000000..a2809da --- /dev/null +++ b/doc/rfc/rfc4317.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group A. Johnston +Request for Comments: 4317 Tello Corporation +Category: Informational R. Sparks + Estacado Systems + December 2005 + + + Session Description Protocol (SDP) + Offer/Answer Examples + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document gives examples of Session Description Protocol (SDP) + offer/answer exchanges. Examples include codec negotiation and + selection, hold and resume, and addition and deletion of media + streams. The examples show multiple media types, bidirectional, + unidirectional, inactive streams, and dynamic payload types. Common + Third Party Call Control (3pcc) examples are also given. + + + + + + + + + + + + + + + + + + + + + + + +Johnston & Sparks Informational [Page 1] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + +Table of Contents + + 1. Overview ........................................................3 + 2. Codec Negotiation and Selection .................................3 + 2.1. Audio and Video 1 ..........................................3 + 2.2. Audio and Video 2 ..........................................4 + 2.3. Audio and Video 3 ..........................................5 + 2.4. Two Audio Streams ..........................................6 + 2.5. Audio and Video 4 ..........................................7 + 2.6. Audio Only 1 ...............................................8 + 2.7. Audio and Video 5 ..........................................9 + 2.8. Audio and Video 6 .........................................10 + 3. Hold and Resume Scenarios ......................................12 + 3.1. Hold and Unhold 1 .........................................12 + 3.2. Hold with Two Streams .....................................13 + 4. Addition and Deletion of Media Streams .........................15 + 4.1. Second Audio Stream Added .................................15 + 4.2. Audio, then Video Added ...................................16 + 4.3. Audio and Video, Then Video Deleted .......................17 + 5. Third Party Call Control (3pcc) ................................19 + 5.1. No Media, Then Audio Added ................................19 + 5.2. Hold and Unhold 2 .........................................20 + 5.3. Hold and Unhold 3 .........................................21 + 6. Security Considerations ........................................22 + 7. Informative References .........................................22 + + + + + + + + + + + + + + + + + + + + + + + + + + +Johnston & Sparks Informational [Page 2] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + +1. Overview + + This document describes offer/answer examples of Session Description + Protocol (SDP) based on RFC 3264 [1]. The SDP in these examples is + defined by RFC 2327 [2]. The offers and answers are assumed to be + transported using a protocol such as Session Initiation Protocol + (SIP) [3]. + + Examples include codec negotiation and selection, hold and resume, + and addition and deletion of media streams. The examples show + multiple media types, bidirectional, unidirectional, inactive + streams, and dynamic payload types. Common Third Party Call Control + (3pcc) [5] examples are also given. + + The following sections contain examples in which two parties, Alice + and Bob, exchange SDP offers, answers, and, in some cases, additional + offers and answers. Note that the subject line (s=) contains a + single space character. + +2. Codec Negotiation and Selection + +2.1. Audio and Video 1 + + This common scenario shows a video and audio session in which + multiple codecs are offered but only one is accepted. As a result of + the exchange shown below, Alice and Bob may send only PCMU audio and + MPV video. Note: Dynamic payload type 97 is used for iLBC codec [6]. + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 8 97 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + a=rtpmap:97 iLBC/8000 + m=video 51372 RTP/AVP 31 32 + a=rtpmap:31 H261/90000 + a=rtpmap:32 MPV/90000 + + + + + + + + + +Johnston & Sparks Informational [Page 3] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49174 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + m=video 49170 RTP/AVP 32 + a=rtpmap:32 MPV/90000 + +2.2. Audio and Video 2 + + Alice can support PCMU, PCMA, and iLBC codecs, but not more than one + at the same time. Alice offers all three to maximize chances of a + successful exchange, and Bob accepts two of them. An audio-only + session is established in the initial exchange between Alice and Bob, + using either PCMU or PCMA codecs (payload type in RTP packet tells + which is being used). Since Alice only supports one audio codec at a + time, a second offer is made with just that one codec, to limit the + codec choice to just one. + + Note: the version number is incremented in both SDP messages in the + second exchange. After this exchange, only the PCMU codec may be + used for media session between Alice and Bob. + + Note: The declined video stream still present in the second exchange + of SDP with ports set to zero. + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 8 97 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + a=rtpmap:97 iLBC/8000 + m=video 51372 RTP/AVP 31 32 + a=rtpmap:31 H261/90000 + a=rtpmap:32 MPV/90000 + + + + + + + +Johnston & Sparks Informational [Page 4] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 0 8 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + m=video 0 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + [Second-Offer] + + v=0 + o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 51372 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + m=video 0 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + [Second-Answer] + + v=0 + o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + m=video 0 RTP/AVP 31 + a=rtpmap:31 H261/90000 + +2.3. Audio and Video 3 + + Alice offers three audio and two video codecs, while Bob accepts with + a single audio and video codec. As a result of this exchange, Bob + and Alice use iLBC for audio and H261 for video. + + Note: change of dynamic payload type from 97 to 99 between the offer + and the answer is OK since the same codec is referenced. + + + + + + +Johnston & Sparks Informational [Page 5] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 8 97 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + a=rtpmap:97 iLBC/8000 + m=video 51372 RTP/AVP 31 32 + a=rtpmap:31 H261/90000 + a=rtpmap:32 MPV/90000 + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 99 + a=rtpmap:99 iLBC/8000 + m=video 51374 RTP/AVP 31 + a=rtpmap:31 H261/90000 + +2.4. Two Audio Streams + + In this example, Alice wishes to establish separate audio streams, + one for normal audio and the other for telephone-events. Alice + offers two separate streams, one audio with two codecs and the other + with RFC 2833 [4] tones (for DTMF). Bob accepts both audio streams + choosing the iLBC codec and telephone-events. + + + + + + + + + + + + + + + + + +Johnston & Sparks Informational [Page 6] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 97 + a=rtpmap:0 PCMU/8000 + a=rtpmap:97 iLBC/8000 + m=audio 49172 RTP/AVP 98 + a=rtpmap:98 telephone-event/8000 + a=sendonly + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=audio 49174 RTP/AVP 98 + a=rtpmap:98 telephone-event/8000 + a=recvonly + +2.5. Audio and Video 4 + + Alice and Bob establish an audio and video session with a single + audio and video codec. In a second exchange, Bob changes his address + for media and Alice accepts with the same SDP as the initial exchange + (and as a result does not increment the version number). + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=video 51372 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + + + + + +Johnston & Sparks Informational [Page 7] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49174 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=video 49170 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + [Second-Offer] + + v=0 + o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com + s= + c=IN IP4 newhost.biloxi.example.com + t=0 0 + m=audio 49178 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=video 49188 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + [Second-Answer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=video 51372 RTP/AVP 31 + a=rtpmap:31 H261/90000 + +2.6. Audio Only 1 + + Alice wishes to establish an audio session with Bob using either PCMU + codec or iLBC codec with RFC2833 tones, but not both at the same + time. The offer contains these two media streams. Bob declines the + first one and accepts the second one. If both media streams had been + accepted, Alice would have sent a second declining one of the + streams, as shown in Section 4.3. + + + + + + + +Johnston & Sparks Informational [Page 8] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + m=audio 51372 RTP/AVP 97 101 + a=rtpmap:97 iLBC/8000 + a=rtpmap:101 telephone-event/8000 + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 0 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + m=audio 49170 RTP/AVP 97 101 + a=rtpmap:97 iLBC/8000 + a=rtpmap:101 telephone-event/8000 + +2.7. Audio and Video 5 + + Alice and Bob establish an audio and video session in the first + exchange with a single audio and video codec. In the second + exchange, Alice adds a second video codec, which Bob accepts. This + allows Alice and Bob to switch between the two video codecs without + another offer/answer exchange. + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 99 + a=rtpmap:99 iLBC/8000 + m=video 51372 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + + + + + +Johnston & Sparks Informational [Page 9] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 99 + a=rtpmap:99 iLBC/8000 + m=video 51374 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + [Second-Offer] + + v=0 + o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 99 + a=rtpmap:99 iLBC/8000 + m=video 51372 RTP/AVP 31 32 + a=rtpmap:31 H261/90000 + a=rtpmap:32 MPV/90000 + + [Second-Answer] + + v=0 + o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 99 + a=rtpmap:99 iLBC/8000 + m=video 51374 RTP/AVP 31 32 + a=rtpmap:31 H261/90000 + a=rtpmap:32 MPV/90000 + +2.8. Audio and Video 6 + + This example shows an audio and video offer that is accepted, but the + answerer wants the video sent to a different address than that of the + audio. This is a common scenario in conferencing where the video and + audio mixing utilizes different servers. In this example, Alice + offers audio and video, and Bob accepts. + + + + + +Johnston & Sparks Informational [Page 10] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 8 97 + a=rtpmap:0 PCMU/8000 + a=rtpmap:8 PCMA/8000 + a=rtpmap:97 iLBC/8000 + m=video 51372 RTP/AVP 31 32 + a=rtpmap:31 H261/90000 + a=rtpmap:32 MPV/90000 + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49174 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + m=video 49172 RTP/AVP 32 + c=IN IP4 otherhost.biloxi.example.com + a=rtpmap:32 MPV/90000 + + + + + + + + + + + + + + + + + + + + + + + + +Johnston & Sparks Informational [Page 11] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + +3. Hold and Resume Scenarios + +3.1. Hold and Unhold 1 + + Alice calls Bob, but when Bob answers he places Alice on hold. Bob + then takes Alice off hold in the second offer. Alice changes port + number in the second exchange. The media session between Alice and + Bob is now active after Alice's second answer. Note that a=sendrecv + could be present in both second offer and answer exchange. This is a + common flow in 3pcc [5] scenarios. + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 97 + a=rtpmap:0 PCMU/8000 + a=rtpmap:97 iLBC/8000 + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 placeholder.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + a=sendonly + + [Second-Offer] + + v=0 + o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + + + + + + + + +Johnston & Sparks Informational [Page 12] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + + [Second-Answer] + + v=0 + o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49178 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + +3.2. Hold with Two Streams + + In this example, two audio streams have been established in the first + offer/answer exchange. In this second offer/answer exchange, one of + the audio streams is placed on hold. Alice offers two media streams, + a bidirectional audio stream and a send-only telephone event stream. + Bob accepts both streams. Bob then puts Alice's audio stream on hold + but not the tone stream. Alice responds with identical SDP to the + initial offer. + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 97 + a=rtpmap:0 PCMU/8000 + a=rtpmap:97 iLBC/8000 + m=audio 49172 RTP/AVP 98 + a=rtpmap:98 telephone-event/8000 + a=sendonly + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=audio 49174 RTP/AVP 98 + a=rtpmap:98 telephone-event/8000 + a=recvonly + + + + +Johnston & Sparks Informational [Page 13] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + [Second-Offer] + + v=0 + o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + a=sendonly + m=audio 49174 RTP/AVP 98 + a=rtpmap:98 telephone-event/8000 + a=recvonly + + [Second-Answer] + + v=0 + o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 97 + a=rtpmap:0 PCMU/8000 + a=rtpmap:97 iLBC/8000 + m=audio 49172 RTP/AVP 98 + a=rtpmap:98 telephone-event/8000 + a=sendonly + + + + + + + + + + + + + + + + + + + + + + + + +Johnston & Sparks Informational [Page 14] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + +4. Addition and Deletion of Media Streams + + This section shows addition and deletion of media streams. + +4.1. Second Audio Stream Added + + In this example, the first offer/answer exchange establishes a single + audio stream with a single codec. The second offer/answer exchange + adds a second audio stream for telephone events. The second stream + is added by Bob's media server (different connection address) to + receive RFC 2833 telephone-events (DTMF digits, typically) from + Alice. Alice accepts. Even though the second stream is + unidirectional, Alice receives RTCP packets on port 49173 from the + media server. + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 97 + a=rtpmap:0 PCMU/8000 + a=rtpmap:97 iLBC/8000 + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + + + + + + + + + + + + + + + +Johnston & Sparks Informational [Page 15] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + + [Second-Offer] + + v=0 + o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=audio 48282 RTP/AVP 98 + c=IN IP4 mediaserver.biloxi.example.com + a=rtpmap:98 telephone-event/8000 + a=recvonly + + [Second-Answer] + + v=0 + o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=audio 49172 RTP/AVP 98 + c=IN IP4 host.atlanta.example.com + a=rtpmap:98 telephone-event/8000 + a=sendonly + +4.2. Audio, then Video Added + + An audio-only session is established in the initial exchange between + Alice and Bob using PCMU codec. Alice adds a video stream that is + accepted by Bob. + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + + + + + + + +Johnston & Sparks Informational [Page 16] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + + [Second-Offer] + + v=0 + o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + m=video 49172 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + [Second-Answer] + + v=0 + o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 0 + a=rtpmap:0 PCMU/8000 + m=video 49168 RTP/AVP 31 + a=rtpmap:31 H261/90000 + +4.3. Audio and Video, Then Video Deleted + + Alice and Bob establish an audio and video session. In a second + exchange, Bob deletes the video session, resulting in an audio-only + session. + + + + + + + + + + + +Johnston & Sparks Informational [Page 17] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=video 51372 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49174 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=video 49170 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + [Second-Offer] + + v=0 + o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49174 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=video 0 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + [Second-Answer] + + v=0 + o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + m=video 0 RTP/AVP 31 + a=rtpmap:31 H261/90000 + + + + +Johnston & Sparks Informational [Page 18] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + +5. Third Party Call Control (3pcc) + + This section shows examples common in Third Party Call Control (3pcc) + flows [5]. Call hold and resume flows are also common in 3pcc. + +5.1. No Media, Then Audio Added + + The first offer from Alice contains no media lines, so Bob accepts + with no media lines. In the second exchange, Alice adds an audio + stream that Bob accepts. + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + + [Second-Offer] + + v=0 + o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + [Second-Answer] + + v=0 + o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + + + + +Johnston & Sparks Informational [Page 19] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + +5.2. Hold and Unhold 2 + + The first offer from Alice contains the connection address 0.0.0.0 + and a random port number, which means that Bob can not send media to + Alice (the media stream is "black holed" or "bh"). Bob accepts with + normal SDP. In the second exchange, Alice changes the connection + address, Bob accepts, and a media session is established. + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 0.0.0.0 + t=0 0 + m=audio 23442 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + [Second-Offer] + + v=0 + o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + [Second-Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + + + +Johnston & Sparks Informational [Page 20] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + +5.3. Hold and Unhold 3 + + The first offer from Alice contains an audio stream, but the answer + from Bob contains the connection address 0.0.0.0 and a random port + number, which means that Alice can not send media to Bob (the media + stream is "black holed" or "bh"). In the second exchange, Bob + changes the connection address, Alice accepts, and a media session is + established. + + [Offer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + [Answer] + + v=0 + o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com + s= + c=IN IP4 0.0.0.0 + t=0 0 + m=audio 9322 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + [Second-Offer] + + v=0 + o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com + s= + c=IN IP4 host.biloxi.example.com + t=0 0 + m=audio 49172 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + [Second-Answer] + + v=0 + o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com + s= + c=IN IP4 host.atlanta.example.com + t=0 0 + m=audio 49170 RTP/AVP 97 + a=rtpmap:97 iLBC/8000 + + + +Johnston & Sparks Informational [Page 21] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + +6. Security Considerations + + SDP offer and answer messages can contain private information about + addresses and sessions to be established between parties. If this + information needs to be kept private, some security mechanism in the + protocol used to carry the offers and answers must be used. For SIP, + this means using TLS transport and/or S/MIME encryption of the SDP + message body. + + It is important that SDP offer and answer messages be properly + authenticated and authorized before they are used to establish a + media session. Examples of SIP mechanisms include SIP Digest, certs, + and cryptographically-verified SIP identity. + +7. Informative References + + [1] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + Session Description Protocol (SDP)", RFC 3264, June 2002. + + [2] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [4] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, + Telephony Tones and Telephony Signals", RFC 2833, May 2000. + + [5] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, + "Best Current Practices for Third Party Call Control (3pcc) in + the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, + April 2004. + + [6] Duric, A. and S. Andersen, "Real-time Transport Protocol (RTP) + Payload Format for internet Low Bit Rate Codec (iLBC) Speech", + RFC 3952, December 2004. + + + + + + + + + + + + + + +Johnston & Sparks Informational [Page 22] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + +Authors' Addresses + + Alan Johnston + Tello Corporation + 999 Baker Way, Suite 250 + San Mateo, CA 94404 + + EMail: ajohnston@tello.com + + + Robert J. Sparks + Estacado Systems + + EMail: rjsparks@estacado.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Johnston & Sparks Informational [Page 23] + +RFC 4317 SDP Offer/Answer Examples December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Johnston & Sparks Informational [Page 24] + |