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

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/