Added scenarios containing more examples.
Added scenarios for various session flows; clarified handling of content-add, content-modify, and content-remove actions; clarified rules for codec priority.
If the foregoing payload types and transport candidates can be successfully used, then the parties would begin to exchange media (in this case audio).
-The parties may continue the session as long as desired. Either party may terminate the session.
+If the foregoing payload types and transport candidates can be successfully used, then the parties would 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).
+The parties may continue the session as long as desired.
+Eventually, one of the parties terminates the session.
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.
-In this scenario, Romeo initiates a voice chat with Juliet using a transport method of ICE-UDP.
The session flow is as follows:
-
+
@@ -625,7 +626,7 @@ Romeo Juliet
action='transport-info'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
-
+
-
+
-
+
-
+
@@ -732,12 +733,14 @@ Romeo Juliet
]]>
- If the payload types and transport candidate can be successfully used by both parties, then the initiator acknowledges the session-accept and the parties begin to exchange media (in this case audio).
+ If the payload types and transport candidate can be successfully used by both parties, then the initiator acknowledges the session-accept.
]]>
- The parties may continue the session as long as desired. Either party may terminate the session.
- 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).
+ The parties may continue the session as long as desired.
+ Eventually, one of the parties terminates the session.
+
]]>
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 session flow is as follows:
-
+
@@ -817,7 +820,7 @@ Romeo Juliet
-
+
@@ -837,13 +840,13 @@ 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.
-
-
+
]]>
@@ -857,7 +860,7 @@ Romeo Juliet
action='content-accept'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
-
+
@@ -877,7 +880,7 @@ Romeo Juliet
initiator='romeo@montague.lit/orchard'
responder='juliet@capulet.lit/balcony'
sid='a73sjjvkla37jfea'>
-
+
@@ -894,10 +897,11 @@ Romeo Juliet
]]>
- As above, if the payload types and transport candidate can be successfully used by both parties, then the initiator acknowledges the session-accept and the parties begin to exchange media (in this case audio).
+ As above, if the payload types and transport candidate can be successfully used by both parties, then the initiator acknowledges the session-accept.
]]>
+ 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.
@@ -905,7 +909,7 @@ Romeo Juliet
action='content-add'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
-
+
@@ -930,9 +934,15 @@ Romeo Juliet
action='content-accept'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
-
+
- ...
+
+
+
+
+
+
+
@@ -943,7 +953,8 @@ Romeo Juliet
]]>
- The media session proceeds, this time with both audio and video.
+ The media session proceeds. Now they would exchange both audio and video, where the audio is exchanged the Speex codec at a clockrate of 8000 and the video is exchanged using the Theora codec with a height of 720 pixels, a width of 1280 pixels, and so on.
+ The parties may continue the session as long as desired.
Eventually, one of the parties terminates the session.
]]>
In this scenario, Romeo initiates a voice chat with Juliet using a transport method of ICE-UDP and an unencrypted profile of "RTP/AVP", but Juliet wants to chat securely so she requests the use of a secure transport as specified in &sdpdtls; (via a profile of "UDP/TLS/RTP/AVP").
+The session flow is as follows:
+|
+ | ack |
+ |<----------------------------|
+ | content-modify |
+ |<----------------------------|
+ | ack |
+ |---------------------------->|
+ | content-accept |
+ |---------------------------->|
+ | ack |
+ |<----------------------------|
+ | transport-info (X times) |
+ | (with acks) |
+ |<--------------------------->|
+ | session-accept |
+ |<----------------------------|
+ | ack |
+ |---------------------------->|
+ | AUDIO (RTP) |
+ |<===========================>|
+ | session-terminate |
+ |<----------------------------|
+ | ack |
+ |---------------------------->|
+ | |
+ ]]>
+ The protocol flow is as follows.
+However, Juliet wants to make sure that the communications are encrypted, so she sends a "content-modify" request to Romeo.
+Romeo then acknowledges the content-modify request and, if it is acceptable, returns a content-accept:
+The other party then acknowledges the acceptance.
+As in Scenario #1, the parties exchange ICE candidates (see above for examples).
+If one of the candidate transports is found to work, the receiver accepts the session.
+If the payload types and transport candidate can be successfully used by both parties, then the initiator acknowledges the session-accept.
+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).
+The parties may continue the session as long as desired.
+Eventually, one of the parties terminates the session.
+The other party MUST then acknowledge termination of the session:
+