<li>The <reason/> element MUST contain a <condition/> element that provides machine-readable information about the reason for the action.</li>
<li>The <reason/> element MAY contain a <sid/> element that specifies a Jingle SessionID (e.g., to point to an alternative session).</li>
<li>The <reason/> element MAY contain a <text/> element that provides human-readable information about the reason for the action.</li>
<li>The <reason/> element MAY contain an element qualified by some other namespace that provides mroe detailed machine-readable information about the reason for the action.</li>
<li>The <reason/> element MAY contain an element qualified by some other namespace that provides more detailed machine-readable information about the reason for the action.</li>
</ul>
<p>The defined conditions are described in the folloiwing table.</p>
<tablecaption='Defined Children of Condition Element'>
<p>The Jingle-specific error conditions are as follows. These condition elements are qualified by the 'urn:xmpp:tmp:jingle-errors' namespace &NSNOTE;.</p>
<p>The Jingle-specific error conditions are as follows. These condition elements are qualified by the 'urn:xmpp:tmp:jingle:errors' namespace &NSNOTE;.</p>
<p>Until this specification advances to a status of Draft, its associated namespaces shall be:</p>
<ul>
<li>urn:xmpp:tmp:jingle</li>
<li>urn:xmpp:tmp:jingle-errors</li>
<li>urn:xmpp:tmp:jingle:errors</li>
</ul>
<p>Upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.</p>
<p>The following namespaces are requested, and are thought to be unique per the XMPP Registrar's requirements:</p>
<section2topic='Jingle Audio and Video via RTP/AVP, Negotiated with ICE-UDP'anchor='scenarios-voicechat'>
<section2topic='Jingle Audio and Video via RTP/AVP, Negotiated with ICE-UDP'anchor='scenarios-securechat'>
<p>In this scenario, Romeo initiates a combined audio and video chat with Juliet using a transport method of ICE-UDP. Juliet at first refuses the video portion, then later offers to add video, which Romeo accepts. The parties also exchange various informational messages</p>
<p>Once the responder acknowledges receipt of the session initiation request as shown above, both initiator and responder MUST immediately negotiate connectivity over the ICE transport by exchanging XML-formatted candidate transports for the channel. This negotiation proceeds immediately in order to maximize the possibility that media can be exchanged as quickly as possible. <note>Concurrent with negotiation of the ICE candidates, it is possible for the initiator and responder to negotiate which content types the session will include, which transport methods will be tried for each content type, etc. Those negotiation flows are shown in other specifications, such as <cite>XEP-0166</cite>. This document specifies only negotiation of the ICE transport method.</note></p>
<p>Note: In order to expedite session establishment, the initiator MAY send transport candidates immediately after sending the "session-initiate" message and before receiving acknowledgement from the responder (i.e., the initiator MUST consider the session to be live even before receiving acknowledgement). Given in-order delivery, the responder should receive such "transport-info" messages after receiving the "session-initiate" message; if not, it is appropriate for the responder to return <unknown-session/> errors since it according to its state machine the session does not exist. If either party receives an <unknown-session/> from the other party, it MUST terminate the negotiation and the session.</p>
<p>Note: In order to expedite session establishment, the initiator MAY send transport candidates immediately after sending the "session-initiate" message and before receiving acknowledgement from the responder (i.e., the initiator MUST consider the session to be live even before receiving acknowledgement). Given in-order delivery, the responder should receive such "transport-info" messages after receiving the "session-initiate" message; if not, it is appropriate for the responder to return <unknown-session/> errors since according to its state machine the session does not exist. If either party receives an <unknown-session/> from the other party, it MUST terminate the negotiation and the session.</p>
<p>The candidate syntax and negotiation flow are described below.</p>
<section3topic='Syntax of Candidate Element'anchor='protocol-candidates-syntax'>
<p>The following is an example of the candidate format:</p>
<p>Naturally, the initiator SHOULD also attempt to send media to the responder as specified above. This media too may or may not get through, but if it does then the other party SHOULD acknowledge receipt.</p>
<p>Naturally, the initiator SHOULD also attempt to send media to the responder as specified above. This media, too, may or may not get through, but if it does then the other party SHOULD acknowledge receipt.</p>
</section3>
<section3topic='Sending An Informational Message'anchor='response-info'>
<p>When it attempts to send data to a Raw UDP candidate, a party SHOULD send an informational message of <trying/>.</p>
<p>In order to secure the data stream that is negotiated via the Jingle ICE transport, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged (for details regarding audio and video exchanges via RTP, refer to <cite>XEP-0167</cite> and <cite>XEP-0180</cite>).</p>
<p>In order to secure the data stream that is negotiated via the Jingle ICE-UDP transport, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged (for details regarding audio and video exchanges via RTP, refer to <cite>XEP-0167</cite> and <cite>XEP-0180</cite>).</p>
<li><p>The application format negotiation process is defined in the <linkurl='#negotiation'>Negotiating a Jingle Video Session</link> section of this document.</p></li>
<li><p>The semantics of the &DESCRIPTION; element are defined in the <linkurl='#format'>Application Format</link> section of this document.</p></li>
<li><p>A mapping of Jingle semantics to the Session Description Protocol is provided in the <linkurl='#sdp'>Mapping to Session Description Protocol</link> section of this document.</p></li>
<li><p>A Jingle video session MUST use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;.</p></li>
<li><p>A Jingle video session SHOULD use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;.</p></li>
<li>
<p>Content is to be sent and received as follows:</p>
<abstract>This specification defines an XML format for encapsulating Dual Tone Multi-Frequency (DTMF) data in informational messages sent within the context of Jingle audio sessions, e.g. to be used in the context of Interactive Voice Response (IVR) systems.</abstract>
&LEGALNOTICE;
<number>0181</number>
<status>Experimental</status>
<status>Proposed</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@ -79,7 +79,7 @@
<section1topic='Tone Format'anchor='format'>
<p>The format for the XML DTMF representation is as follows &NSNOTE;:</p>
<section1topic='Negotiating Use of the RFC 4733 Format'anchor='rfc4733'>
<p>Some applications may want to stream Jingle voice RTP directly to a non-XMPP entity, such as a SIP phone (see &rfc3261;). In this scenario, DTMF needs to be sent in the content channel. Jingle DTMF enables Jingle entities to negotiate whether to send RTP over the XMPP signalling channel as described above, or over the content channel using &rfc4733;.</p>
<p>To request that the voice session will switch to use of the RFC 4733 format for communicating DTMF, a client sends a <dtmf-method/> element, qualified by the 'http://www.xmpp.org/extensions/xep-0181.html#ns' namespace as the payload of a Jingle session-info message:</p>
<p>To request that the voice session will switch to use of the RFC 4733 format for communicating DTMF, a client sends a <dtmf-method/> element, qualified by the 'urn:xmpp:tmp:jingle:dtmf' namespace as the payload of a Jingle session-info message:</p>
<examplecaption="Client Requests Use of RFC 4733"><
Peter Saint-Andre
15 years ago