One document matched: draft-petithuguenin-mmusic-ice-attributes-level-04.xml
<?xml version="1.0" ?>
<?rfc compact="yes" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" docName="draft-petithuguenin-mmusic-ice-attributes-level-04" ipr="noModificationTrust200902" updates="5245">
<front>
<title abbrev="Media level ICE attributes">Media level ice-options SDP attribute</title>
<author fullname="Marc Petit-Huguenin" initials="M.P.H" surname="Petit-Huguenin">
<organization>Impedance Mismatch</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="8" month="October" year="2012"/>
<area>RAI</area>
<workgroup>MMUSIC</workgroup>
<abstract>
<t>This document normatively updates RFC 5245 by redefining the ice-options SDP attribute as a session-level and media-level attribute.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<xref target="RFC5245">ICE</xref>
defines the ice-options SDP attribute as session-level only attribute, but when ICE is used with disaggregated media (see section 3 of
<xref target="I-D.loreto-splices-disaggregated-media"/>
), there is a possibility that different media use different ICE implementations and/or different networks, and so these different media will require different values for this attribute.
</t>
<t>
As an example, the ice-options attribute value "rtp+ecn" (defined in
<xref target="RFC6679"/>
) signals ECN capability.
Two aggregated media using two different RTP implementations may want to use different values for this attribute.
</t>
<t>Note that there is a similar problem for the ice-lite attribute but unfortunately it does not seem possible to design a way to use the ice-lite attribute at the media level that is compatible with legacy implementations that recognize only the session-level attribute.</t>
</section>
<section title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"/>
.
</t>
</section>
<section anchor="ice-options" title="The ice-options Attribute">
<t>The ice-options attribute is redefined by this document as a session-level and media-level attribute.</t>
<t>All future new ICE options MUST also define how media-level ICE options using this new value are aggregated to eventually generate the value of the session-level ICE option, so legacy implementations that only recognize session-level ICE options can interoperate with implementations that recognize ICE options at both levels.</t>
<t>Before applying this specific aggregation rule, the session-level ice-options attribute MUST be copied as media-level attribute in each media.</t>
</section>
<section anchor="ice-lite" title="The ice-lite Attribute">
<t>The ice-lite attribute is not redefined by this specification.</t>
</section>
<section anchor="ice-mismatch" title="The ice-mismatch Attribute">
<t>
<xref target="RFC5245"/>
section 15.3 defines this attribute as been media level, which seems correct, but section 21.1.4 erroneously registered this attribute in IANA as session level.
An
<eref target="http://www.rfc-editor.org/errata_search.php?eid=3149">errata</eref>
has been filled and the IANA registry has been accordingly fixed.
</t>
</section>
<section title="Specific Aggregation Rule for the rtp+ecn ICE Option">
<t>
If all aggregated media using ICE contain a media-level "rtp+ecn" ICE option, as defined by
<xref target="RFC6064"/>
, then an "rtp+ecn" ICE option MUST be inserted at the session-level.
</t>
</section>
<section title="Security Considerations">
<t>
This document does not add any security considerations beyond what is discussed in
<xref target="RFC5245"/>
.
</t>
</section>
<section title="IANA Considerations">
<t>No IANA considerations.</t>
</section>
<section title="Acknowledgements">
<t>
This document was written with the xml2rfc tool described in
<xref target="RFC2629"/>
.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.</t>
</list>
</t>
<t>Note that the force of these words is modified by the requirement
level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" type="TXT"/>
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
<reference anchor="RFC5245">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization/>
</author>
<date month="April" year="2010"/>
</front>
<seriesInfo name="RFC" value="5245"/>
<format octets="285120" target="ftp://ftp.isi.edu/in-notes/rfc5245.txt" type="TXT"/>
</reference>
<reference anchor="RFC6679">
<front>
<title>Explicit Congestion Notification (ECN) for RTP over UDP</title>
<author fullname="M. Westerlund" initials="M." surname="Westerlund">
<organization/>
</author>
<author fullname="I. Johansson" initials="I." surname="Johansson">
<organization/>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization/>
</author>
<author fullname="P. O'Hanlon" initials="P." surname="O'Hanlon">
<organization/>
</author>
<author fullname="K. Carlberg" initials="K." surname="Carlberg">
<organization/>
</author>
<date month="August" year="2012"/>
</front>
<seriesInfo name="RFC" value="6679"/>
<format octets="148560" target="ftp://ftp.isi.edu/in-notes/rfc6679.txt" type="TXT"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country>
</postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>
<date month="June" year="1999"/>
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2629"/>
<format octets="48677" target="ftp://ftp.isi.edu/in-notes/rfc2629.txt" type="TXT"/>
<format octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html" type="HTML"/>
<format octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml" type="XML"/>
</reference>
<reference anchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization/>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization/>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization/>
</author>
<date month="July" year="2006"/>
</front>
<seriesInfo name="RFC" value="4566"/>
<format octets="108820" target="ftp://ftp.isi.edu/in-notes/rfc4566.txt" type="TXT"/>
</reference>
<reference anchor="RFC5159">
<front>
<title>Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection</title>
<author fullname="L. Dondeti" initials="L." surname="Dondeti">
<organization/>
</author>
<author fullname="A. Jerichow" initials="A." surname="Jerichow">
<organization/>
</author>
<date month="March" year="2008"/>
</front>
<seriesInfo name="RFC" value="5159"/>
<format octets="13921" target="ftp://ftp.isi.edu/in-notes/rfc5159.txt" type="TXT"/>
</reference>
<reference anchor="RFC5888">
<front>
<title>The Session Description Protocol (SDP) Grouping Framework</title>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization/>
</author>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization/>
</author>
<date month="June" year="2010"/>
</front>
<seriesInfo name="RFC" value="5888"/>
<format octets="43924" target="ftp://ftp.isi.edu/in-notes/rfc5888.txt" type="TXT"/>
</reference>
<reference anchor="RFC6064">
<front>
<title>SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service</title>
<author fullname="M. Westerlund" initials="M." surname="Westerlund">
<organization/>
</author>
<author fullname="P. Frojdh" initials="P." surname="Frojdh">
<organization/>
</author>
<date month="January" year="2011"/>
</front>
<seriesInfo name="RFC" value="6064"/>
<format octets="44810" target="ftp://ftp.isi.edu/in-notes/rfc6064.txt" type="TXT"/>
</reference>
<reference anchor="I-D.loreto-splices-disaggregated-media">
<front>
<title>Disaggregated Media in the Session Initiation Protocol (SIP)</title>
<author fullname="Gonzalo Camarillo" initials="G" surname="Camarillo">
<organization/>
</author>
<author fullname="Salvatore Loreto" initials="S" surname="Loreto">
<organization/>
</author>
<author fullname="Rifaat Shekh-Yusef" initials="R" surname="Shekh-Yusef">
<organization/>
</author>
<date day="25" month="June" year="2011"/>
<abstract>
<t>Disaggregated media refers to the ability for a user to create a multimedia session combining different media streams, coming from different devices under his or her control, so that they are treated by the far end of the session as a single media session. This document lists several use cases that involve disaggregated media in SIP. Additionally, this document analyzes what types of disaggregated media can be implemented using existing protocol mechanisms, and the pros and cons of using each of those mechanisms. Finally, this document describes scenarios that are not covered by current mechanisms and proposes new IETF work to cover them.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-loreto-splices-disaggregated-media-02"/>
<format target="http://www.ietf.org/internet-drafts/draft-loreto-splices-disaggregated-media-02.txt" type="TXT"/>
</reference>
</references>
<section title="Examples">
<section title="Aggregating media all supporting ICE">
<t>In this example, we have two SDP to aggregate.
The first SDP contains an ice-options attribute at the media level:</t>
<figure>
<artwork><![CDATA[v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-options:rtp+ecn
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
m=text 45666 RTP/AVP 98
b=RS:0
b=RR:0
a=rtpmap:98 t140/1000
a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr
10.0.1.1 rport 9000]]></artwork>
</figure>
<t>The second SDP also have an ice-options attribute at the media level:</t>
<figure>
<artwork><![CDATA[v=0
o=jdoe 1 1 IN IP4 10.0.1.2
s=
c=IN IP4 192.0.2.4
t=0 0
a=ice-options:rtp+ecn
a=ice-pwd:f7sD7f7dF87s87d7da5564
a=ice-ufrag:776G
m=video 10000 RTP/AVP
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.2 10000 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.4 45000 typ srflx raddr
10.0.1.1 rport 10000]]></artwork>
</figure>
<t>The first step is to copy the session-level ice-options attribute as media-level attribute.
The first SDP is modified like this:</t>
<figure>
<artwork><![CDATA[v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-options:rtp+ecn
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=ice-options:rtp+ecn
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
m=text 45666 RTP/AVP 98
b=RS:0
b=RR:0
a=rtpmap:98 t140/1000
a=ice-options:rtp+ecn
a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr
10.0.1.1 rport 9000]]></artwork>
</figure>
<t>The second SDP is modified like this:</t>
<figure>
<artwork><![CDATA[v=0
o=jdoe 1 1 IN IP4 10.0.1.2
s=
c=IN IP4 192.0.2.4
t=0 0
a=ice-options:rtp+ecn
a=ice-pwd:f7sD7f7dF87s87d7da5564
a=ice-ufrag:776G
m=video 10000 RTP/AVP
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=ice-options:rtp+ecn
a=candidate:1 1 UDP 2130706431 10.0.1.2 10000 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.4 45000 typ srflx raddr
10.0.1.1 rport 10000]]></artwork>
</figure>
<t>
After aggregation, all the individual media keep their media-level ice-options attribute, and a session-level ice-options attribute is added as per the rule in
<xref target="ice-options"/>
:
</t>
<figure>
<artwork><![CDATA[v=0
o=- 1309452627 1309452627 IN IP4 10.0.1.1
s=
t=0 0
a=ice-options:rtp+ecn
m=audio 45664 RTP/AVP 0
c=IN IP4 192.168.2.3
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=ice-options:rtp+ecn
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
m=text 45666 RTP/AVP 98
c=IN IP4 192.168.2.3
b=RS:0
b=RR:0
a=rtpmap:98 t140/1000
a=ice-options:rtp+ecn
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr
10.0.1.1 rport 9000
m=video 10000 RTP/AVP
c=IN IP4 192.168.2.4
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=ice-options:rtp+ecn
a=candidate:1 1 UDP 2130706431 10.0.1.2 10000 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.4 45000 typ srflx raddr
10.0.1.1 rport 10000]]></artwork>
</figure>
</section>
<section title="Aggregating media partially supporting ICE">
<t>In this example, we have two SDP to aggregate, but the second one does not use ICE.
The first SDP contains an ice-options attribute at the media level:</t>
<figure>
<artwork><![CDATA[v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-options:rtp+ecn
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
m=text 45666 RTP/AVP 98
b=RS:0
b=RR:0
a=rtpmap:98 t140/1000
a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr
10.0.1.1 rport 9000]]></artwork>
</figure>
<t>The second SDP does not contain any ice-options attribute:</t>
<figure>
<artwork><![CDATA[v=0
o=jdoe 1 1 IN IP4 10.0.1.2
s=
c=IN IP4 192.0.2.4
t=0 0
m=video 10000 RTP/AVP
a=rtpmap:0 PCMU/8000]]></artwork>
</figure>
<t>The first step is to copy the session-level ice-options attribute as media-level attribute.
Only the first SDP is modified in this example:</t>
<figure>
<artwork><![CDATA[v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 192.0.2.3
t=0 0
a=ice-options:rtp+ecn
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 45664 RTP/AVP 0
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=ice-options:rtp+ecn
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
m=text 45666 RTP/AVP 98
b=RS:0
b=RR:0
a=rtpmap:98 t140/1000
a=ice-options:rtp+ecn
a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr
10.0.1.1 rport 9000]]></artwork>
</figure>
<t>
After aggregation, all the individual media keep their media-level ice-options attribute, and a session-level ice-options attribute is added as per the rule in
<xref target="ice-options"/>
:
</t>
<figure>
<artwork><![CDATA[v=0
o=- 1309452627 1309452627 IN IP4 10.0.1.1
s=
t=0 0
a=ice-options:rtp+ecn
m=audio 45664 RTP/AVP 0
c=IN IP4 192.168.2.3
b=RS:0
b=RR:0
a=rtpmap:0 PCMU/8000
a=ice-options:rtp+ecn
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.1 rport 8998
m=text 45666 RTP/AVP 98
c=IN IP4 192.168.2.3
b=RS:0
b=RR:0
a=rtpmap:98 t140/1000
a=ice-options:rtp+ecn
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=candidate:1 1 UDP 2130706431 10.0.1.1 9000 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45666 typ srflx raddr
10.0.1.1 rport 9000
m=video 10000 RTP/AVP
c=IN IP4 192.168.2.4
a=rtpmap:0 PCMU/8000]]></artwork>
</figure>
</section>
</section>
<section title="Analysis of similar issues in other attributes">
<t>In the MMUSIC WG session in Quebec City, it was suggested that the problem was perhaps larger than just ICE attributes.
This section is the result of a systematic look at all the session level only SDP attributes registered by IANA at the date of this document.
The conclusion is that only the ICE attributes are of concern but that steps should be taken to ensure that these problems cannot happen for future new attributes.</t>
<texttable>
<ttcol>Attribute</ttcol>
<ttcol>Reference</ttcol>
<ttcol>Comments</ttcol>
<c>cat</c>
<c>
<xref target="RFC4566"/>
</c>
<c>OK</c>
<c>keywds</c>
<c>
<xref target="RFC4566"/>
</c>
<c>OK</c>
<c>type</c>
<c>
<xref target="RFC4566"/>
</c>
<c>OK</c>
<c>type:broadcast</c>
<c>
<xref target="RFC4566"/>
</c>
<c>
<xref target="type_broadcast"/>
</c>
<c>type:H332</c>
<c>[ITU Recommendation H.332]</c>
<c>OK</c>
<c>type:meeting</c>
<c>
<xref target="RFC4566"/>
</c>
<c>OK</c>
<c>type:moderated</c>
<c>
<xref target="RFC4566"/>
</c>
<c>OK</c>
<c>type:test</c>
<c>
<xref target="RFC4566"/>
</c>
<c>OK</c>
<c>charset</c>
<c>
<xref target="RFC4566"/>
</c>
<c>
<xref target="charset"/>
</c>
<c>charset:iso8895-1</c>
<c>
<xref target="RFC4566"/>
</c>
<c>
<xref target="charset"/>
</c>
<c>tool</c>
<c>
<xref target="RFC4566"/>
</c>
<c>
<xref target="tool"/>
</c>
<c>ipbcp</c>
<c>[ITU-T Q.1970]</c>
<c>
<xref target="others"/>
</c>
<c>group</c>
<c>
<xref target="RFC5888"/>
</c>
<c>OK</c>
<c>ice-lite</c>
<c>
<xref target="RFC5245"/>
</c>
<c>
<xref target="ice-lite"/>
</c>
<c>ice-mismatch</c>
<c>
<xref target="RFC5245"/>
</c>
<c>
<xref target="ice-mismatch"/>
</c>
<c>ice-options</c>
<c>
<xref target="RFC5245"/>
</c>
<c>
<xref target="ice-options"/>
</c>
<c>bcastversion</c>
<c>
<xref target="RFC5159"/>
</c>
<c>
<xref target="others"/>
</c>
<c>3GPP-Integrity-Key</c>
<c>
<xref target="RFC6064"/>
</c>
<c>
<xref target="others"/>
</c>
<c>3GPP-SDP-Auth</c>
<c>
<xref target="RFC6064"/>
</c>
<c>
<xref target="others"/>
</c>
<c>alt-group</c>
<c>
<xref target="RFC6064"/>
</c>
<c>
<xref target="others"/>
</c>
<c>PSCid</c>
<c>[TS 183 063]</c>
<c>
<xref target="others"/>
</c>
<c>bc_service</c>
<c>[TS 183 063]</c>
<c>
<xref target="others"/>
</c>
<c>bc_program</c>
<c>[TS 183 063]</c>
<c>
<xref target="others"/>
</c>
<c>bc_service_package</c>
<c>[TS 183 063]</c>
<c>
<xref target="others"/>
</c>
</texttable>
<section anchor="type_broadcast" title="The type:broadcast Attribute">
<t>The "type:broadcast" does not have any issue by itself, but it should be noted that it implies a default attribute of recvonly, so the disaggregation process must take this in account.</t>
</section>
<section anchor="charset" title="The charset Attribute">
<t>Because the main reason to use a different charset for a session description is to generate a more compact representation, it is probably OK that this attribute exists only at the session level.
But the aggregation/disaggregation rules must explicitly convert the individual media descriptions to and from the common charset, ISO-10646.</t>
</section>
<section anchor="tool" title="The tool Attribute">
<t>The definition of this attribute make it clear that this attribute contains the name and version number of the tool that created the session description as a whole.
But it probably would be useful to define this attribute at the media level too, so we can know the tools used for create the individual media descriptions.</t>
</section>
<section anchor="others" title="The ipbcp, bcastversion, 3GPP-Integrity-Key, 3GPP-SDP-Auth, alt-group, PSCid, bc_service, bc_program and bc_service_package Attributes">
<t>These attributes were not defined in IETF Standard Track documents, so the analysis is left to the SDOs that produced this specifications.</t>
</section>
</section>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="Modifications between -04 and -03">
<t>
<list style="symbols">
<t>Updated rtp+ecn reference.</t>
<t>IANA registry for ice-mismatch fixed.</t>
</list>
</t>
</section>
<section title="Design Notes">
<t>
<list style="symbols">
<t>It has been proposed multiple times to use a different attribute name for the ice-options attribute when used at the media-level.
Using a different name does not solve the aggregation problem and, in the opinion of this author, could create confusion.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:53:13 |