Added scenario for handling of busy state, including Jingle-specific error code and modified error flow (no longer an instance of decline).
Separated methoddescription formats from signalling protocol.
Separated method description formats from signalling protocol.
Naturally, more complex scenarios are possible (indeed, likely).
+Naturally, more complex scenarios are possible; see the Scenarios section of this document for details.
The simplest flow might happens as follows. The example is that of a voice chat (see XEP-0167) initiated by Romeo, where the transport is &xep0177;.
Procedures for mapping the Jingle signalling protocol to existing signalling standards such as the IETF's Session Initiation Protocol (SIP) and the ITU's H.323 protocol (see &h323;); these documents are forthcoming.
| Term | @@ -344,6 +351,14 @@ Romeo JulietA component is a numbered stream of data which needs to be transmitted between the endpoints for a given content type in the context of a given session. It is up to the transport to negotiate the details of each component. Depending on the content type and the content description, one content description may require multiple components to be communicated (e.g., the audio content type might use two components: one to transmit an RTP stream and another to transmit RTCP timing information). |
|---|
In diagrams, the following conventions are used:
+Jingle consists of three parts, each with its own syntax, semantics, and state machine:
@@ -473,6 +488,7 @@ PENDING o---------------------+ |If the receiver is busy, it SHOULD return a &recipient; error along with a Jingle-specific error condition of <busy/>.
+If the receiver does not support any of the specified content description formats, it MUST return a &feature; error with a Jingle-specific error condition of <unsupported-content/>.
@@ -565,9 +590,52 @@ PENDING o---------------------+ |The very simple scenario described in the How It Works section of this document is just that: very simple. Typically, the session flow is more complex. The following sections show some more complex scenarios, in order of complexity.
+The very simple scenario described in the How It Works section of this document is just that: very simple. Typically, the session flow is more complex. The following sections show some more complex scenarios, in relative order of complexity.
+In this scenario, Romeo initiates a voice chat with Juliet but she is otherwise engaged.
+The session flow is as follows:
+|
+ | error |
+ | (recipient-unavailable) |
+ ]]>
+ The protocol flow is as follows.
+In this scenario, Romeo initiates a voice chat with Juliet using a transport method of ICE-UDP.
+In this scenario, Romeo initiates a voice chat with Juliet using a transport method of ICE-UDP, and the parties exchange informational messages.
The session flow is as follows:
|
| ack |
|<----------------------------|
+ | session-info (ringing) |
+ |<----------------------------|
+ | ack |
+ |---------------------------->|
| transport-info (X times) |
| (with acks) |
|<--------------------------->|
@@ -617,6 +689,25 @@ Romeo Juliet
to='romeo@montague.lit/orchard'
type='result'/>
]]>
+
+
+
+
+ ]]>
+
+ ]]>
In this scenario, Romeo initiates a combined audio and video chat with Juliet using a transport method of ICE. Juliet at first refuses the video portion, then later offers to add video, which Romeo accepts.
+In this scenario, Romeo initiates a combined audio and video chat with Juliet using a transport method of ICE. Juliet at first refuses the video portion, then later offers to add video, which Romeo accepts. The parties also exchange various informational messages
The session flow is as follows:
|
| ack |
|<----------------------------|
+ | session-info (ringing) |
+ |<----------------------------|
+ | ack |
+ |---------------------------->|
| content-remove |
|<----------------------------|
| ack |
@@ -787,6 +882,14 @@ Romeo Juliet
|---------------------------->|
| AUDIO (RTP) |
|<===========================>|
+ | session-info (hold) |
+ |<----------------------------|
+ | ack |
+ |---------------------------->|
+ | session-info (active) |
+ |<----------------------------|
+ | ack |
+ |---------------------------->|
| content-add |
|<----------------------------|
| ack |
@@ -838,6 +941,25 @@ Romeo Juliet
]]>
+ ]]>
+
+
+
+
+ ]]>
+
]]>
However, Juliet doesn't want to do video because she is having a bad hair day, so she sends a "content-remove" request to Romeo.
]]>
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).
- Once Juliet gets her hair in order, she decides that she is presentable for a video chat so she sends a content-add request to Romeo.
+ Juliet wants to get her hair in order so she puts Romeo on hold.
+
+
+
+
+ ]]>
+
+ ]]>
+ Juliet returns so she informs Romeo that she is actively engaged in the call again.
+
+
+
+
+ ]]>
+
+ ]]>
+ The parties now continue the audio chat.
+ Finally Juliet decides that she is presentable for a video chat so she sends a content-add request to Romeo.
|
| ack |
|<----------------------------|
+ | session-info (ringing) |
+ |<----------------------------|
+ | ack |
+ |---------------------------->|
| content-modify |
|<----------------------------|
| ack |
@@ -1034,6 +1201,25 @@ Romeo Juliet
to='romeo@montague.lit/orchard'
type='result'/>
]]>
+
+
+
+
+ ]]>
+
+ ]]>
However, Juliet wants to make sure that the communications are encrypted, so she sends a "content-modify" request to Romeo.
@@ -1200,6 +1386,11 @@ Romeo Juliet
XMPP Condition
Description
+
+ <busy/>
+ &recipient;
+ The session-initiate is declined because the recipient is online but unavailable to participate in a session (this maps to error code 486 in SIP).
+
<out-of-order/>
&unexpected;
@@ -1438,6 +1629,7 @@ Romeo Juliet
xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns-errors'
elementFormDefault='qualified'>
+