mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 15:18:51 -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