The <reason/> element MUST contain a <condition/> element that provides machine-readable information about the reason for the action.
The <reason/> element MAY contain a <sid/> element that specifies a Jingle SessionID (e.g., to point to an alternative session).
The <reason/> element MAY contain a <text/> element that provides human-readable information about the reason for the action.
-
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.
+
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.
The defined conditions are described in the folloiwing table.
Until this specification advances to a status of Draft, its associated namespaces shall be:
urn:xmpp:tmp:jingle
-
urn:xmpp:tmp:jingle-errors
+
urn:xmpp:tmp:jingle:errors
Upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.
The following namespaces are requested, and are thought to be unique per the XMPP Registrar's requirements:
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
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. 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 XEP-0166. This document specifies only negotiation of the ICE transport method.
-
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.
+
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.
The candidate syntax and negotiation flow are described below.
The following is an example of the candidate format:
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.
+
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.
When it attempts to send data to a Raw UDP candidate, a party SHOULD send an informational message of <trying/>.
@@ -280,7 +280,7 @@
-
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 XEP-0167 and XEP-0180).
+
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 XEP-0167 and XEP-0180).
The application format negotiation process is defined in the Negotiating a Jingle Video Session section of this document.
The semantics of the &DESCRIPTION; element are defined in the Application Format section of this document.
A mapping of Jingle semantics to the Session Description Protocol is provided in the Mapping to Session Description Protocol section of this document.
-
A Jingle video session MUST use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;.
+
A Jingle video session SHOULD use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;.
Content is to be sent and received as follows:
diff --git a/xep-0181.xml b/xep-0181.xml
index 5a0ac051..2f19b581 100644
--- a/xep-0181.xml
+++ b/xep-0181.xml
@@ -10,7 +10,7 @@
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.
&LEGALNOTICE;
0181
- Experimental
+ ProposedStandards TrackStandardsCouncil
@@ -79,7 +79,7 @@
The format for the XML DTMF representation is as follows &NSNOTE;:
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;.
-
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:
+
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:
If an entity supports Jingle DTMF (which natively includes sending of DTMF in the XMPP signalling channel), it MUST return a &xep0030; feature of "http://www.xmpp.org/extensions/xep-0181.html#ns" in response to service discovery information requests.
+
If an entity supports Jingle DTMF (which natively includes sending of DTMF in the XMPP signalling channel), it MUST return a &xep0030; feature of "urn:xmpp:tmp:jingle:dtmf" in response to service discovery information requests.
If an entity also supports sending of DTMF in the content channel, it MUST also return a service discovery feature of "urn:xmpp:jingle:dtmf:rtp" in response to service discovery information requests.
Naturally, support MAY also be determined via the dynamic, presence-based profile of Service Discovery defined in &xep0115;.
@@ -177,8 +177,8 @@
Until this specification advances to a status of Draft, its associated namespaces shall be:
Upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.
The following namespaces are requested, and are thought to be unique per the XMPP Registrar's requirements: