--- 1/draft-ietf-mmusic-sdp-offer-answer-01.txt 2006-02-05 00:28:59.000000000 +0100 +++ 2/draft-ietf-mmusic-sdp-offer-answer-02.txt 2006-02-05 00:28:59.000000000 +0100 @@ -1,18 +1,18 @@ Internet Engineering Task Force MMUSIC WG Internet Draft J.Rosenberg dynamicsoft H.Schulzrinne Columbia U. -draft-ietf-mmusic-sdp-offer-answer-01.txt -February 21, 2002 +draft-ietf-mmusic-sdp-offer-answer-02.txt +February 27, 2002 Expires: August 2002 An Offer/Answer Model with SDP STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering @@ -38,50 +38,50 @@ them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). Table of Contents - 1 Introduction ........................................ 3 - 2 Terminology ......................................... 4 - 3 Definitions ......................................... 4 - 4 Protocol Operation .................................. 4 - 5 Generating the initial offer ........................ 5 - 5.1 Unicast Streams ..................................... 6 - 5.2 Multicast Streams ................................... 9 - 6 Generating the answer ............................... 9 - 6.1 Unicast Streams ..................................... 10 - 6.2 Multicast Streams ................................... 12 - 7 Offerer Processing of the Answer .................... 13 - 8 Modifying the session ............................... 13 - 8.1 Adding a Media Stream ............................... 14 - 8.2 Removing a Media Stream ............................. 14 - 8.3 Modifying a Media Stream ............................ 15 - 8.3.1 Modifying Address, Port or Transport ................ 15 - 8.3.2 Changing the Set of Media Formats ................... 16 - 8.3.3 Changing Media Types ................................ 17 - 8.3.4 Changing Attributes ................................. 17 - 8.4 Putting a Unicast Media Stream on Hold .............. 17 - 9 Indicating Capabilities ............................. 18 - 10 Example Offer/Answer Exchanges ...................... 19 - 10.1 Basic Exchange ...................................... 19 - 10.2 One of N Codec Selection ............................ 21 - 11 Security Considerations ............................. 23 + 1 Introduction ........................................ 2 + 2 Terminology ......................................... 3 + 3 Definitions ......................................... 3 + 4 Protocol Operation .................................. 3 + 5 Generating the initial offer ........................ 4 + 5.1 Unicast Streams ..................................... 5 + 5.2 Multicast Streams ................................... 8 + 6 Generating the answer ............................... 8 + 6.1 Unicast Streams ..................................... 9 + 6.2 Multicast Streams ................................... 11 + 7 Offerer Processing of the Answer .................... 12 + 8 Modifying the session ............................... 12 + 8.1 Adding a Media Stream ............................... 13 + 8.2 Removing a Media Stream ............................. 13 + 8.3 Modifying a Media Stream ............................ 14 + 8.3.1 Modifying Address, Port or Transport ................ 14 + 8.3.2 Changing the Set of Media Formats ................... 15 + 8.3.3 Changing Media Types ................................ 16 + 8.3.4 Changing Attributes ................................. 16 + 8.4 Putting a Unicast Media Stream on Hold .............. 16 + 9 Indicating Capabilities ............................. 17 + 10 Example Offer/Answer Exchanges ...................... 18 + 10.1 Basic Exchange ...................................... 18 + 10.2 One of N Codec Selection ............................ 20 + 11 Security Considerations ............................. 22 12 IANA Considerations ................................. 23 - 13 Acknowledgements .................................... 24 - 14 Author's Addresses .................................. 24 - 15 Normative References ................................ 24 - 16 Non-Normative References ............................ 25 + 13 Acknowledgements .................................... 23 + 14 Author's Addresses .................................. 23 + 15 Normative References ................................ 23 + 16 Informative References .............................. 24 1 Introduction The Session Description Protocol (SDP) [1] was originally conceived as a way to describe multicast sessions carried on the Mbone. The Session Announcement Protocol (SAP) [6] was devised as a multicast mechanism to carry SDP messages. Although the SDP specification allows for unicast operation, it is not complete. Unlike multicast, where there is a global view of the session that is used by all participants, unicast sessions involve two participants, and a @@ -189,34 +189,36 @@ The term glare was originally used in circuit switched telecommunications networks to describe the condition where two switches both attempt to seize the same available circuit on the same trunk at the same time. Here, it means both agents have attempted to send an updated offer at the same time. The higher layer protocol needs to provide a means for resolving such conditions. The higher layer protocol will need to provide a means - for ordering of messages in each direction. + for ordering of messages in each direction. SIP meets these + requirements [7]. 5 Generating the initial offer The offer (and answer) MUST be a valid SDP, as defined by RFC 2327 [1], with one exception. RFC 2327 mandates that either an e or a p line is present in the SDP. This specification relaxes that constraint; an SDP formulated for an offer/answer application MAY omit both the e and p lines. The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed - integer. Although the SDP specification allows for multiple session - descriptions to be concatenated together into a large SDP message, an - SDP message used in the offer/answer model MUST contain exactly one - session description. + integer. The initial value of the version MUST be less than (2**62)- + 1, to avoid rollovers. Although the SDP specification allows for + multiple session descriptions to be concatenated together into a + large SDP message, an SDP message used in the offer/answer model MUST + contain exactly one session description. The SDP "s=" line conveys the subject of the media stream, which is reasonably defined for multicast, but ill defined for unicast. For unicast streams, it is RECOMMENDED that it consist of a single space character (0x20). Unfortunately, SDP does not allow the "s=" line to be empty. The SDP "t=" line conveys the time of the session. Generally, streams @@ -811,23 +813,25 @@ and it will also locally mute, so that no media is sent to the far end, and no media is played out. RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and - ports at the time of the offer. An agent MUST be capable of receiving - SDP with a connection address of 0.0.0.0, in which case it means that - neither RTP nor RTCP should be sent to the peer. + ports at the time of the offer. Of course, when used, the port number + MUST NOT be zero, which would specify that the stream has been + disabled. An agent MUST be capable of receiving SDP with a connection + address of 0.0.0.0, in which case it means that neither RTP nor RTCP + should be sent to the peer. 9 Indicating Capabilities Before an agent sends an offer, it is helpful to know if the media formats in that offer would be acceptable to the answerer. Certain protocols, like SIP, provide a means to query for such capabilities. SDP can be used in responses to such queries to indicate capabilities. This section describes how such an SDP message is formatted. Since SDP has no way to indicate that the message is for the purpose of capability indication, this is determined from the @@ -966,22 +969,22 @@ o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 62986 RTP/AVP 0 4 18 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=inactive - Bob can dynamic switching between PCMU and G.723. So, he sends the - following answer: + Bob can support dynamic switching between PCMU and G.723. So, he + sends the following answer: v=0 o=bob 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 54344 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=inactive @@ -1021,35 +1023,37 @@ 11 Security Considerations There are numerous attacks possible if an attacker can modify offers or answers in transit. Generally, these include diversion of media streams (enabling eavesdropping), disabling of calls, and injection of unwanted media streams. If a passive listener can construct fake offers, and inject those into an exchange, similar attacks are possible. Even if an attacker can simply observe offers and answers, they can inject media streams into an existing conversation. - Offer/answer relies an transport within an application signaling + Offer/answer relies on transport within an application signaling protocol, such as SIP. It also relies on that protocol for security capabilities. Because of the attacks described above, that protocol MUST provide a means for end-to-end authentication and integrity protection of offers and answers. It SHOULD offer encryption of bodies to prevent eavesdropping. However, media injection attacks can alternatively be resolved through authenticated media exchange, and therefore the encryption requirement is a SHOULD instead of a MUST. Replay attacks are also problematic. An attacker can replay an old offer, perhaps one that had put media on hold, and thus disable media streams in a conversation. Therefore, the application protocol MUST provide a secure way to sequence offers and answers, and to detect and reject old offers or answers. + SIP [7] meets all of these requirements. + 12 IANA Considerations There are no IANA considerations with this specification. 13 Acknowledgements The authors would like to thank Allison Mankin, Rohan Mahy, Joerg Ott, and Flemming Andreasen for their detailed comments. 14 Author's Addresses @@ -1084,29 +1088,29 @@ Comments 3108, Internet Engineering Task Force, May 2001. [4] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," Request for Comments 1889, Internet Engineering Task Force, Jan. 1996. [5] H. Schulzrinne, "RTP profile for audio and video conferences with minimal control," Request for Comments 1890, Internet Engineering Task Force, Jan. 1996. -16 Non-Normative References +16 Informative References [6] M. Handley, C. Perkins, and E. Whelan, "Session announcement protocol," Request for Comments 2974, Internet Engineering Task Force, Oct. 2000. [7] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation - protocol," Internet Draft, Internet Engineering Task Force, Oct. - 2001. Work in progress. + protocol," Internet Draft, Internet Engineering Task Force, Feb. + 2002. Work in progress. [8] H. Schulzrinne, A. Rao, and R. Lanphier, "Real time streaming protocol (RTSP)," Request for Comments 2326, Internet Engineering Task Force, Apr. 1998. [9] H. Schulzrinne and S. Petrack, "RTP payload for DTMF digits, telephony tones and telephony signals," Request for Comments 2833, Internet Engineering Task Force, May 2000. [10] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: