mirror of https://github.com/moparisthebest/xeps
0.25rc1
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2581 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
2a71e1626e
commit
2c776569f3
144
xep-0167.xml
144
xep-0167.xml
|
|
@ -37,6 +37,7 @@
|
|||
<li>Refactored encryption syntax.</li>
|
||||
<li>Added optional bandwidth element.</li>
|
||||
<li>Added example of description-info action for modifying application parameters.</li>
|
||||
<li>Corrected the schemas.</li>
|
||||
</ul>
|
||||
</remark>
|
||||
</revision>
|
||||
|
|
@ -275,25 +276,25 @@
|
|||
<tr>
|
||||
<td>channels</td>
|
||||
<td>The number of channels; if omitted, it MUST be assumed to contain one channel</td>
|
||||
<td>positiveInteger (defaults to 1)</td>
|
||||
<td>unsignedByte (defaults to 1)</td>
|
||||
<td>RECOMMENDED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>clockrate</td>
|
||||
<td>The sampling frequency in Hertz</td>
|
||||
<td>positiveInteger</td>
|
||||
<td>unsignedInt</td>
|
||||
<td>RECOMMENDED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>id</td>
|
||||
<td>The payload identifier</td>
|
||||
<td>positiveInteger</td>
|
||||
<td>unsignedByte</td>
|
||||
<td>REQUIRED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>maxptime</td>
|
||||
<td>Maximum packet time as specified in RFC 4566</td>
|
||||
<td>positiveInteger</td>
|
||||
<td>unsignedInt</td>
|
||||
<td>OPTIONAL</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
|
@ -305,7 +306,7 @@
|
|||
<tr>
|
||||
<td>ptime</td>
|
||||
<td>Packet time as specified in RFC 4566</td>
|
||||
<td>positiveInteger</td>
|
||||
<td>unsignedInt</td>
|
||||
<td>OPTIONAL</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
|
@ -369,7 +370,7 @@ Initiator Responder
|
|||
to='romeo@montague.lit/orchard'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
<p>After successful transport negotiation (not shown here), the responder accepts the session by sending a session-accept action to the initiator. The session-accept SHOULD include a subset of the payload types sent by the initiator, i.e., a list of the offered payload types that the responder can send and/or receive. The list that the responder sends SHOULD retain the ID numbers specified by the initiator. The order of the &PAYLOADTYPE; elements indicates the responder's preferences, with the most-preferred types first.</p>
|
||||
<p>After successful transport negotiation (not shown here), the responder accepts the session by sending a session-accept action to the initiator. The session-accept SHOULD include a subset of the payload types sent by the initiator, i.e., a list of the offered payload types that the responder can send and/or receive. The list that the responder sends SHOULD retain the ID numbers specified by the initiator. The order of the &PAYLOADTYPE; elements indicates the responder's preferences, with the most-preferred type first.</p>
|
||||
<p>In the following example, we imagine that the responder supports Speex at clockrate of 8000 but not 16000, G729, and PCMA but not PMCU. Therefore the responder returns only two payload types (since PMCA was not offered).</p>
|
||||
<example caption="Responder definitively accepts the session"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
|
|
@ -420,12 +421,12 @@ Initiator Responder
|
|||
|
||||
<section1 topic='Mapping to Session Description Protocol' anchor='sdp'>
|
||||
<p>The SDP media type for Jingle RTP is "audio" (see Section 8.2.1 of <cite>RFC 4566</cite>) for audio media, "video" (see Section 8.2.1 of <cite>RFC 4566</cite>) for video media, etc. The media type is reflected in the Jingle 'media' attribute.</p>
|
||||
<p>The Jingle 'bandwidth' attribute SHALL be mapped to an SDP b= line, where the SDP <bwtype> parameter MUST be "AS" and the SDP <bandwidth> parameter contains the value of the Jingle 'bandwidth' attribute.</p>
|
||||
<p>The Jingle <bandwidth/> element SHALL be mapped to an SDP b= line; in particular, the value of the 'type' attribute shall be mapped to the SDP <bwtype> parameter and the XML character data of the Jingle <bandwidth/> element shall be mapped to the SDP <bandwidth> parameter.</p>
|
||||
<p>If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in <cite>RFC 4566</cite>. The generic format for the media field is as follows:</p>
|
||||
<code><![CDATA[
|
||||
m=<media> <port> <transport> <fmt list>
|
||||
]]></code>
|
||||
<p>In the context of Jingle audio sessions, the <media> is "audio" or "video" or some other media type as specified by the 'media' attribute, the <port> is the preferred port for such communications (which might be determined dynamically), and the <fmt list> is the payload-type ID.</p>
|
||||
<p>In the context of Jingle audio sessions, the <media> parameter is "audio" or "video" or some other media type as specified by the 'media' attribute, the <port> parameter is the preferred port for such communications (which might be determined dynamically), and the <fmt list> 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:0' media='audio'>
|
||||
|
|
@ -487,15 +488,15 @@ delivery-method=inline; configuration=somebase16string;
|
|||
|
||||
<section1 topic='Early Media' anchor='earlymedia'>
|
||||
<p>The term "early media" refers to media that is exchanged before a responder has definitively accepted a session request generated by an initiator. Early media is typically used to send ringing tones and announcements, using either audio streams or Dual Tone Multi-Frequency (DTMF) events.</p>
|
||||
<p>In Jingle, the exchange of early media is established through use of the "content-add" action. In order to match the usage specified in &rfc3959; and &rfc3960;, when adding a content definition for early media the value of the &CONTENT; element's 'disposition' attribute MUST be "early-session" for mapping to a SIP Content-Disposition header value of "early-session" (if necessary). This enables endpoints or intermediate gateways to apply the application server model described in <cite>RFC 3960</cite>.</p>
|
||||
<p>In Jingle, the exchange of early media is established through use of the "content-add" action. In order to match the usage specified in &rfc3959; and &rfc3960;, when adding a content definition for early media the value of the &CONTENT; element's 'disposition' attribute MUST be "early-session" for mapping to a SIP Content-Disposition header value of "early-session". This enables endpoints or intermediate gateways to apply the application server model described in <cite>RFC 3960</cite>.</p>
|
||||
<p>An entity that generates a content-add for early media SHOULD specify the same codecs for both session media and early media (however, it is possible that the entity that generates the early media does not generate the session media, for example in the case of an intermediate gateway or application server; in this case the entity MUST use one of the codecs advertised by the initiator).</p>
|
||||
<p>Upon receiving a content-add action specifying the use of early media, the initiator's client SHOULD acknowledge the content-add, complete any required transpor negotiation, and then send a content-accept (or content-reject) to the sender. When the responder subsequently sends a session-accept action, the acceptance MUST NOT be construed to include the content definition whose disposition is "early-session".</p>
|
||||
<p>Upon receiving a content-add action specifying the use of early media, the initiator's client SHOULD acknowledge the content-add, complete any required transport negotiation, and then send a content-accept (or content-reject) to the sender. When the responder subsequently sends a session-accept action, the acceptance MUST NOT be construed to include the content definition whose disposition is "early-session".</p>
|
||||
<p>In handling early media and deciding whether to generate local ringing or to play early media received from the responder or an intermediate gateway, the initiator's client SHOULD proceed as follows:</p>
|
||||
<ol>
|
||||
<li>If no ringing notification is received via a session-info event containing a <ringing/> condition, do not generate local ringing.</li>
|
||||
<li>If a ringing notification is received and no early media is received, generate local ringing.</li>
|
||||
<li>If a ringing notification is received but early media is received, play the early media and do not generate local media.</li>
|
||||
<li>Once the responder has accepted the session and the session (as opposed to early session) media has begun to flow, stop local ringing or stop playing early media.</li>
|
||||
<li>Once the responder has accepted the session and the session data (as opposed to early session data) has begun to flow, stop local ringing or stop playing early media.</li>
|
||||
</ol>
|
||||
<p>For examples of early media, see the <link url='#scenarios-earlymedia'>Jingle Audio via RTP with Early Media</link> section of this document.</p>
|
||||
</section1>
|
||||
|
|
@ -520,14 +521,63 @@ delivery-method=inline; configuration=somebase16string;
|
|||
tag='1'/>
|
||||
</encryption>
|
||||
]]></code>
|
||||
<p>The mapping of to SDP is as follows.</p>
|
||||
<p>The mapping of that data to SDP is as follows.</p>
|
||||
<code><![CDATA[
|
||||
a=crypto:1 AES_CM_128_HMAC_SHA1_80
|
||||
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:32
|
||||
session-params:KDR=1;UNENCRYPTED_SRTCP
|
||||
]]></code>
|
||||
<p>When the responder receives a session-initiate action containing an <encryption/> element, the responder MUST either (1) accept the offer by denoting one of the <crypto/> elements as acceptable (it does this by mirroring that <crypto/> element in its session acceptance) or (2) reject the offer by sending a session-terminate action with a Jingle reason of <security-error/> and an RTP-specific condition of <invalid-crypto/>.</p>
|
||||
<example caption="Responder terminates session because of invalid crypto"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='term1'
|
||||
to='romeo@montague.lit/orchard'
|
||||
type='set'>
|
||||
<jingle xmlns='urn:xmpp:jingle:0'
|
||||
action='session-terminate'
|
||||
initiator='romeo@montague.lit/orchard'
|
||||
sid='a73sjjvkla37jfea'>
|
||||
<reason>
|
||||
<security-error/>
|
||||
<invalid-crypto xmlns='urn:xmpp:jingle:apps:rtp:errors:0'/>
|
||||
</reason>
|
||||
</jingle>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If the responder requires encryption but the initiator did not include an <encryption/> element in its offer, the responder MUST reject the offer by sending a session-terminate action with a Jingle reason of <security-error/> and an RTP-specific condition of <crypto-required/>.</p>
|
||||
<example caption="Responder terminates session because crypto is required"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='term1'
|
||||
to='romeo@montague.lit/orchard'
|
||||
type='set'>
|
||||
<jingle xmlns='urn:xmpp:jingle:0'
|
||||
action='session-terminate'
|
||||
initiator='romeo@montague.lit/orchard'
|
||||
sid='a73sjjvkla37jfea'>
|
||||
<reason>
|
||||
<security-error/>
|
||||
<crypto-required xmlns='urn:xmpp:jingle:apps:rtp:errors:0'/>
|
||||
</reason>
|
||||
</jingle>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If the initiator requires encryption but the responder does not include an <encryption/> element in its session acceptance, the initiator MUST terminate the session with a Jingle reason of <security-error/> and an RTP-specific condition of <crypto-required/>.</p>
|
||||
<example caption="Initiator terminates session because crypto is required"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='term1'
|
||||
to='romeo@montague.lit/orchard'
|
||||
type='set'>
|
||||
<jingle xmlns='urn:xmpp:jingle:0'
|
||||
action='session-terminate'
|
||||
initiator='romeo@montague.lit/orchard'
|
||||
sid='a73sjjvkla37jfea'>
|
||||
<reason>
|
||||
<security-error/>
|
||||
<crypto-required xmlns='urn:xmpp:jingle:apps:rtp:errors:0'/>
|
||||
</reason>
|
||||
</jingle>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Informational Messages' anchor='info'>
|
||||
|
|
@ -540,7 +590,7 @@ delivery-method=inline; configuration=somebase16string;
|
|||
</tr>
|
||||
<tr>
|
||||
<td><active/></td>
|
||||
<td>The principal or device is again actively participating in the session after having been on hold or on mute. The <active/< element MAY possess a 'name' attribute whose value specifies a particular session that is again active (e.g., activating the video aspect but not the audio aspect of a voice+video chat). If no 'name' attribute is included, the recipient MUST assume that all sessions are active.</td>
|
||||
<td>The principal or device is again actively participating in the session after having been on hold or on mute. The <active/> element MAY possess a 'name' attribute whose value specifies a particular session that is again active (e.g., activating the video aspect but not the audio aspect of a voice+video chat). If no 'name' attribute is included, the recipient MUST assume that all sessions are active.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><hold/></td>
|
||||
|
|
@ -548,7 +598,7 @@ delivery-method=inline; configuration=somebase16string;
|
|||
</tr>
|
||||
<tr>
|
||||
<td><mute/></td>
|
||||
<td>The principal is temporarily stopping media output but continues to accept media input. The <mute/< element MAY possess a 'name' attribute whose value specifies a particular session to be muted (e.g., muting the audio aspect but not the video aspect of a voice+video chat). If no 'name' attribute is included, the recipient MUST assume that all sessions are to be muted.</td>
|
||||
<td>The principal is temporarily stopping media output but continues to accept media input. The <mute/> element MAY possess a 'name' attribute whose value specifies a particular session to be muted (e.g., muting the audio aspect but not the video aspect of a voice+video chat). If no 'name' attribute is included, the recipient MUST assume that all sessions are to be muted.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><ringing/></td>
|
||||
|
|
@ -656,10 +706,8 @@ delivery-method=inline; configuration=somebase16string;
|
|||
to='romeo@montague.lit/orchard'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:jingle:0'/>
|
||||
<feature var='urn:xmpp:jingle:apps:rtp:0'/>
|
||||
...
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
|
@ -716,7 +764,7 @@ Romeo Juliet
|
|||
]]></example>
|
||||
<example caption="Responder acknowledges session-initiate"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='accept1'
|
||||
id='jingle1'
|
||||
to='romeo@montague.lit/orchard'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
|
|
@ -820,7 +868,7 @@ Romeo Juliet
|
|||
]]></example>
|
||||
<example caption="Responder acknowledges session-initiate"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='accept1'
|
||||
id='jingle1'
|
||||
to='romeo@montague.lit/orchard'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
|
|
@ -887,7 +935,7 @@ Romeo Juliet
|
|||
to='juliet@capulet.lit/balcony'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
<p>The parties now begin to exchange media. In this case they would exchange audio using the Speex codec at a clockrate of 8000 since that is the highest-priority codec for the responder (as determined by the XML order of the &PAYLOADTYPE; children).</p>
|
||||
<p>The parties now begin to exchange media. In this case they would use RTP to exchange audio using the Speex codec at a clockrate of 8000 since that is the highest-priority codec for the responder (as determined by the XML order of the &PAYLOADTYPE; children).</p>
|
||||
<p>The parties can continue the session as long as desired.</p>
|
||||
<p>Eventually, one of the parties terminates the session.</p>
|
||||
<example caption="Responder terminates the session"><![CDATA[
|
||||
|
|
@ -977,31 +1025,15 @@ Romeo Juliet
|
|||
</jingle>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>To signal that the initiator wishes to use SRTP, the initiator's client includes keying material via the <encryption/> element (with one set of keying material per <crypto/> element). Here the initiator signals that encryption is mandatory via the 'required' attribute.</p>
|
||||
<p>To signal that the initiator wishes to use SRTP, the initiator's client includes keying material via the <encryption/> element (with one set of keying material per <crypto/> element). Here the initiator also signals that encryption is mandatory via the 'required' attribute.</p>
|
||||
<p>The responder immediately acknowledges the session initiation request.</p>
|
||||
<example caption="Responder acknowledges session-initiate"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='accept1'
|
||||
id='jingle1'
|
||||
to='romeo@montague.lit/orchard'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
<p>If the keying material is acceptable, the responder's continues with the negotiation. If the keying material is not acceptable, the responder's client terminates the session (and can do so at any time).</p>
|
||||
<example caption="Responder acknowledges session-initiate"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='term1'
|
||||
to='romeo@montague.lit/orchard'
|
||||
type='set'>
|
||||
<jingle xmlns='urn:xmpp:jingle:0'
|
||||
action='session-terminate'
|
||||
initiator='romeo@montague.lit/orchard'
|
||||
sid='a73sjjvkla37jfea'>
|
||||
<reason>
|
||||
<general-error/>
|
||||
<invalid-crypto xmlns='urn:xmpp:jingle:apps:rtp:errors:0'/>
|
||||
</reason>
|
||||
</jingle>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If the keying material is acceptable, the responder's continues with the negotiation. If the keying material is not acceptable, the responder's client terminates the session as described under <link url='#srtp'>Negotiation of SRTP</link>.</p>
|
||||
<example caption="Responder sends ringing message"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='ringing1'
|
||||
|
|
@ -1072,7 +1104,7 @@ Romeo Juliet
|
|||
to='juliet@capulet.lit/balcony'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
<p>The parties now begin to exchange media. In this case they would exchange audio using the Speex codec at a clockrate of 8000 since that is the highest-priority codec for the responder (as determined by the XML order of the &PAYLOADTYPE; children).</p>
|
||||
<p>The parties now begin to exchange media. In this case they would use SRTP to exchange audio using the Speex codec at a clockrate of 8000 since that is the highest-priority codec for the responder (as determined by the XML order of the &PAYLOADTYPE; children).</p>
|
||||
<p>The parties can continue the session as long as desired.</p>
|
||||
<p>Eventually, one of the parties terminates the session.</p>
|
||||
<example caption="Responder terminates the session"><![CDATA[
|
||||
|
|
@ -1167,7 +1199,7 @@ Romeo Gateway Juliet
|
|||
]]></example>
|
||||
<example caption="Responder acknowledges session-initiate"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='accept1'
|
||||
id='jingle1'
|
||||
to='romeo@montague.lit/orchard'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
|
|
@ -1188,7 +1220,7 @@ Romeo Gateway Juliet
|
|||
<description xmlns='urn:xmpp:jingle:apps:rtp:0' media='audio'>
|
||||
<payload-type id='18' name='G729'/>
|
||||
</description>
|
||||
<transport xmlns='urn:xmpp:jingle:transports:raw-udp:0'>
|
||||
<transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
|
||||
<candidate component='1'
|
||||
generation='0'
|
||||
id='a9j3mnbtu1'
|
||||
|
|
@ -1206,7 +1238,7 @@ Romeo Gateway Juliet
|
|||
to='juliet@capulet.lit/balcony'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
<p>Because the gateway (on behalf of the responder) specified a transport method of Raw UDP for the early session data, the initiator then would send a Raw UDP candidate to the gateway, inform the gateway that it is trying to send media to the candidate provided by the gateway, etc. See <cite>XEP-0177</cite> for details.</p>
|
||||
<p>Because the gateway (on behalf of the responder) specified a transport method of Raw UDP for the early session data, the initiator then would send a Raw UDP candidate to the gateway (see <cite>XEP-0177</cite> for details).</p>
|
||||
<p>Eventually the initiator would send a content-accept to the gateway.</p>
|
||||
<example caption="Initiator accepts new content definition"><![CDATA[
|
||||
<iq from='romeo@montague.lit/orchard'
|
||||
|
|
@ -1224,7 +1256,7 @@ Romeo Gateway Juliet
|
|||
<description xmlns='urn:xmpp:jingle:apps:rtp:0' media='audio'>
|
||||
<payload-type id='18' name='G729'/>
|
||||
</description>
|
||||
<transport xmlns='urn:xmpp:jingle:transports:raw-udp:0'>
|
||||
<transport xmlns='urn:xmpp:jingle:transports:raw-udp:1'>
|
||||
<candidate component='1'
|
||||
generation='0'
|
||||
id='a9j3mnbtu1'
|
||||
|
|
@ -1246,7 +1278,7 @@ Romeo Gateway Juliet
|
|||
<p>Eventually, the responder sends a session-accept.</p>
|
||||
<example caption="Responder sends session-accept"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='accept1'
|
||||
id='accept2'
|
||||
to='romeo@montague.lit/orchard'
|
||||
type='set'>
|
||||
<jingle xmlns='urn:xmpp:jingle:0'
|
||||
|
|
@ -1282,7 +1314,7 @@ Romeo Gateway Juliet
|
|||
]]></example>
|
||||
<example caption="Initiator acknowledges session-accept"><![CDATA[
|
||||
<iq from='romeo@montague.lit/orchard'
|
||||
id='accept1'
|
||||
id='accept2'
|
||||
to='juliet@capulet.lit/balcony'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
|
|
@ -1496,7 +1528,7 @@ Romeo Juliet
|
|||
to='juliet@capulet.lit/balcony'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
<p>The parties now begin to exchange media. In this case they would exchange audio using the Speex codec at a clockrate of 8000 since that is the highest-priority codec for the responder (as determined by the XML order of the &PAYLOADTYPE; children).</p>
|
||||
<p>The parties now begin to exchange media. In this case they would use RTP to exchange audio using the Speex codec at a clockrate of 8000 since that is the highest-priority codec for the responder (as determined by the XML order of the &PAYLOADTYPE; children).</p>
|
||||
<p>The parties chat for a while. Eventually Juliet wants to get her hair in order so she puts Romeo on hold.</p>
|
||||
<example caption="Responder sends hold message"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
|
|
@ -1634,6 +1666,10 @@ Romeo Juliet
|
|||
</iq>
|
||||
]]></example>
|
||||
<example caption="Responder acknowledges description-info"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
id='desc1'
|
||||
to='romeo@montague.lit/orchard'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
<p>Eventually, one of the parties terminates the session.</p>
|
||||
<example caption="Initiator sends session-terminate"><![CDATA[
|
||||
|
|
@ -1675,7 +1711,7 @@ Romeo Juliet
|
|||
<p>XMPP applications that use Jingle RTP sessions for voice chat MUST support and prefer native RTP methods of communicating DTMF information, in particular the "audio/telephone-event" and "audio/tone" media types. It is NOT RECOMMENDED to use the protocol described in &xep0181; for communicating DTMF information with RTP-aware endpoints.</p>
|
||||
</section3>
|
||||
<section3 topic='When to Listen for Audio' anchor='impl-audio-listen'>
|
||||
<p>When the Jingle RTP content type is accepted via a session-accept action, both initiator and responder SHOULD start listening for audio as defined by the negotiated transport method and audio application format. For interoperability with telephony systems, after the responder acknowledges the session initiation request, the responder SHOULD send a "ringing" message and both parties SHOULD play any audio received.</p>
|
||||
<p>When the Jingle RTP content type is accepted via a session-accept action, both initiator and responder SHOULD start listening for audio as defined by the negotiated transport method and audio application format. For interoperability with telephony systems, after the responder acknowledges the session initiation request, the responder SHOULD send a "ringing" message and both parties SHOULD play any audio received. For more detailed suggestions in the context of early media, see under <link url='#earlymedia'>Early Media</link>.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Video Sessions' anchor='impl-video'>
|
||||
|
|
@ -1686,7 +1722,7 @@ Romeo Juliet
|
|||
</section1>
|
||||
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged. Such encryption methods are out of scope for this specification.</p>
|
||||
<p>In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the RTP data transport; the use of SRTP is recommended.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
|
|
@ -1704,7 +1740,7 @@ Romeo Juliet
|
|||
<p>Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
|
||||
</section2>
|
||||
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
|
||||
<p>If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, 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 <cite>XEP-0053</cite>.</p>
|
||||
&NSVER;
|
||||
</section2>
|
||||
<section2 topic='Service Discovery Features' anchor='registrar-features'>
|
||||
<p>For each RTP media type that an entity supports, it MUST advertise support for the "urn:xmpp:jingle:apps:rtp:[media]" feature, where the string "[media]" is replaced by the appropriate media type such as "audio" or "video".</p>
|
||||
|
|
@ -1805,12 +1841,12 @@ Romeo Juliet
|
|||
minOccurs='0'
|
||||
maxOccurs='unbounded'/>
|
||||
</xs:sequence>
|
||||
<xs:attribute name='channels' type='xs:byte' use='optional' default='1'/>
|
||||
<xs:attribute name='clockrate' type='xs:short' use='optional'/>
|
||||
<xs:attribute name='channels' type='xs:unsignedByte' use='optional' default='1'/>
|
||||
<xs:attribute name='clockrate' type='xs:unsignedInt' use='optional'/>
|
||||
<xs:attribute name='id' type='xs:unsignedByte' use='required'/>
|
||||
<xs:attribute name='maxptime' type='xs:short' use='optional'/>
|
||||
<xs:attribute name='maxptime' type='xs:unsignedInt' use='optional'/>
|
||||
<xs:attribute name='name' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='ptime' type='xs:short' use='optional'/>
|
||||
<xs:attribute name='ptime' type='xs:unsignedInt' use='optional'/>
|
||||
</xs:complexType>
|
||||
|
||||
<xs:complexType name='parameterElementType'>
|
||||
|
|
@ -1841,6 +1877,8 @@ Romeo Juliet
|
|||
xmlns='urn:xmpp:jingle:apps:rtp:errors:0'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:element name='crypto-required' type='empty'/>
|
||||
|
||||
<xs:element name='invalid-crypto' type='empty'/>
|
||||
|
||||
<xs:simpleType name='empty'>
|
||||
|
|
|
|||
Loading…
Reference in New Issue