draft-ietf-mmusic-sdp-new-06.txt   draft-ietf-mmusic-sdp-new-07.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-06.txt Van Jacobson/Packet Design draft-ietf-mmusic-sdp-new-07.txt Van Jacobson/Packet Design
Colin Perkins/ISI Colin Perkins/ISI
27 February 2002 26 March 2002
Expires: August 2002 Expires: September 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
skipping to change at page 14, line 11 skipping to change at page 14, line 11
o If the session is multicast, the connection address will be an IP o If the session is multicast, the connection address will be an IP
multicast group address. If the conference is not multicast, then multicast group address. If the conference is not multicast, then
the connection address contains the unicast IP address of the the connection address contains the unicast IP address of the
expected data source or data relay or data sink as determined by expected data source or data relay or data sink as determined by
additional attribute fields. It is not expected that unicast additional attribute fields. It is not expected that unicast
addresses will be given in a session description that is addresses will be given in a session description that is
communicated by a multicast announcement, though this is not communicated by a multicast announcement, though this is not
prohibited. prohibited.
o Conferences using an IP multicast connection address MUST also have o Conferences using an IPv4 multicast connection address MUST also
a time to live (TTL) value present in addition to the multicast have a time to live (TTL) value present in addition to the multicast
address. The TTL and the address together define the scope with address. The TTL and the address together define the scope with
which multicast packets sent in this conference will be sent. TTL which multicast packets sent in this conference will be sent. TTL
values MUST be in the range 0-255. values MUST be in the range 0-255.
The TTL for the session is appended to the address using a slash as The TTL for the session is appended to the address using a slash as
a separator. An example is: a separator. An example is:
c=IN IP6 FF00:03AD::7F2E:172A:1E24/127 c=IN IP4 224.2.36.42/127
IPv6 multicast does not use TTL scoping, and hence the TTL value
MUST NOT be present for IPv6 multicast. It is expected that IPv6
scoped addresses will be used to limit the scope of conferences.
Hierarchical or layered encoding schemes are data streams where the Hierarchical or layered encoding schemes are data streams where the
encoding from a single media source is split into a number of encoding from a single media source is split into a number of
layers. The receiver can choose the desired quality (and hence layers. The receiver can choose the desired quality (and hence
bandwidth) by only subscribing to a subset of these layers. Such bandwidth) by only subscribing to a subset of these layers. Such
layered encodings are normally transmitted in multiple multicast layered encodings are normally transmitted in multiple multicast
groups to allow multicast pruning. This technique keeps unwanted groups to allow multicast pruning. This technique keeps unwanted
traffic from sites only requiring certain levels of the hierarchy. traffic from sites only requiring certain levels of the hierarchy.
For applications requiring multiple multicast groups, we allow the For applications requiring multiple multicast groups, we allow the
following notation to be used for the connection address: following notation to be used for the connection address:
<base multicast address>/<ttl>/<number of addresses> <base multicast address>[/<ttl>]/<number of addresses>
If the number of addresses is not given it is assumed to be one. If the number of addresses is not given it is assumed to be one.
Multicast addresses so assigned are contiguously allocated above the Multicast addresses so assigned are contiguously allocated above the
base address, so that, for example: base address, so that, for example:
c=IN IP4 224.2.1.1/127/3 c=IN IP4 224.2.1.1/127/3
would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to
be used at a ttl of 127. This is semantically identical to be used at a ttl of 127. This is semantically identical to
including multiple ``c='' lines in a media description: including multiple ``c='' lines in a media description:
c=IN IP4 224.2.1.1/127 c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127 c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127 c=IN IP4 224.2.1.3/127
Similarly, an IPv6 example would be:
c=IN IP6 FF15::101/3
which is semantically equivalent to:
c=IN IP6 FF15::101
c=IN IP6 FF15::102
c=IN IP6 FF15::103
(remembering that the TTL field is not present in IPv6 multicast).
Multiple addresses or ``c='' lines can only be specified on a per- Multiple addresses or ``c='' lines can only be specified on a per-
media basis, and not for a session-level ``c='' field. media basis, and not for a session-level ``c='' field.
The slash notation described above MUST NOT be used for IP unicast The slash notation described above MUST NOT be used for IP unicast
addresses. addresses.
Bandwidth Bandwidth
b=<modifier>:<bandwidth-value> b=<modifier>:<bandwidth-value>
skipping to change at page 25, line 25 skipping to change at page 25, line 43
packet, expressed as time in milliseconds. The time shall be packet, expressed as time in milliseconds. The time shall be
calculated as the sum of the time the media present in the packet calculated as the sum of the time the media present in the packet
represents. The time SHOULD be a multiple of the frame size. This is represents. The time SHOULD be a multiple of the frame size. This is
probably only meaningful for audio data. It is a media attribute, probably only meaningful for audio data. It is a media attribute,
and is not dependent on charset. Note that this attribute was and is not dependent on charset. Note that this attribute was
introduced after RFC 2327, and non updated implementations will introduced after RFC 2327, and non updated implementations will
ignore this attribute. ignore this attribute.
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>] parameters>]
See the section on Media Announcements (the ``m='' field). This is a See the section on Media Announcements (the ``m='' field). This may
media attribute. be either a session or media attribute.
a=recvonly a=recvonly
This specifies that the tools should be started in receive-only mode This specifies that the tools should be started in receive-only mode
where applicable. It can be either a session or media attribute, and where applicable. It can be either a session or media attribute, and
is not dependent on charset. Note that recvonly applies to the media is not dependent on charset. Note that recvonly applies to the media
only, not to any associated control protocol (e.g. an RTP based only, not to any associated control protocol (e.g. an RTP based
system in recvonly mode SHOULD still send RTCP packets). system in recvonly mode SHOULD still send RTCP packets).
a=sendrecv a=sendrecv
This specifies that the tools should be started in send and receive This specifies that the tools should be started in send and receive
skipping to change at page 36, line 42 skipping to change at page 37, line 42
multicast-address = IP4-multicast / IP6-multicast multicast-address = IP4-multicast / IP6-multicast
IP4-multicast = m1 3*( "." decimal-uchar ) IP4-multicast = m1 3*( "." decimal-uchar )
"/" ttl [ "/" integer ] "/" ttl [ "/" integer ]
; IPv4 multicast addresses may be in the ; IPv4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255 ; range 224.0.0.0 to 239.255.255.255
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT )) ("23" DIGIT ))
IP6-multicast = hexpart IP6-multicast = hexpart [ "/" integer ]
; IPv6 address starting with FF ; IPv6 address starting with FF
ttl = (POS-DIGIT *2DIGIT) / "0" ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".") FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified ; fully qualified domain name as specified
; in RFC1035 ; in RFC1035
IP4-address = b1 3*("." decimal-uchar) / "0.0.0.0" IP4-address = b1 3*("." decimal-uchar) / "0.0.0.0"
 End of changes. 

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