One document matched: draft-petithuguenin-mmusic-ice-attributes-level-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc compact="yes" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" docName="draft-petithuguenin-mmusic-ice-attributes-level-01" 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>Stonyfish, Inc.</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="30" month="June" year="2011"/>
<abstract>
<t>
This document redefines 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="I-D.ietf-avtcore-ecn-for-rtp"/>) 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="ecn" 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 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="I-D.ietf-avtcore-ecn-for-rtp"/>, 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="http://www.rfc-editor.org/rfc/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"/>
<abstract>
<t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5245"/>
<format octets="285120" target="http://www.rfc-editor.org/rfc/rfc5245.txt" type="TXT"/>
</reference>
<reference anchor="I-D.ietf-avtcore-ecn-for-rtp">
<front>
<title>Explicit Congestion Notification (ECN) for RTP over UDP</title>
<author fullname="Magnus Westerlund" initials="M" surname="Westerlund">
<organization/>
</author>
<author fullname="Ingemar Johansson" initials="I" surname="Johansson">
<organization/>
</author>
<author fullname="Colin Perkins" initials="C" surname="Perkins">
<organization/>
</author>
<author fullname="Piers O'Hanlon" initials="P" surname="O'Hanlon">
<organization/>
</author>
<author fullname="Ken Carlberg" initials="K" surname="Carlberg">
<organization/>
</author>
<date day="31" month="May" year="2011"/>
<abstract>
<t>This memo specifies how Explicit Congestion Notification (ECN) can be used with Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initilization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initilization methods are also defined.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-avtcore-ecn-for-rtp-02"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-02.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="http://www.rfc-editor.org/rfc/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="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="ecn"/>:</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="ecn"/>:</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="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="Modifications between -01 and -00">
<t>
<list style="symbols">
<t>Changed the rtp+ecn aggregation rule so that non-ICE media are not used when aggregating.</t>
<t>Filled Security and IANA sections.</t>
<t>Added examples of aggregation.</t>
<t>Added a design note about using different attribute name at media level.</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:15 |