One document matched: draft-petithuguenin-mmusic-ice-attributes-level-02.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-attributes-level-00" ipr="noModificationTrust200902" updates="5245">
<front>
<title abbrev="Attributes Level">Convertion between SDP Session Level and Media Level Attributes</title>
<author fullname="Marc Petit-Huguenin" initials="M.P.H" surname="Petit-Huguenin">
<organization>(Unaffiliated)</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="8" month="December" year="2011"/>
<area>RAI</area>
<workgroup>MMUSIC</workgroup>
<abstract>
<t>
This document also normatively updates RFC 5245 by mandating all new SDP attributes to be defined at both the session and media level, and to be accompanied by a normative algorithm to convert between the two levels.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Not all the <xref target="RFC4566">SDP</xref> attributes are defined at both session and media level.
This creates problems when SDP is used with disaggregated media (see section 3 of <xref target="I-D.loreto-splices-disaggregated-media"/>), as each m= line can be produced or consumed by a different implementation, perhaps even on a different physical device.
</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>
<t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "NOT RECOMMENDED" are appropriate when valid exceptions to a general requirement are known to exist or appear to exist, and it is infeasible or impractical to enumerate all of them.
However, they should not be interpreted as permitting implementors to fail to implement the general requirement when such failure would result in interoperability failure.
</t>
</section>
<texttable anchor="lines">
<ttcol>Letter</ttcol> <ttcol>Level</ttcol> <ttcol>Comments</ttcol>
<c>v</c> <c>session</c> <c>?</c>
<c>o</c> <c>session</c> <c>?</c>
<c>s</c> <c>session</c> <c>?</c>
<c>i</c> <c>both</c> <c>?</c>
<c>u</c> <c>session</c> <c>?</c>
<c>e</c> <c>session</c> <c>?</c>
<c>p</c> <c>session</c> <c>?</c>
<c>c</c> <c>both</c> <c>?</c>
<c>b</c> <c>both</c> <c>?</c>
<c>z</c> <c>session</c> <c>?</c>
<c>k</c> <c>both</c> <c>?</c>
<c>a</c> <c>both</c> <c>See below</c>
<c>t</c> <c>session</c> <c/>
<c>r</c> <c>session</c> <c/>
<c>m</c> <c>N/A</c> <c/>
</texttable>
<texttable anchor="attributes">
<ttcol>Attribute</ttcol> <ttcol>Level</ttcol> <ttcol>Comments</ttcol>
<c>cat</c> <c>session</c> <c>?</c>
<c>keywds</c> <c>session</c> <c>?</c>
<c>tool</c> <c>session</c> <c>Should probably also be defined at media level?</c>
<c>ptime</c> <c>media</c> <c>OK</c>
<c>maxptime</c> <c>media</c> <c>OK</c>
<c>rtpmap</c> <c>media</c> <c>OK</c>
<c>recvonly</c> <c>both</c> <c>Standard algo</c>
<c>sendrecv</c> <c>both</c> <c>Standard algo</c>
<c>sendonly</c> <c>both</c> <c>Standard algo</c>
<c>inactive</c> <c>both</c> <c>Standard algo</c>
<c>orient</c> <c>media</c> <c>OK</c>
<c>type</c> <c>session</c> <c>?</c>
<c>charset</c> <c>session</c> <c>?</c>
<c>sdplang</c> <c>both</c> <c>?</c>
<c>lang</c> <c>both</c> <c>?</c>
<c>framerate</c> <c>media</c> <c>OK</c>
<c>quality</c> <c>media</c> <c>OK</c>
<c>fmtp</c> <c>media</c> <c>OK</c>
</texttable>
<section title="Security Considerations">
</section>
<section title="IANA Considerations">
</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="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"/>
<abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4566"/>
<format octets="108820" target="http://www.rfc-editor.org/rfc/rfc4566.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>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:53:22 |