draft-ietf-mmusic-sdp-new-10.txt   draft-ietf-mmusic-sdp-new-11.txt 
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
INTERNET-DRAFT Mark Handley/ACIRI INTERNET-DRAFT Mark Handley/ACIRI
draft-ietf-mmusic-sdp-new-10.txt Van Jacobson/Packet Design draft-ietf-mmusic-sdp-new-11.txt Van Jacobson/Packet Design
Colin Perkins/ISI Colin Perkins/ISI
Expires: November 2002 3 November 2002
SDP: Session Description Protocol SDP: Session Description Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 16, line 10 skipping to change at page 16, line 10
Note that CT gives a total bandwidth figure for all the media at all Note that CT gives a total bandwidth figure for all the media at all
sites. AS gives a bandwidth figure for a single media at a single sites. AS gives a bandwidth figure for a single media at a single
site, although there may be many sites sending simultaneously. site, although there may be many sites sending simultaneously.
o Extension Mechanism: Tool writers can define experimental bandwidth o Extension Mechanism: Tool writers can define experimental bandwidth
modifiers by prefixing their modifier with ``X-''. For example: modifiers by prefixing their modifier with ``X-''. For example:
b=X-YZ:128 b=X-YZ:128
SDP parsers MUST ignore bandwidth fields with unknown modifiers. Use of the ``X-'' prefix is NOT RECOMMENDED: instead new modifiers
SHOULD be registered with IANA in the standard namespace. SDP
parsers MUST ignore bandwidth fields with unknown modifiers.
Modifiers MUST be alpha-numeric and, although no length limit is Modifiers MUST be alpha-numeric and, although no length limit is
given, they are recommended to be short. given, they are recommended to be short.
Times, Repeat Times and Time Zones Times, Repeat Times and Time Zones
t=<start time> <stop time> t=<start time> <stop time>
o ``t='' fields specify the start and stop times for a session. o ``t='' fields specify the start and stop times for a session.
Multiple ``t='' fields MAY be used if a session is active at Multiple ``t='' fields MAY be used if a session is active at
multiple irregularly spaced times; each additional ``t='' field multiple irregularly spaced times; each additional ``t='' field
skipping to change at page 20, line 32 skipping to change at page 20, line 32
Attribute values are octet strings, and MAY use any octet value except Attribute values are octet strings, and MAY use any octet value except
0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are
to be interpreted as in ISO-10646 character set with UTF-8 encoding. to be interpreted as in ISO-10646 character set with UTF-8 encoding.
Unlike other text fields, attribute values are NOT normally affected by Unlike other text fields, attribute values are NOT normally affected by
the `charset' attribute as this would make comparisons against known the `charset' attribute as this would make comparisons against known
values problematic. However, when an attribute is defined, it can be values problematic. However, when an attribute is defined, it can be
defined to be charset-dependent, in which case it's value should be defined to be charset-dependent, in which case it's value should be
interpreted in the session charset rather than in ISO-10646. interpreted in the session charset rather than in ISO-10646.
Attributes that will be commonly used can be registered with IANA (see Attributes SHOULD be registered with IANA (see Appendix B). Names of
Appendix B). Unregistered attributes should begin with "X-" to prevent unregistered attributes SHOULD begin with "X-" to prevent inadvertent
inadvertent collision with registered attributes. In either case, if an collision with registered attributes, however the use of unregistered
attribute is received that is not understood, it should simply be attributes is NOT RECOMMENDED. If an attribute is received that is not
ignored by the receiver. understood, it MUST be ignored by the receiver.
Media Announcements Media Announcements
m=<media> <port> <transport> <fmt list> m=<media> <port> <transport> <fmt list>
A session description may contain a number of media descriptions. Each A session description may contain a number of media descriptions. Each
media description starts with an ``m='' field, and is terminated by media description starts with an ``m='' field, and is terminated by
either the next ``m='' field or by the end of the session description. either the next ``m='' field or by the end of the session description.
A media field also has several sub-fields: A media field also has several sub-fields:
skipping to change at page 23, line 23 skipping to change at page 23, line 23
payload types. payload types.
An example of a static payload type is u-law PCM coded single An example of a static payload type is u-law PCM coded single
channel audio sampled at 8kHz. This is completely defined in the channel audio sampled at 8kHz. This is completely defined in the
RTP Audio/Video profile as payload type 0, so the media field for RTP Audio/Video profile as payload type 0, so the media field for
such a stream sent to UDP port 49232 is: such a stream sent to UDP port 49232 is:
m=audio 49232 RTP/AVP 0 m=audio 49232 RTP/AVP 0
An example of a dynamic payload type is 16 bit linear encoded stereo An example of a dynamic payload type is 16 bit linear encoded stereo
audio sampled at 16KHz. If we wish to use dynamic RTP/AVP payload audio sampled at 16 kHz. If we wish to use dynamic RTP/AVP payload
type 98 for such a stream, additional information is required to type 98 for such a stream, additional information is required to
decode it: decode it:
m=video 49232 RTP/AVP 98 m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2 a=rtpmap:98 L16/16000/2
The general form of an rtpmap attribute is: The general form of an rtpmap attribute is:
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>] a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]
For audio streams, <encoding parameters> may specify the number of For audio streams, <encoding parameters> may specify the number of
audio channels. This parameter may be omitted if the number of audio channels. This parameter may be omitted if the number of
channels is one provided no additional parameters are needed. channels is one provided no additional parameters are needed.
For video streams, no encoding parameters are currently specified. For video streams, no encoding parameters are currently specified.
skipping to change at page 24, line 15 skipping to change at page 24, line 15
m=audio 49230 RTP/AVP 96 97 98 m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000 a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000 a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2 a=rtpmap:98 L16/11025/2
RTP profiles that specify the use of dynamic payload types MUST RTP profiles that specify the use of dynamic payload types MUST
define the set of valid encoding names and/or a means to register define the set of valid encoding names and/or a means to register
encoding names if that profile is to be used with SDP. encoding names if that profile is to be used with SDP.
Experimental encoding formats can also be specified using rtpmap. Experimental encoding formats can also be specified using rtpmap.
RTP formats that are not registered as standard format names must be RTP formats that are not registered as standard format names MUST be
preceded by ``X-''. Thus a new experimental redundant audio stream preceded by ``X-''. Use of the ``X-'' prefix is deprecated, and all
called GSMLPC using dynamic payload type 99 could be specified as: new formats SHOULD be registered with IANA. Thus a new experimental
redundant audio stream called GSMLPC using dynamic payload type 99
could be specified as:
m=audio 49232 RTP/AVP 99 m=audio 49232 RTP/AVP 99
a=rtpmap:99 X-GSMLPC/8000 a=rtpmap:99 X-GSMLPC/8000
Such an experimental encoding requires that any site wishing to Such an experimental encoding requires that any site wishing to
receive the media stream has relevant configured state in its receive the media stream has relevant configured state in its
session directory to know which tools are appropriate. session directory to know which tools are appropriate.
Note that RTP audio formats typically do not include information Note that RTP audio formats typically do not include information
about the number of samples per packet. If a non-default (as about the number of samples per packet. If a non-default (as
skipping to change at page 34, line 29 skipping to change at page 34, line 29
zone-adjustments = "z=" time SP ["-"] typed-time zone-adjustments = "z=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time) *(SP time SP ["-"] typed-time)
key-field = ["k=" key-type CRLF] key-field = ["k=" key-type CRLF]
attribute-fields = *("a=" attribute CRLF) attribute-fields = *("a=" attribute CRLF)
media-descriptions = *( media-field media-descriptions = *( media-field
information-field information-field
*connection-field connection-field
bandwidth-fields bandwidth-fields
key-field key-field
attribute-fields ) attribute-fields )
media-field = "m=" media SP port ["/" integer] media-field = "m=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF SP proto 1*(SP fmt) CRLF
; sub-rules of 'o=' ; sub-rules of 'o='
username = non-ws-string username = non-ws-string
;pretty wide definition, but doesn't include space ;pretty wide definition, but doesn't include space
skipping to change at page 36, line 18 skipping to change at page 36, line 18
start-time = time / "0" start-time = time / "0"
stop-time = time / "0" stop-time = time / "0"
time = POS-DIGIT 9*DIGIT time = POS-DIGIT 9*DIGIT
; 10-digit NTP time represents times between ; 10-digit NTP time represents times between
; 1931 and 5068 AD. 9* allows times after that ; 1931 and 5068 AD. 9* allows times after that
; as well. ; as well.
; sub-rules of 'r=' and 'z=' ; sub-rules of 'r=' and 'z='
repeat-interval = typed-time repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
typed-time = POS-DIGIT *DIGIT [fixed-len-time-unit] typed-time = 1*DIGIT [fixed-len-time-unit]
fixed-len-time-unit = "d" / "h" / "m" / "s" fixed-len-time-unit = "d" / "h" / "m" / "s"
; sub-rules of 'k=' ; sub-rules of 'k='
key-type = "prompt" / key-type = "prompt" /
"clear:" text / "clear:" text /
"base64:" base64 / "base64:" base64 /
"uri:" uri / "uri:" uri /
key-method [ ":" text ] key-method [ ":" text ]
skipping to change at page 39, line 7 skipping to change at page 39, line 7
;string of visible US-ASCII, or high-bit, characters ;string of visible US-ASCII, or high-bit, characters
token-char = %x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7E token-char = %x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7E
; definition from RFC 2045 - ; definition from RFC 2045 -
; "any (US-ASCII) CHAR except SPACE, CTLs, ; "any (US-ASCII) CHAR except SPACE, CTLs,
; or tspecials". ; or tspecials".
; the tspecials are ()<>@,;: ; the tspecials are ()<>@,;:
token = 1*(token-char) token = 1*(token-char)
email-safe = 1*(%x01-09/%x0B-0C/%x0E-27/ email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
%x2A-3B/%x3D/%x3E-FF)
;any byte except NUL, CR, LF, or the quoting ;any byte except NUL, CR, LF, or the quoting
;characters ()<> ;characters ()<>
integer = POS-DIGIT *DIGIT integer = POS-DIGIT *DIGIT
; generic sub-rules: primitives ; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9 POS-DIGIT = %x31-39 ; 1 - 9
skipping to change at page 45, line 30 skipping to change at page 45, line 30
2465 Latham Street 2465 Latham Street
Mountain View, CA 94040 Mountain View, CA 94040
United States United States
Email: van@packetdesign.com Email: van@packetdesign.com
Colin Perkins Colin Perkins
USC Information Sciences Institute USC Information Sciences Institute
3811 N. Fairfax Drive, Suite 200 3811 N. Fairfax Drive, Suite 200
Arlington, VA 22203 Arlington, VA 22203
United States United States
Email: csp@isi.edu Email: csp@csperkins.org
Acknowledgments Acknowledgments
Many people in the IETF MMUSIC working group have made comments and Many people in the IETF MMUSIC working group have made comments and
suggestions contributing to this document. In particular, we would like suggestions contributing to this document. In particular, we would like
to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross
Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna and Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna and
Jonathan Lennox. Jonathan Lennox.
References References
 End of changes. 12 change blocks. 
20 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/