mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 18:22:24 -05:00
inbox versions
This commit is contained in:
stpeter
parent
9a9ec8a52d
commit
d42870fe8c
339
inbox/rtcp-fb.xml
Normal file
339
inbox/rtcp-fb.xml
Normal file
@ -0,0 +1,339 @@
|
|||||||
|
<?xml version='1.0' encoding='UTF-8'?>
|
||||||
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||||
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||||
|
%ents;
|
||||||
|
]>
|
||||||
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||||
|
<xep>
|
||||||
|
<header>
|
||||||
|
<title>Jingle RTP Feedback Negotiation</title>
|
||||||
|
<abstract>This specification defines an XMPP extension to negotiate
|
||||||
|
the use of the Extended RTP Profile for Real-time Transport Control
|
||||||
|
Protocol (RTCP)-Based Feedback (RTP/AVPF) with Jingle RTP
|
||||||
|
sessions</abstract>
|
||||||
|
&LEGALNOTICE;
|
||||||
|
<number>xxxx</number>
|
||||||
|
<status>ProtoXEP</status>
|
||||||
|
<type>Standard</type>
|
||||||
|
<sig>Standards</sig>
|
||||||
|
<approver>Council</approver>
|
||||||
|
<dependencies>
|
||||||
|
<spec>XEP-0167</spec>
|
||||||
|
<spec>RFC 4585</spec>
|
||||||
|
</dependencies>
|
||||||
|
<author>
|
||||||
|
<firstname>Olivier</firstname>
|
||||||
|
<surname>Crête</surname>
|
||||||
|
<email>olivier.crete@collabora.co.uk</email>
|
||||||
|
<jid>olivier.crete@collabora.co.uk</jid>
|
||||||
|
</author>
|
||||||
|
<discuss>jingle</discuss>
|
||||||
|
<revision>
|
||||||
|
<version>0.0.1</version>
|
||||||
|
<date>2011-01-10</date>
|
||||||
|
<initials>oc</initials>
|
||||||
|
<remark><p>First draft.</p></remark>
|
||||||
|
</revision>
|
||||||
|
</header>
|
||||||
|
|
||||||
|
<section1 topic='Introduction' anchor='introduction'>
|
||||||
|
<p>This documents specifies how to negotiate the use of the Extended
|
||||||
|
RTP Profile for Real-time Transport Control Protocol (RTCP)-Based
|
||||||
|
Feedback (RTP/AVPF) with Jingle RTP sessions.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Requirements' anchor='requirements'>
|
||||||
|
<p>The Jingle extension defined herein is designed to meet the following requirements:</p>
|
||||||
|
<ol>
|
||||||
|
<li>Enable negotiations of the required parameters for the
|
||||||
|
transmissions of RTP Feedback messages as defined in RFC
|
||||||
|
4585.</li>
|
||||||
|
<li>Map these parameters to Session Description Protocol (SDP; see
|
||||||
|
&rfc4566;) to enable interoperability.</li>
|
||||||
|
</ol>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='New elements' anchor='elements'>
|
||||||
|
<p>This specification defines two new elements, <rtcp-fb/> and
|
||||||
|
<rtcp-fb-trr-int/>, that can be inserted in the
|
||||||
|
<description/> or the <payload-type/> elements of a
|
||||||
|
XEP-0167 RTP session. The presence of any of these elements in a
|
||||||
|
content's description means that the RTP/AVPF profile should be used
|
||||||
|
for the whole content. If any of these elements are inside the
|
||||||
|
<payload-type/> element, the parameters specified apply only to
|
||||||
|
that payload type, if they are directly inside the
|
||||||
|
<description/> tag, then the specified parameters apply to the
|
||||||
|
whole content.</p>
|
||||||
|
|
||||||
|
<p>The attributes of the <rtcp-fb/> element are:</p>
|
||||||
|
<table caption='rtcp-fb attributes'>
|
||||||
|
<tr>
|
||||||
|
<th>Attribute</th>
|
||||||
|
<th>Description</th>
|
||||||
|
<th>Inclusion</th>
|
||||||
|
<th>Possible values</th>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>type</td>
|
||||||
|
<td>The type of feedback</td>
|
||||||
|
<td>REQUIRED</td>
|
||||||
|
<td>ack, nack, ccm, app, etc..</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>subtype</td>
|
||||||
|
<td>The subtype (depends on the type)</td>
|
||||||
|
<td>OPTIONAL (possibly REQUIRED depending on the type)</td>
|
||||||
|
<td>
|
||||||
|
ack: rpsi, app<br/>
|
||||||
|
nack: sli, pli, rpsi, app, rai<br/>
|
||||||
|
ccm: fir, tmmbr, tstr, vbcm<br/>
|
||||||
|
app: depends on the application<br/>
|
||||||
|
</td>
|
||||||
|
</tr>
|
||||||
|
</table>
|
||||||
|
|
||||||
|
<p>Any type or subtype of feedback message that requires extra
|
||||||
|
parameters in the a=b form can use the <parameter/> element to
|
||||||
|
describe it. Any other form of parameter can be store in the CDATA
|
||||||
|
inside the <rtcp-fb/> element.</p>
|
||||||
|
|
||||||
|
<p>The element <rtcp-fb-trr-int/> is used to specify the minimum
|
||||||
|
interval between two Regular (full compound) RTCP packets in
|
||||||
|
milliseconds for this media session. It corresponds to the
|
||||||
|
"a=rtcp-fb:* trr-int" line in SDP. The attributes of the
|
||||||
|
<rtcp-fb-trr-int/> element are:</p>
|
||||||
|
<table caption='rtcp-fb-trr-int attributes'>
|
||||||
|
<tr>
|
||||||
|
<th>Attribute</th>
|
||||||
|
<th>Description</th>
|
||||||
|
<th>Inclusion</th>
|
||||||
|
<th>Possible values</th>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>value</td>
|
||||||
|
<td>Number of milliseconds between regular RTCP reports</td>
|
||||||
|
<td>REQUIRED</td>
|
||||||
|
<td>0 to MAXUINT (default to 0)</td>
|
||||||
|
</tr>
|
||||||
|
</table>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<section1 topic='Negotiation' anchor='negotiation'>
|
||||||
|
<p>Feedback messages are negotiated along the codecs. They follow
|
||||||
|
the same Offer/Answer mechanism based on SDP Offer/Answer. The
|
||||||
|
initiator signals which feedback messages it wants to send or
|
||||||
|
receive in the the <session-initiate/> iq stanza. If the
|
||||||
|
responder does not understand the type or subtype of a feedback
|
||||||
|
message, it MUST remove the element from the reply. If the responder
|
||||||
|
does not wish to provide or receive some kind of feedback, it MUST
|
||||||
|
remove the relevant element. It MUST then send the remaining
|
||||||
|
elements it wants to keep as-is without modifying them in the
|
||||||
|
<session-accept/></p>
|
||||||
|
|
||||||
|
<p>The responder MUST send any <rtcp-fb/> element as-is if it
|
||||||
|
accepts it. It MUST NOT change any parameter to conform the the
|
||||||
|
negotiation defined in RFC 4585 Section 4. It MUST NOT add any
|
||||||
|
<rtcp-fb/> element that was not offered by the initiator. It
|
||||||
|
MUST NOT modify the 'value' of any >rtcp-fb-trr-int/<
|
||||||
|
element. It can only remove the >rtcp-fb-trr-int/< element or
|
||||||
|
reject the content. If all the feedback messages are removed but the
|
||||||
|
responder wants to stay in the RTP/AVPF profile, it MUST put a
|
||||||
|
<rtcp-fb-trr-int/> element with the same 'value' that it
|
||||||
|
received from the intiator, if the initiator did not provide a
|
||||||
|
<rtcp-fb-trr-int/> element, then this value is "0".</p>
|
||||||
|
|
||||||
|
<p>Example negotiation where the initiator requests Packet Loss
|
||||||
|
Indications (pli) as defined in RFC 4585 on both H.263 and H.264,
|
||||||
|
but also requests Slice Loss Indications for H.264 with a minimum
|
||||||
|
interval between regular full compound RTCP packets of 100 milliseconds.</p>
|
||||||
|
|
||||||
|
<example caption='Initiator sends description inside session-initiate'><![CDATA[
|
||||||
|
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='video'>
|
||||||
|
<rtcp-fb xmlns='urn:xmpp:jingle:apps:rtp:rtcp-fb:0' type='nack' subtype='pli'/>
|
||||||
|
<payload-type id='96' name='H264' clockrate='90000'>
|
||||||
|
<rtcp-fb-trr-int xmlns='urn:xmpp:jingle:apps:rtp:rtcp-fb:0' value='100'/>
|
||||||
|
<rtcp-fb xmlns='urn:xmpp:jingle:apps:rtp:rtcp-fb:0' type='nack' subtype='sli'/>
|
||||||
|
</payload-type>
|
||||||
|
<payload-type id='34' name='H263' clockrate='90000'/>
|
||||||
|
</description>
|
||||||
|
]]></example>
|
||||||
|
|
||||||
|
<p>Example reply where the responder rejects the "sli" but
|
||||||
|
accepts the "pli".</p>
|
||||||
|
|
||||||
|
<example caption='Reponder sends description inside session-accept'><![CDATA[
|
||||||
|
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='video'>
|
||||||
|
<rtcp-fb xmlns='urn:xmpp:jingle:apps:rtp:rtcp-fb:0' type='nack' subtype='pli'/>
|
||||||
|
<payload-type id='96' name='H264' clockrate='90000'>
|
||||||
|
<rtcp-fb-trr-int xmlns='urn:xmpp:jingle:apps:rtp:rtcp-fb:0' value='100'/>
|
||||||
|
</payload-type>
|
||||||
|
<payload-type id='34' name='H263' clockrate='90000'/>
|
||||||
|
</description>
|
||||||
|
]]></example>
|
||||||
|
|
||||||
|
<p>Another reply to the same request where the responder wishes to
|
||||||
|
stay in the AVPF profile but rejects all specific feedback messages
|
||||||
|
by using the <rtcp-fb-trr-int/> with the default value.</p>
|
||||||
|
|
||||||
|
<example caption='Responder sends description inside session-accept without any feedback message'><![CDATA[
|
||||||
|
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='video'>
|
||||||
|
<rtcp-fb-trr-int xmlns='urn:xmpp:jingle:apps:rtp:rtcp-fb:0' value='0'/>
|
||||||
|
<payload-type id='96' name='H264' clockrate='90000'/>
|
||||||
|
<payload-type id='34' name='H263' clockrate='90000'/>
|
||||||
|
</description>
|
||||||
|
]]></example>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Mapping to Session Description Protocol' anchor='sdp-mapping'>
|
||||||
|
<p>The <rtcp-fb/> element maps to the a:rtcp-fb= SDP line with
|
||||||
|
the exception of the 'trr-int' parameter which is mapped into it's
|
||||||
|
own element (<rtcp-fb-trr-int/>) in XMPP. The payload types
|
||||||
|
are also not explicitly written in the <rtcp-fb/> and
|
||||||
|
<rtcp-fb-trr-int/> elements. Instead, each payload type has its own
|
||||||
|
set of <rtcp-fb/> and <rtcp-fb-trr-int/> elements if
|
||||||
|
they do not apply to the whole content.</p>
|
||||||
|
|
||||||
|
<p>Example conversion of a sample fragment of a SDP containing an
|
||||||
|
audio session using the RTP/AVP profile for audio and the RTP/AVPF
|
||||||
|
profile for video:</p>
|
||||||
|
<example caption='SDP fragment'><![CDATA[
|
||||||
|
v=0
|
||||||
|
o=remeo 3203093520 3203093520 IN IP4 host.example.com
|
||||||
|
s=Video call with feedback
|
||||||
|
t=3203130148 3203137348
|
||||||
|
m=audio 49170 RTP/AVP 0
|
||||||
|
c=IN IP4 10.0.1.1
|
||||||
|
a=rtpmap:0 PCMU/8000
|
||||||
|
m=video 59172 RTP/AVPF 98 99
|
||||||
|
c=IN IP4 10.0.1.1
|
||||||
|
a=rtpmap:98 H263-1998/90000
|
||||||
|
a=rtpmap:99 H261/90000
|
||||||
|
a=rtcp-fb:* nack
|
||||||
|
a=rtcp-fb:98 nack rpsi
|
||||||
|
a=rtcp-fb:98 trr-int 100
|
||||||
|
]]></example>
|
||||||
|
<example caption='The same description in XMPP format'><![CDATA[
|
||||||
|
<iq from='romeo@montague.lit/orchard'
|
||||||
|
id='ph37a419'
|
||||||
|
to='juliet@capulet.lit/balcony'
|
||||||
|
type='set'>
|
||||||
|
<jingle xmlns='urn:xmpp:jingle:1'>
|
||||||
|
action='session-initiate'
|
||||||
|
initiator='romeo@montague.lit/orchard'
|
||||||
|
sid='a73sjjvkla37jfea'>
|
||||||
|
<content creator='initiator' name='voice'>
|
||||||
|
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
|
||||||
|
<payload-type id='0' name='PCMU' />
|
||||||
|
</description>
|
||||||
|
<transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
|
||||||
|
<candidate component='1'
|
||||||
|
generation='0'
|
||||||
|
id='a9j3mnbtu1'
|
||||||
|
ip='10.0.1.1'
|
||||||
|
port='49170'/>
|
||||||
|
<candidate component='2'
|
||||||
|
generation='0'
|
||||||
|
id='a9j3mnbtu1'
|
||||||
|
ip='10.0.1.1'
|
||||||
|
port='49171'/>
|
||||||
|
</transport>
|
||||||
|
</content>
|
||||||
|
<content creator='initiator' name='face'>
|
||||||
|
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='video'>
|
||||||
|
<rtcp-fb xmlns='urn:xmpp:jingle:apps:rtp:rtcp-fb:0' type='nack'/>
|
||||||
|
<payload-type id='98' name='H263-1998'>
|
||||||
|
<rtcp-fb xmlns='urn:xmpp:jingle:apps:rtp:rtcp-fb:0' type='nack'
|
||||||
|
subtype='rpsi'/>
|
||||||
|
<rtcp-fb-trr-int xmlns='urn:xmpp:jingle:apps:rtp:rtcp-fb:0' value='100'/>
|
||||||
|
</payload-type>
|
||||||
|
<payload-type id='99' name='H264' />
|
||||||
|
</description>
|
||||||
|
<transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
|
||||||
|
<candidate component='1'
|
||||||
|
generation='0'
|
||||||
|
id='a9j3mnbtu1'
|
||||||
|
ip='10.0.1.1'
|
||||||
|
port='49172'/>
|
||||||
|
<candidate component='2'
|
||||||
|
generation='0'
|
||||||
|
id='a9j3mnbtu1'
|
||||||
|
ip='10.0.1.1'
|
||||||
|
port='49173'/>
|
||||||
|
</transport>
|
||||||
|
</content>
|
||||||
|
</jingle>
|
||||||
|
</iq>
|
||||||
|
|
||||||
|
]]></example>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Determining support' anchor='determining-support'>
|
||||||
|
<p>To advertise its support for Extended RTCP Feedback in Jingle RTP
|
||||||
|
Sessions and a minimum interval between regular RTCP packets, when
|
||||||
|
replying to &xep0030; information requests an entity MUST return the
|
||||||
|
following features:</p>
|
||||||
|
|
||||||
|
<ol>
|
||||||
|
<li>URNs for any version of this protocol that the entity
|
||||||
|
supports -- e.g., "urn:xmpp:jingle:apps:rtp:rtcp-fb:0" for the
|
||||||
|
current version</li>
|
||||||
|
</ol>
|
||||||
|
|
||||||
|
<p>An example follows:</p>
|
||||||
|
|
||||||
|
<example caption="Service discovery information request"><![CDATA[
|
||||||
|
<iq from='romeo@montague.lit/orchard'
|
||||||
|
id='bh3vd715'
|
||||||
|
to='juliet@capulet.lit/balcony'
|
||||||
|
type='get'>
|
||||||
|
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||||
|
</iq>
|
||||||
|
]]></example>
|
||||||
|
|
||||||
|
<example caption="Service discovery information response"><![CDATA[
|
||||||
|
<iq from='juliet@capulet.lit/balcony'
|
||||||
|
id='bh3vd715'
|
||||||
|
to='romeo@montague.lit/orchard'
|
||||||
|
type='result'>
|
||||||
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||||
|
<feature var='urn:xmpp:jingle:1'/>
|
||||||
|
<feature var='urn:xmpp:jingle:apps:rtp:1'/>
|
||||||
|
<feature var='urn:xmpp:jingle:apps:rtp:video'/>
|
||||||
|
<feature var='urn:xmpp:jingle:apps:rtp:rtcp-fb:0'/>
|
||||||
|
</query>
|
||||||
|
</iq>
|
||||||
|
]]></example>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='IANA Considerations' anchor='iana-considerations'>
|
||||||
|
<p>This document requires no interaction with the Internet Assigned
|
||||||
|
Numbers Authority (IANA).</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||||
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
||||||
|
<p>This specification defines the following XML namespaces:</p>
|
||||||
|
<ul>
|
||||||
|
<li>urn:xmpp:jingle:apps:rtp:rtcp-fb:0</li>
|
||||||
|
</ul>
|
||||||
|
<p>The ®ISTRAR; includes the foregoing namespaces in its
|
||||||
|
registry at &NAMESPACES;, as governed by &xep0053;.</p>
|
||||||
|
</section2>
|
||||||
|
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
|
||||||
|
<p>If the protocol defined in this specification undergoes a
|
||||||
|
revision that is not fully backwards-compatible with an older
|
||||||
|
version, the XMPP Registrar shall increment the protocol version
|
||||||
|
number found at the end of the XML namespaces defined herein, as
|
||||||
|
described in Section 4 of XEP-0053.</p>
|
||||||
|
</section2>
|
||||||
|
</section1>
|
||||||
|
<section1 topic='XML Schemas'>
|
||||||
|
<p>TODO: Write actual schema</p>
|
||||||
|
</section1>
|
||||||
|
<section1 topic='Acknowledgements' anchor='ack'>
|
||||||
|
<p>Thanks to Youness Alaoui for his feedback.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
</xep>
|
||||||
256
inbox/rtp-hdrext.xml
Normal file
256
inbox/rtp-hdrext.xml
Normal file
@ -0,0 +1,256 @@
|
|||||||
|
<?xml version='1.0' encoding='UTF-8'?>
|
||||||
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||||
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||||
|
%ents;
|
||||||
|
]>
|
||||||
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||||
|
<xep>
|
||||||
|
<header>
|
||||||
|
<title>Jingle RTP Header Extensions negotiation</title>
|
||||||
|
<abstract>This specification defines an XMPP extension to negotiate
|
||||||
|
the use of the use of RTP Header Extension as defined by RFC 5285
|
||||||
|
with Jingle RTP sessions</abstract>
|
||||||
|
&LEGALNOTICE;
|
||||||
|
<number>xxxx</number>
|
||||||
|
<status>ProtoXEP</status>
|
||||||
|
<type>Standard</type>
|
||||||
|
<sig>Standards</sig>
|
||||||
|
<approver>Council</approver>
|
||||||
|
<dependencies>
|
||||||
|
<spec>XEP-0167</spec>
|
||||||
|
<spec>RFC 85</spec>
|
||||||
|
</dependencies>
|
||||||
|
<author>
|
||||||
|
<firstname>Olivier</firstname>
|
||||||
|
<surname>Crête</surname>
|
||||||
|
<email>olivier.crete@collabora.co.uk</email>
|
||||||
|
<jid>olivier.crete@collabora.co.uk</jid>
|
||||||
|
</author>
|
||||||
|
<discuss>jingle</discuss>
|
||||||
|
<revision>
|
||||||
|
<version>0.0.1</version>
|
||||||
|
<date>2011-01-10</date>
|
||||||
|
<initials>oc</initials>
|
||||||
|
<remark><p>First draft.</p></remark>
|
||||||
|
</revision>
|
||||||
|
</header>
|
||||||
|
|
||||||
|
<section1 topic='Introduction' anchor='introduction'>
|
||||||
|
<p>This documents specifies how to negotiate the use of the RTP
|
||||||
|
Header Extensions as defined by RFC 5285 with Jingle RTP
|
||||||
|
sessions.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Requirements' anchor='requirements'>
|
||||||
|
<p>The Jingle extension defined herein is designed to meet the following requirements:</p>
|
||||||
|
<ol>
|
||||||
|
<li>Enable negotiations of the RTP Header extensions as defined in
|
||||||
|
RFC 5285.</li>
|
||||||
|
<li>Map these parameters to Session Description Protocol (SDP; see
|
||||||
|
&rfc4566;) to enable interoperability.</li>
|
||||||
|
</ol>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='New element' anchor='element'>
|
||||||
|
<p>This specification defines a new element, <rtp-hdrext/>,
|
||||||
|
that can be inserted in the <description/> element of a
|
||||||
|
XEP-0167 RTP session.</p>
|
||||||
|
|
||||||
|
<p>The attributes of the <rtp-hdrext/> element are:</p>
|
||||||
|
<table caption='rtp-hdrext attributes'>
|
||||||
|
<tr>
|
||||||
|
<th>Attribute</th>
|
||||||
|
<th>Description</th>
|
||||||
|
<th>Inclusion</th>
|
||||||
|
<th>Possible values</th>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>id</td>
|
||||||
|
<td>The ID of the extensions</td>
|
||||||
|
<td>REQUIRED</td>
|
||||||
|
<td>1-256, 4096-4351</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>uri</td>
|
||||||
|
<td>The URI that defines the extension</td>
|
||||||
|
<td>REQUIRED</td>
|
||||||
|
<td>Any valid URI</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>senders</td>
|
||||||
|
<td>Which party is allowed to send the negotiated RTP Header Extensions</td>
|
||||||
|
<td>OPTIONAL (defaults to "both")</td>
|
||||||
|
<td>"initiator", "responder", and "both"</td>
|
||||||
|
</tr>
|
||||||
|
</table>
|
||||||
|
|
||||||
|
<p>Any type of RTP Header Extension that requires extra
|
||||||
|
parameters in the a=b form can embed <parameter/> elements to
|
||||||
|
describe it. Any other form of parameter can be stored in the CDATA
|
||||||
|
inside the <rtp-hdrext/> element.</p>
|
||||||
|
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Negotiation' anchor='negotiation'>
|
||||||
|
<p>RTP header extensions are negotiated along the codecs. They
|
||||||
|
follow the same Offer/Answer mechanism based on SDP
|
||||||
|
Offer/Answer. The initiator signals which RTP header extensions it
|
||||||
|
wants to send or receive in the the <session-initiate/> iq
|
||||||
|
stanza. If the responder does not understand the type of header
|
||||||
|
extensions, it MUST remove the element from the reply. If the
|
||||||
|
responder does not wish to provide or receive some kind of RTP
|
||||||
|
header extension, it MUST remove the relevant element from the
|
||||||
|
reply. It MUST then send the remaining elements it wants to keep
|
||||||
|
as-is without modifying them in the <session-accept/> iq
|
||||||
|
stanza.</p>
|
||||||
|
|
||||||
|
<p> It MUST NOT add any <rtp-hdrext/> element that was not
|
||||||
|
offered by the initiator. The responder MAY downgrade the senders
|
||||||
|
field from "both" to "initator" or "responder", but MUST NOT modify it
|
||||||
|
if it is "initator" or "responder".</p>
|
||||||
|
|
||||||
|
<p>Example negotiation where the initiator offers to use the
|
||||||
|
timestamp offset header extension as defined in RFC 5450 and also
|
||||||
|
the requests synchronisation metadata header extension (RFC 6051)
|
||||||
|
with either the 56-bit or the 64-bit format.</p>
|
||||||
|
|
||||||
|
<example caption='Initiator sends description inside session-initiate'>
|
||||||
|
<![CDATA[
|
||||||
|
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='video'>
|
||||||
|
<rtp-hdrext xmlns='urn:xmpp:jingle:apps:rtp:rtp-hdrext:0'
|
||||||
|
uri='urn:ietf:params:rtp-hdrext:toffset'
|
||||||
|
id='1'/>
|
||||||
|
<rtp-hdrext xmlns='urn:xmpp:jingle:apps:rtp:rtp-hdrext:0'
|
||||||
|
uri='urn:ietf:params:rtp-hdrext:ntp-64'
|
||||||
|
id='4907'/>
|
||||||
|
<rtp-hdrext xmlns='urn:xmpp:jingle:apps:rtp:rtp-hdrext:0'
|
||||||
|
uri='urn:ietf:params:rtp-hdrext:ntp-56'
|
||||||
|
id='4907'/>
|
||||||
|
<payload-type id='96' name='THEORA' clockrate='90000'/>
|
||||||
|
</description>
|
||||||
|
]]></example>
|
||||||
|
|
||||||
|
<p>Example reply where the responder accepts the timestamp offset
|
||||||
|
and the 56-bit synchronisation metadata header extensions.</p>
|
||||||
|
|
||||||
|
<example caption='Reponder sends description inside session-accept'><![CDATA[
|
||||||
|
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='video'>
|
||||||
|
<rtp-hdrext xmlns='urn:xmpp:jingle:apps:rtp:rtp-hdrext:0'
|
||||||
|
uri='urn:ietf:params:rtp-hdrext:toffset'
|
||||||
|
id='1'/>
|
||||||
|
<rtp-hdrext xmlns='urn:xmpp:jingle:apps:rtp:rtp-hdrext:0'
|
||||||
|
uri='urn:ietf:params:rtp-hdrext:ntp-56'
|
||||||
|
id='2'/>
|
||||||
|
<payload-type id='96' name='THEORA' clockrate='90000'/>
|
||||||
|
</description>
|
||||||
|
]]></example>
|
||||||
|
|
||||||
|
<p>Another reply to the same request where the responder accepts only the synchronisation data header extension with the 64-bit format.</p>
|
||||||
|
|
||||||
|
<example caption='Responder sends description inside session-accept with only the synchronisation data accepted'><![CDATA[
|
||||||
|
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='video'>
|
||||||
|
<rtp-hdrext xmlns='urn:xmpp:jingle:apps:rtp:rtp-hdrext:0'
|
||||||
|
uri='urn:ietf:params:rtp-hdrext:ntp-64'
|
||||||
|
id='2'/>
|
||||||
|
<payload-type id='96' name='THEORA' clockrate='90000'/>
|
||||||
|
</description>
|
||||||
|
]]></example>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Mapping to Session Description Protocol' anchor='sdp-mapping'>
|
||||||
|
<p>The <rtp-hdrext/> element maps to the "a:extmap=" SDP line
|
||||||
|
defined in RFC 5285. The ID is mapped to the 'id' attribute, the
|
||||||
|
direction to the 'senders' attribute and the URI to the 'uri'
|
||||||
|
attribute.</p>
|
||||||
|
|
||||||
|
<p>Example conversion of a incomplete sample fragment of a SDP taken from RFC 5285 section 6 into equivalent XMPP:</p>
|
||||||
|
<example caption='SDP fragment'><![CDATA[
|
||||||
|
m=video
|
||||||
|
a=sendrecv
|
||||||
|
a=extmap:1 URI-toffset
|
||||||
|
a=extmap:2/recvonly URI-gps-string
|
||||||
|
a=extmap:3 URI-frametype
|
||||||
|
]]></example>
|
||||||
|
<example caption='The same description in XMPP format'><![CDATA[
|
||||||
|
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='video'>
|
||||||
|
<rtp-hdrext xmlns='urn:xmpp:jingle:apps:rtp:rtp-hdrext:0'
|
||||||
|
id='1'
|
||||||
|
uri='URI-toffset'/>
|
||||||
|
<rtp-hdrext xmlns='urn:xmpp:jingle:apps:rtp:rtp-hdrext:0'
|
||||||
|
id='2'
|
||||||
|
uri='URI-gps-string'
|
||||||
|
senders='initiator'/>
|
||||||
|
<rtp-hdrext xmlns='urn:xmpp:jingle:apps:rtp:rtp-hdrext:0'
|
||||||
|
id='3'
|
||||||
|
uri='URI-frametype'/>
|
||||||
|
</description>
|
||||||
|
]]></example>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='Determining support' anchor='determining-support'>
|
||||||
|
<p>To advertise its support for Generic Header extensions in Jingle
|
||||||
|
RTP Sessions, when replying to &xep0030; information requests an
|
||||||
|
entity MUST return the following features:</p>
|
||||||
|
|
||||||
|
<ol>
|
||||||
|
<li>URNs for any version of this protocol that the entity
|
||||||
|
supports -- e.g., "urn:xmpp:jingle:apps:rtp:rtp-hdrext:0" for the
|
||||||
|
current version</li>
|
||||||
|
</ol>
|
||||||
|
|
||||||
|
<p>An example follows:</p>
|
||||||
|
|
||||||
|
<example caption="Service discovery information request"><![CDATA[
|
||||||
|
<iq from='romeo@montague.lit/orchard'
|
||||||
|
id='bh3vd715'
|
||||||
|
to='juliet@capulet.lit/balcony'
|
||||||
|
type='get'>
|
||||||
|
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||||
|
</iq>
|
||||||
|
]]></example>
|
||||||
|
|
||||||
|
<example caption="Service discovery information response"><![CDATA[
|
||||||
|
<iq from='juliet@capulet.lit/balcony'
|
||||||
|
id='bh3vd715'
|
||||||
|
to='romeo@montague.lit/orchard'
|
||||||
|
type='result'>
|
||||||
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||||
|
<feature var='urn:xmpp:jingle:1'/>
|
||||||
|
<feature var='urn:xmpp:jingle:apps:rtp:1'/>
|
||||||
|
<feature var='urn:xmpp:jingle:apps:rtp:video'/>
|
||||||
|
<feature var='urn:xmpp:jingle:apps:rtp:rtp-hdrext:0'/>
|
||||||
|
</query>
|
||||||
|
</iq>
|
||||||
|
]]></example>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='IANA Considerations' anchor='iana-considerations'>
|
||||||
|
<p>This document requires no interaction with the Internet Assigned
|
||||||
|
Numbers Authority (IANA).</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||||
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
||||||
|
<p>This specification defines the following XML namespaces:</p>
|
||||||
|
<ul>
|
||||||
|
<li>urn:xmpp:jingle:apps:rtp:rtp-hdrext:0</li>
|
||||||
|
</ul>
|
||||||
|
<p>The ®ISTRAR; includes the foregoing namespaces in its
|
||||||
|
registry at &NAMESPACES;, as governed by &xep0053;.</p>
|
||||||
|
</section2>
|
||||||
|
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
|
||||||
|
<p>If the protocol defined in this specification undergoes a
|
||||||
|
revision that is not fully backwards-compatible with an older
|
||||||
|
version, the XMPP Registrar shall increment the protocol version
|
||||||
|
number found at the end of the XML namespaces defined herein, as
|
||||||
|
described in Section 4 of XEP-0053.</p>
|
||||||
|
</section2>
|
||||||
|
</section1>
|
||||||
|
<section1 topic='XML Schemas'>
|
||||||
|
<p>TODO: Write actual schema</p>
|
||||||
|
</section1>
|
||||||
|
<section1 topic='Acknowledgements' anchor='ack'>
|
||||||
|
<p>Thanks to Youness Alaoui for his feedback.</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
|
</xep>
|
||||||
Loading…
Reference in New Issue
Block a user