From e3afb38a386ae7eaa24d4297aab52540f86f51d2 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 20 Mar 2009 22:06:07 +0000 Subject: [PATCH] 0.29 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2912 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0167.xml | 214 ++++++++++++--------------------------------------- 1 file changed, 48 insertions(+), 166 deletions(-) diff --git a/xep-0167.xml b/xep-0167.xml index a4af216a..ce01a676 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -28,6 +28,12 @@ &seanegan; &robmcqueen; &diana; + + 0.29 + 2009-03-20 + psa +

Simplified session flow for audio/video scenario; clarified handling of hold messages.

 + 0.28 2009-03-11 @@ -630,33 +636,10 @@ delivery-method=inline; configuration=somebase16string; - -

Informational messages can be sent by either party within the context of Jingle to communicate the status of a Jingle RTP session, device, or principal. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info", where the informational message is a payload element qualified by the 'urn:xmpp:jingle:apps:rtp:info:1' namespace; the following payload elements are defined: A <trying/> element (equivalent to the SIP 100 Trying response code) is not necessary, since each session-level message is acknowledged via XMPP IQ semantics.

- - - - - - - - - - - - - - - - - - - - - -
ElementMeaning
<active/>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.
<hold/>The principal is temporarily pausing the chat (i.e., putting the other party on hold). This message is purely informational; to ensure that no media will be exchanged, it is necessary to change the value of the 'senders' attribute to "none" via a content-modify message.
<mute/>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.
<ringing/>The device is ringing but the principal has not yet interacted with it to answer (this maps to the SIP 180 response code).
-

Note: Because the informational message is sent in an IQ-set, the receiving party MUST return either an IQ-result or an IQ-error (normally only an IQ-result to acknowledge receipt; no error flows are defined or envisioned at this time).

- - +

Informational messages can be sent by either party within the context of Jingle to communicate the status of a Jingle RTP session, device, or principal. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info", where the informational message is a payload element qualified by the 'urn:xmpp:jingle:apps:rtp:info:1' namespace. The following payload elements are defined. A <trying/> element (equivalent to the SIP 100 Trying response code) is not necessary, since each session-level message is acknowledged via XMPP IQ semantics.

+

Note: Because an informational message is sent in an IQ-set, the receiving party MUST return either an IQ-result or an IQ-error (normally an IQ-result simply to acknowledge receipt).

+ +

The <active/> payload indicates that the principal or device is again actively participating in the session after having been on mute or having put the other party on hold. 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.

]]> + + +

The <hold/> payload indicates that the principal is temporarily pausing the chat (i.e., putting the other party on hold). It is RECOMMENDED for the parties to handle informational <hold/> messages as follows (where the holdee is the party that receives the hold message and the holder is the party that sends the hold message):

+
    +
  • The holdee SHOULD stop sending media.
    • +
  • The holdee MUST keep accepting media (this ensures that the holder can immediately start sending media again when switching back from hold to active, or can send hold music or other media).
    • +
  • The holder MAY continue to send media (e.g. hold music).
    • +
  • The holder MAY silently drop all media that it receives from the holdee.
    • +
]]> + + +

The <mute/> payload indicates that 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.

]]> + + +

The <ringing/> payload indicates that the device is ringing but the principal has not yet interacted with it to answer (this maps to the SIP 180 response code).

-

In this scenario, Romeo initiates an audio chat with Juliet using a transport method of ICE-UDP. Romeo wants to add video but Juliet refuses; later she offers to add video, which Romeo accepts. The parties also exchange various informational messages

+

In this scenario, Romeo initiates an audio chat with Juliet using a transport method of ICE-UDP. After the chat is active, Romeo adds video. The parties also exchange various informational messages

The session flow is as follows (some of these messages are sent in parallel):

| | ack | |<----------------------------| - | content-reject for video | + | content-accept for video | |<----------------------------| | ack | |---------------------------->| @@ -1525,28 +1523,10 @@ Romeo Juliet |<----------------------------| | ack | |---------------------------->| - | content-modify for audio | - | (senders="none") | - |<----------------------------| - | ack | - |---------------------------->| | session-info (active) | |<----------------------------| | ack | |---------------------------->| - | content-modify for audio | - | (senders="both") | - |<----------------------------| - | ack | - |---------------------------->| - | content-add for video | - |<----------------------------| - | ack | - |---------------------------->| - | content-accept for video | - |---------------------------->| - | ack | - |---------------------------->| | AUDIO + VIDEO (RTP) | |<===========================>| | session-terminate | @@ -1704,28 +1684,32 @@ Romeo Juliet to='romeo@montague.lit/orchard' type='result'/> ]]> -

However, Juliet doesn't want to do video because she is having a bad hair day, so she sends a content-reject message to Romeo.

- However, Juliet is having a bad hair day, so she sends a content-accept message to Romeo but puts him on hold while she gets her hair in order.

+ - + + + + + + + + + + 128 + + + ]]> -

Romeo then acknowledges the content-reject message.

- - ]]> -

Juliet wants to get her hair in order, so she puts Romeo on hold while she will be away from her device for a while.

]]> - Romeo then acknowledges the content-accept and session-info messages.

+ ]]> -

To ensure that the session is truly paused, Juliet's client sends a content-modify message, setting the 'senders' attribute to "none".

- - - - - - ]]> - ]]> @@ -1785,95 +1756,6 @@ Romeo Juliet to='juliet@capulet.lit/balcony' type='result'/> ]]> -

Juliet's client also resumes the voice chat by setting the 'senders' attribute back to a value of "both".

- - - - - - ]]> - - ]]> -

The parties now continue the voice chat.

-

Finally Juliet decides that she is presentable for a video chat so she sends a content-add request to Romeo.

- - - - - - - - - - - - - - 128 - - - - - - ]]> -

The entity receiving the content-add request then acknowledges the request and, if it is acceptable, returns a content-accept action:

- - ]]> - - - - - - - - - - - - - 128 - - - - - - ]]> -

Juliet then acknowledges the acceptance.

- - ]]>

The media session proceeds. Now they would exchange both audio and video, where the audio is exchanged via the Speex codec at a clockrate of 8000 and the video is exchanged using the Theora codec with a height of 600 pixels, a width of 800 pixels, a bandwidth limit of 128,000 kilobits per second, etc.

The parties can continue the session as long as desired.

Other events might occur throughout the life of the session. For example, one of the parties might want to tweak the video parameters using a description-info action.