moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

1.1rc4

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3665 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-12-02 19:49:46 +00:00
parent 2d3695a6ae
commit 546f040c3d
1 changed files with 12 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
xep-0167.xml
View File

@ -19,6 +19,8 @@
<spec>XMPP Core</spec>
<spec>XEP-0166</spec>
<spec>RFC 3550</spec>
<spec>RFC 3551</spec>
<spec>RFC 3711</spec>
</dependencies>
<supersedes/>
<supersededby/>
@ -42,10 +44,10 @@
&robmcqueen;
&diana;
<revision>
<version>1.1rc3</version>
<version>1.1rc4</version>
<date>in progress, last updated 2009-12-02</date>
<initials>psa</initials>
<remark><p>Added creator attribute to mute and unmute elements so that these events can be correlated with a particular content type; clarified use of the reason element in cases other than termination; defined handling of content-add when none of the offered payload-types are supported, where the signalling uses a content-reject message with a Jingle reason of &lt;failed-application/&gt; and a list of the supported codecs; clarified that the SDP transport is RTP/AVP by default, that the transport is RTP/SAVP if security preconditions are present, and that additional transports such as RTP/AVPF and RTP/SAVPF might be supported in a future version of this specification.</p></remark>
<remark><p>Added creator attribute to mute and unmute elements so that these events can be correlated with a particular content type; clarified use of the reason element in cases other than termination; defined handling of content-add when none of the offered payload-types are supported, where the signalling uses a content-reject message with a Jingle reason of &lt;failed-application/&gt; and a list of the supported codecs; clarified that the RTP profile is RTP/AVP by default, that the profile is RTP/SAVP if security preconditions are present, and that additional profiles such as RTP/AVPF and RTP/SAVPF might be supported in a future version of this specification.</p></remark>
</revision>
<revision>
<version>1.0</version>
@ -309,6 +311,12 @@
<section1 topic='Application Format' anchor='format'>
<p>A Jingle RTP session is described by a content type that contains one application format and one transport method. Each &lt;content/&gt; element defines a single RTP session. A Jingle negotiation MAY result in the establishment of multiple RTP sessions (e.g., one for audio and one for video). An application SHOULD consider all of the RTP sessions that are established via the same Jingle negotiation to be synchronized for purposes of streaming, playback, recording, etc.</p>
<p>RTP as defined in <cite>RFC 3550</cite> is used in the context of various "profiles" that are defined by other specifications. Jingle RTP treats RTP profiles as follows:</p>
<ol>
<li>By default the RTP profile in Jingle RTP MUST be considered "RTP/AVP" as defined in &rfc3551;.</li>
<li>If the session initiation request contains an &lt;encryption/&gt; element to specify use of SRTP as described under <link url='#srtp'>Negotiation of SRTP</link>, then the RTP profile MUST instead be considered "RTP/SAVP" as defined in &rfc3711;.</li>
<li>Future versions of this specification might define how to use other RTP profiles, such as "RTP/AVPF" and "RTP/SAVPF" as defined in &rfc4585; and &rfc5124; respectively.</li>
</ol>
<p>The application format consists of one or more encodings contained within a wrapper &lt;description/&gt; element qualified by the 'urn:xmpp:jingle:apps:rtp:1' namespace &VNOTE;. In the language of <cite>RFC 4566</cite> each encoding is a payload-type; therefore, each &lt;payload-type/&gt; element specifies an encoding that can be used for the RTP stream, as illustrated in the following example.</p>
<code><![CDATA[
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
@ -374,7 +382,7 @@
<td>OPTIONAL</td>
</tr>
</table>
<p>In Jingle RTP, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in &rfc3551; (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of <cite>RFC 3551</cite>. The payload IDs are represented in the 'id' attribute.</p>
<p>In Jingle RTP, the encodings are used in the context of RTP. The most common encodings for the Audio/Video Profile (AVP) of RTP are listed in <cite>RFC 3551</cite> (these "static" types are reserved from payload ID 0 through payload ID 95), although other encodings are allowed (these "dynamic" types use payload IDs 96 to 127) in accordance with the dynamic assignment rules described in Section 3 of <cite>RFC 3551</cite>. The payload IDs are represented in the 'id' attribute.</p>
<p>Each &lt;payload-type/&gt; element MAY contain one or more child elements that specify particular parameters related to the payload. For example, as described in &rfc5574;, the "cng", "mode", and "vbr" parameters can be specified in relation to usage of the Speex <note>See &lt;<link url='http://www.speex.org/'>http://www.speex.org/</link>&gt;.</note> codec. Where such parameters are encoded via the "fmtp" SDP attribute, they shall be represented in Jingle via the following format:</p>
<code><![CDATA[
<parameter name='foo' value='bar'/>
@ -519,8 +527,7 @@ Initiator Responder
<code><![CDATA[
m=<media> <port> <transport> <fmt list>
]]></code>
<p>The SDP &lt;media&gt; parameter is "audio" or "video" or some other media type as specified by the Jingle 'media' attribute, the &lt;port&gt; parameter is the preferred port for such communications (which might be determined dynamically), and the &lt;fmt list&gt; parameter is the payload-type ID.</p>
<p>By default the SDP &lt;transport&gt; MUST be considered "RTP/AVP" as defined in <cite>RFC 3550</cite>. If the initiation request contains a &lt;security/&gt; element to specify security preconditions for the session, then the SDP &lt;transport&gt; MUST instead be considered "RTP/SAVP" as defined in <cite>RFC 3711</cite>. Future versions of this specification might define how to use other SDP transports, such as "RTP/AVPF" and "RTP/SAVPF" as defined in &rfc4585; and &rfc5124; respectively.</p>
<p>The SDP &lt;media&gt; parameter is "audio" or "video" or some other media type as specified by the Jingle 'media' attribute, the &lt;port&gt; parameter is the preferred port for such communications (which might be determined dynamically), the &lt;transport&gt; parameter shall correspond to the RTP profile as described under <link url='#format'>Application Format</link>, and the &lt;fmt list&gt; parameter is the payload-type ID.</p>
<p>For example, consider the following static payload-type:</p>
<code><![CDATA[
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>