From c74e0b398746e7b25c0d1b435e217adfa940d6f9 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Thu, 25 Sep 2008 16:22:09 +0000 Subject: [PATCH] 0.24 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2262 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0167.xml | 261 +++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 223 insertions(+), 38 deletions(-) diff --git a/xep-0167.xml b/xep-0167.xml index 7a54464a..963d5770 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -28,14 +28,14 @@ &diana; 0.24 - 2008-09-24 + 2008-09-25 psa/dc
    -
  • Defined handling of early media.
    • +
  • Defined handling of early media, including mappings to RFC 3959 and RFC 3960 using the newly-defined 'disposition' attribute for the <content/> element in XEP-0166.
  • Clarified handling of SRTP negotiation.
    • -
  • Defined invalid-crypto error condition.
    • -
  • Changed DTMF text to prefer native RTP methods and not recommend sending of DTMF in the XMPP signalling channel.
    • +
  • More fully specified invalid-crypto error condition.
    • +
  • Changed DTMF text to prefer native RTP methods and not recommend sending of DTMF in the XMPP signalling channel, per XEP-0181.
  • Modified namespaces to incorporate namespace versioning.
  • Cleaned up XML schemas.
@@ -470,39 +470,18 @@ delivery-method=inline; configuration=somebase16string; -

The term "early media" refers to media that is exchanged before a responder has definitively accepted a session request generated by an initiator. Early media is typically used to send ringing tones and announcements, either via audio streams or Dual Tone Multi-Frequency (DTMF) events.

-

In Jingle, the exchange of early media is established through use of the "content-add" action. The session flow is as follows.

- | - | ack | - |<----------------------------| - | session-info (ringing) | - |<----------------------------| - | ack | - |---------------------------->| - | content-add | - | (early media) | - |<----------------------------| - | ack | - |---------------------------->| - | EARLY MEDIA (RTP) | - |<===========================>| - | session-accept | - |<----------------------------| - | ack | - |---------------------------->| - | AUDIO (RTP) | - |<===========================>| - | session-terminate | - |<----------------------------| - | ack | - |---------------------------->| - | | - ]]> +

The term "early media" refers to media that is exchanged before a responder has definitively accepted a session request generated by an initiator. Early media is typically used to send ringing tones and announcements, using either audio streams or Dual Tone Multi-Frequency (DTMF) events.

+

In Jingle, the exchange of early media is established through use of the "content-add" action. In order to match the usage specified in &rfc3959; and &rfc3960;, when adding a content definition for early media the value of the &CONTENT; element's 'disposition' attribute MUST be "early-session" for mapping to a SIP Content-Disposition header value of "early-session" (if necessary). This enables endpoints or intermediate gateways to apply the application server model described in RFC3960.

+

An entity that generates a content-add for early media SHOULD specify the same codecs for both session media and early media (however, it is possible that the entity generating early media does not generate session media, for example in the case of an intermediate gateway or application server; in this case the entity MUST use one of the codecs advertised by the initiator).

+

Upon receiving a content-add action specifying the use of early media, the initiator's client SHOULD acknowledge the content-add and then send a content-accept to the sender. When the responder subsequently sends a session-accept action, the acceptance MUST NOT be construued to include the content definition whose disposition is "early-session".

+

In handling early media and deciding whether to generate local ringing or play early media received from the responder or an intermediate gateway, the initiator's client SHOULD proceed as follows:

+
    +
  1. If no ringing notification is received via a session-info event containing a <ringing/> condition, do not generate local ringing.
    2. +
  2. If a ringing notification is received and no early media is received, generate local ringing.
    3. +
  3. If a ringing notification is received but early media is received, play the early media and do not generate local media.
    4. +
  4. Once the responder has accepted the session and the session (as opposed to early session) media has begun to flow, stop local ringing or stop playing early media.
    5. +
+

For examples of early media, see the Jingle Audio via RTP with Early Media section of this document.

 @@ -643,7 +622,9 @@ Romeo Juliet -

The following sections show a number of Jingle RTP scenarios, roughly in order of complexity.

+ +

The following sections show a number of Jingle RTP scenarios, roughly in order of increasing complexity.

+

In this scenario, Romeo initiates a voice chat with Juliet but she is otherwise engaged.

The session flow is as follows:

@@ -737,6 +718,7 @@ Romeo Juliet type='result'/> ]]> +

In this scenario, Romeo initiates a voice chat with Juliet using a transport method of ICE-UDP. The parties also exchange informational messages.

The session flow is as follows:

@@ -887,6 +869,7 @@ Romeo Juliet type='result'/> ]]> +

In this scenario, Romeo initiates a secure voice chat with Juliet using a transport method of ICE-UDP. The parties also exchange informational messages.

The session flow is as follows:

@@ -894,6 +877,7 @@ Romeo Juliet Romeo Juliet | | | session-initiate | + | (with keying material) | |---------------------------->| | ack | |<----------------------------| @@ -1066,6 +1050,207 @@ Romeo Juliet type='result'/> ]]> + + +

In this scenario, Romeo initiates a voice chat with Juliet using a transport method of ICE-UDP. There is a gateway between Romeo and Juliet, and the gateway functions as an application server by returning early media to Romeo (perhaps some late medieval hold music or an old-fashioned IVR interaction). To simplify the flow, we have left out any ringing notifications generated by Juliet.

+

The session flow is as follows.

+ | session-initiate | + | ack |------------------------>| + |<------------------------| | + | content-add | ack | + | (early media) x<------------------------| + |<------------------------| | + | ack | | + |------------------------>| | + | content-accept | | + |------------------------>| | + | ack | | + |<------------------------| | + | EARLY MEDIA (RTP) | | + |<=======================>| | + | | session-accept | + | |<------------------------| + | session-accept | | + |<------------------------| | + | ack | | + |------------------------>| ack | + | |------------------------>| + | AUDIO (RTP) | + |<=================================================>| + | | session-terminate | + | |<------------------------| + | session-terminate | | + |<------------------------| | + | ack | | + |------------------------>| ack | + | |------------------------>| + | | | + ]]> +

The protocol flow is as follows, showing only the stanzas sent between Romeo and the gateway (acting on Juliet's behalf).

+ + + + + + + + + + + + + + + ]]> + + ]]> +

Now the gateway sends a content-add action to Romeo while waiting for Juliet to pay attention to her telephony interface.

+ + + + + + + + + + + + + ]]> +

Romeo then acknowledges the content-add action and immediately also sends a content-accept.

+ + ]]> + + + + + + + + + + + + + ]]> +

The gateway then acknowledges the acceptance on behalf of Juliet.

+ + ]]> +

Now the gateway sends early media to Romeo.

+

Eventually, the responder sends a session-accept.

+ + + + + + + + + + + + + + ]]> + + ]]> +

The endpoints now begin to exchange session media; as a result, Romeo and the gateway terminate the exchange of early media.

+

The endpoints can continue the session as long as desired.

+

Eventually, one of the endpoints terminates the session.

+ + + + + Sorry, gotta go! + + + + ]]> +

The other party then acknowledges termination of the session:

+ + ]]> + +

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

The session flow is as follows: