From 2c776569f3249d78272b285ef7288cbee081e107 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 19 Dec 2008 04:26:32 +0000 Subject: [PATCH] 0.25rc1 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2581 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0167.xml | 144 ++++++++++++++++++++++++++++++++------------------- 1 file changed, 91 insertions(+), 53 deletions(-) diff --git a/xep-0167.xml b/xep-0167.xml index 926fcea3..15cdb408 100644 --- a/xep-0167.xml +++ b/xep-0167.xml @@ -37,6 +37,7 @@
  • Refactored encryption syntax.
  • Added optional bandwidth element.
  • Added example of description-info action for modifying application parameters.
    • +
  • Corrected the schemas.
    • @@ -275,25 +276,25 @@ channels The number of channels; if omitted, it MUST be assumed to contain one channel - positiveInteger (defaults to 1) + unsignedByte (defaults to 1) RECOMMENDED clockrate The sampling frequency in Hertz - positiveInteger + unsignedInt RECOMMENDED id The payload identifier - positiveInteger + unsignedByte REQUIRED maxptime Maximum packet time as specified in RFC 4566 - positiveInteger + unsignedInt OPTIONAL @@ -305,7 +306,7 @@ ptime Packet time as specified in RFC 4566 - positiveInteger + unsignedInt OPTIONAL @@ -369,7 +370,7 @@ Initiator Responder to='romeo@montague.lit/orchard' type='result'/> ]]> -

    After successful transport negotiation (not shown here), the responder accepts the session by sending a session-accept action to the initiator. The session-accept SHOULD include a subset of the payload types sent by the initiator, i.e., a list of the offered payload types that the responder can send and/or receive. The list that the responder sends SHOULD retain the ID numbers specified by the initiator. The order of the &PAYLOADTYPE; elements indicates the responder's preferences, with the most-preferred types first.

    +

    After successful transport negotiation (not shown here), the responder accepts the session by sending a session-accept action to the initiator. The session-accept SHOULD include a subset of the payload types sent by the initiator, i.e., a list of the offered payload types that the responder can send and/or receive. The list that the responder sends SHOULD retain the ID numbers specified by the initiator. The order of the &PAYLOADTYPE; elements indicates the responder's preferences, with the most-preferred type first.

    In the following example, we imagine that the responder supports Speex at clockrate of 8000 but not 16000, G729, and PCMA but not PMCU. Therefore the responder returns only two payload types (since PMCA was not offered).

    The SDP media type for Jingle RTP is "audio" (see Section 8.2.1 of RFC 4566) for audio media, "video" (see Section 8.2.1 of RFC 4566) for video media, etc. The media type is reflected in the Jingle 'media' attribute.

    -

    The Jingle 'bandwidth' attribute SHALL be mapped to an SDP b= line, where the SDP <bwtype> parameter MUST be "AS" and the SDP <bandwidth> parameter contains the value of the Jingle 'bandwidth' attribute.

    +

    The Jingle <bandwidth/> element SHALL be mapped to an SDP b= line; in particular, the value of the 'type' attribute shall be mapped to the SDP <bwtype> parameter and the XML character data of the Jingle <bandwidth/> element shall be mapped to the SDP <bandwidth> parameter.

    If the payload type is static (payload-type IDs 0 through 95 inclusive), it MUST be mapped to a media field defined in RFC 4566. The generic format for the media field is as follows:

    ]]> -

    In the context of Jingle audio sessions, the <media> is "audio" or "video" or some other media type as specified by the 'media' attribute, the <port> is the preferred port for such communications (which might be determined dynamically), and the <fmt list> is the payload-type ID.

    +

    In the context of Jingle audio sessions, the <media> parameter is "audio" or "video" or some other media type as specified by the 'media' attribute, the <port> parameter is the preferred port for such communications (which might be determined dynamically), and the <fmt list> parameter is the payload-type ID.

    For example, consider the following static payload-type:

    @@ -487,15 +488,15 @@ 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, 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 RFC 3960.

    +

    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". This enables endpoints or intermediate gateways to apply the application server model described in RFC 3960.

    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 that generates the early media does not generate the 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, complete any required transpor negotiation, and then send a content-accept (or content-reject) to the sender. When the responder subsequently sends a session-accept action, the acceptance MUST NOT be construed to include the content definition whose disposition is "early-session".

    +

    Upon receiving a content-add action specifying the use of early media, the initiator's client SHOULD acknowledge the content-add, complete any required transport negotiation, and then send a content-accept (or content-reject) to the sender. When the responder subsequently sends a session-accept action, the acceptance MUST NOT be construed to include the content definition whose disposition is "early-session".

    In handling early media and deciding whether to generate local ringing or to 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. If a ringing notification is received and no early media is received, generate local ringing.
    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. +
    5. Once the responder has accepted the session and the session data (as opposed to early session data) has begun to flow, stop local ringing or stop playing early media.

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

     @@ -520,14 +521,63 @@ delivery-method=inline; configuration=somebase16string; tag='1'/> ]]>     -

    The mapping of to SDP is as follows.

    +

    The mapping of that data to SDP is as follows.

    When the responder receives a session-initiate action containing an <encryption/> element, the responder MUST either (1) accept the offer by denoting one of the <crypto/> elements as acceptable (it does this by mirroring that <crypto/> element in its session acceptance) or (2) reject the offer by sending a session-terminate action with a Jingle reason of <security-error/> and an RTP-specific condition of <invalid-crypto/>.

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

    If the responder requires encryption but the initiator did not include an <encryption/> element in its offer, the responder MUST reject the offer by sending a session-terminate action with a Jingle reason of <security-error/> and an RTP-specific condition of <crypto-required/>.

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

    If the initiator requires encryption but the responder does not include an <encryption/> element in its session acceptance, the initiator MUST terminate the session with a Jingle reason of <security-error/> and an RTP-specific condition of <crypto-required/>.

    + + + + + + + + + ]]> @@ -540,7 +590,7 @@ delivery-method=inline; configuration=somebase16string; <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. + 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/> @@ -548,7 +598,7 @@ delivery-method=inline; configuration=somebase16string; <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. + 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/> @@ -656,10 +706,8 @@ delivery-method=inline; configuration=somebase16string; to='romeo@montague.lit/orchard' type='result'> - ... - ... ]]>     @@ -716,7 +764,7 @@ Romeo Juliet ]]> ]]> @@ -820,7 +868,7 @@ Romeo Juliet ]]> ]]> @@ -887,7 +935,7 @@ Romeo Juliet to='juliet@capulet.lit/balcony' type='result'/> ]]> -

    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 now begin to exchange media. In this case they would use RTP to 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 can continue the session as long as desired.

    Eventually, one of the parties terminates the session.

    ]]> -

    To signal that the initiator wishes to use SRTP, the initiator's client includes keying material via the <encryption/> element (with one set of keying material per <crypto/> element). Here the initiator signals that encryption is mandatory via the 'required' attribute.

    +

    To signal that the initiator wishes to use SRTP, the initiator's client includes keying material via the <encryption/> element (with one set of keying material per <crypto/> element). Here the initiator also signals that encryption is mandatory via the 'required' attribute.

    The responder immediately acknowledges the session initiation request.

    ]]> -

    If the keying material is acceptable, the responder's continues with the negotiation. If the keying material is not acceptable, the responder's client terminates the session (and can do so at any time).

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

    If the keying material is acceptable, the responder's continues with the negotiation. If the keying material is not acceptable, the responder's client terminates the session as described under Negotiation of SRTP.

    ]]> -

    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 now begin to exchange media. In this case they would use SRTP to 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 can continue the session as long as desired.

    Eventually, one of the parties terminates the session.

    ]]> @@ -1188,7 +1220,7 @@ Romeo Gateway Juliet - + ]]> -

    Because the gateway (on behalf of the responder) specified a transport method of Raw UDP for the early session data, the initiator then would send a Raw UDP candidate to the gateway, inform the gateway that it is trying to send media to the candidate provided by the gateway, etc. See XEP-0177 for details.

    +

    Because the gateway (on behalf of the responder) specified a transport method of Raw UDP for the early session data, the initiator then would send a Raw UDP candidate to the gateway (see XEP-0177 for details).

    Eventually the initiator would send a content-accept to the gateway.

    - + Eventually, the responder sends a session-accept.

    ]]> @@ -1496,7 +1528,7 @@ Romeo Juliet to='juliet@capulet.lit/balcony' type='result'/> ]]>     -

    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 now begin to exchange media. In this case they would use RTP to 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 chat for a while. Eventually Juliet wants to get her hair in order so she puts Romeo on hold.

    ]]> ]]>

    Eventually, one of the parties terminates the session.

    XMPP applications that use Jingle RTP sessions for voice chat MUST support and prefer native RTP methods of communicating DTMF information, in particular the "audio/telephone-event" and "audio/tone" media types. It is NOT RECOMMENDED to use the protocol described in &xep0181; for communicating DTMF information with RTP-aware endpoints.

    -

    When the Jingle RTP content type is accepted via a session-accept action, both initiator and responder SHOULD start listening for audio as defined by the negotiated transport method and audio application format. For interoperability with telephony systems, after the responder acknowledges the session initiation request, the responder SHOULD send a "ringing" message and both parties SHOULD play any audio received.

    +

    When the Jingle RTP content type is accepted via a session-accept action, both initiator and responder SHOULD start listening for audio as defined by the negotiated transport method and audio application format. For interoperability with telephony systems, after the responder acknowledges the session initiation request, the responder SHOULD send a "ringing" message and both parties SHOULD play any audio received. For more detailed suggestions in the context of early media, see under Early Media.

     @@ -1686,7 +1722,7 @@ Romeo Juliet -

    In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged. Such encryption methods are out of scope for this specification.

    +

    In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the RTP data transport; the use of SRTP is recommended.

     @@ -1704,7 +1740,7 @@ Romeo Juliet

    Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

     -

    If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

    + &NSVER;

    For each RTP media type that an entity supports, it MUST advertise support for the "urn:xmpp:jingle:apps:rtp:[media]" feature, where the string "[media]" is replaced by the appropriate media type such as "audio" or "video".

    @@ -1805,12 +1841,12 @@ Romeo Juliet minOccurs='0' maxOccurs='unbounded'/> - - + + - + - + @@ -1841,6 +1877,8 @@ Romeo Juliet xmlns='urn:xmpp:jingle:apps:rtp:errors:0' elementFormDefault='qualified'> + +