From b72ed9cadae0f1030e5f40a4a1bc3622780c5c03 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 23 Mar 2007 22:07:08 +0000 Subject: [PATCH] 0.13 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@687 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0166.xml | 362 ++++++++++++++++----------------------------------- 1 file changed, 115 insertions(+), 247 deletions(-) diff --git a/xep-0166.xml b/xep-0166.xml index 9449efbd..4c02dabb 100644 --- a/xep-0166.xml +++ b/xep-0166.xml @@ -23,9 +23,15 @@ &scottlu; &joebeda; &stpeter; - &hildjj; - &seanegan; &robmcqueen; + &seanegan; + &hildjj; + + 0.13 + 2007-03-23 + psa/ram +

Simplified signalling process and state chart; Removed session-redirect action (use redirect error instead); removed content-decline action; removed transport-* actions (except transport-info for ICE negotiation); removed description-* actions; simplified syntax to allow only one transport per content type; corrected syntax of creator attribute to be either initiator or responder (not JIDs); added profile attribute to content element in order to specify RTP profile in use.

 + 0.12 2006-12-21 @@ -200,7 +206,7 @@ Content Type - The combination of one content description and at least one content transport method. + The combination of one content description and one content transport method. Content Description @@ -226,14 +232,14 @@

This document defines the semantics and syntax for overall session management. It also provides pluggable "slots" for content description formats and content transport methods, which are specified in separate documents; however, for the sake of completeness, this document also includes examples for all of the actions related to description formats and transport methods.

At the most basic level, the process for negotiating a Jingle session is as follows:

    -
  1. One user (the "initator") sends to another user (the "receiver") a session request with one content type, which includes one content description and (say) two potential transport methods.
    2. +
  2. One user (the "initator") sends to another user (the "receiver") a session request with one content type, which includes at least one content type.
  3. If the receiver wants to proceed, it provisionally accepts the request by sending an IQ result.
  4. Both the initiator and receive start exchanging possible transport candidates as quickly as possible (these are sent in quick succession before further negotiation in order to minimize the time required before media data can flow).
  5. These candidates are checked for connectivity.
  6. As soon as the receiver finds a candidate over which media can flow, the receiver sends to the initiator a "session-accept" action.
  7. The parties start sending media over the negotiated candidate.
-

If the parties later discover a better candidate, they perform a "transport-modify" or "content-modify" negotiation and then switch to the better candidate. Naturally they can also modify various other parameters related to the session (e.g., adding video to a voice chat).

+

If the parties later discover a better candidate, they perform a "content-modify" negotiation and then switch to the better candidate. Naturally they can also modify various other parameters related to the session (e.g., adding video to a voice chat).

The state machine for overall session management (i.e., the state per Session ID) is as follows:

@@ -245,26 +251,23 @@ |/ | PENDING o---------------------+ | | | session-info, | | - | | content-remove, | | - | | content-modify, | | | | content-accept, | | - | | content-decline | | + | | content-modify, | | + | | content-remove | | | +------------------+ | | | | session-accept | | | ACTIVE o---------------------+ | | | session-info, | | - | | content-add, | | - | | content-remove, | | - | | content-modify, | | | | content-accept, | | - | | content-decline | | + | | content-add, | | + | | content-modify, | | + | | content-remove | | | +------------------+ | | | +-------------------------+ | - | session-redirect, | session-terminate | o ENDED @@ -276,121 +279,48 @@ PENDING o---------------------+ |
  • ENDED

    • The actions related to management of the overall Jingle session are as follows:

    -
      -
    1. content-accept
      2. -
    2. content-add
      3. -
    3. content-decline
      4. -
    4. content-modify
      5. -
    5. content-remove
      6. -
    6. session-accept
      7. -
    7. session-initiate
      8. -
    8. session-info
      9. -
    9. session-redirect
      10. -
    10. session-terminate
      11. -
    -

    These actions are defined in greater detail under Jingle Actions.

    -     - -

    The content type of a session is made up of two aspects:

    -
      -
    1. The content description format specifies the "what" of the session (e.g., audio).
      2. -
    2. The content transport method defines "how" the data shall be exchanged (e.g., raw UDP).
      3. -
    -

    The &CONTENT; element also specifies who will be sending content (the initiator, the recipient, or both).

    - -

    When negotiating the session and its content type, the entities involved in the session need to exchange content description formats. The approach taken herein is to specify pure session description information in separate specifications, one for each content description format (audio, video, etc.). While it is possible to send raw Session Description Protocol (SDP) data for the session descriptions (the approach that was taken in XEP-0111), this is not necessarily helpful, since SDP is not structured data, not all SDP data is needed or used in the most common use cases, and SDP has been heavily extended in several useful directions that are not captured in the core SDP specification. The session negotiation must contain some content description format(s), which are defined in separate specifications. Those specifications also define the state chart for the content description format in question.

    -

    The generic state machine for management of any given content description format is as follows:

    - - START - o - | - | session-initiate - | content-add - | -[PENDING] o-------------+ - | | | description-info - | |_________| description-modify - | - | content-accept - | description-accept - | session-accept - | - | _____________________o [MODIFYING] - | / description-modify / \ - |/ / | - [ACTIVE] o--------------------/ | - |\ description-decline | - | \______________________/ - | description-accept - | - | content-remove - | session-terminate - | - o [ENDED] - -

    The states related to management of content description formats are:

    -
      -
    1. PENDING
      2. -
    2. ACTIVE
      3. -
    3. MODIFYING
      4. -
    4. ENDED
      5. -
    -

    The actions related to management of content description formats are as follows:

    -
      -
    1. description-accept
      2. -
    2. description-decline
      3. -
    3. description-info
      4. -
    4. description-modify
      5. -
    -

    These actions are defined in greater detail under Jingle Actions.

    -     - -

    As with the content description formats, the content transport methods are defined in separate specifications. Possible content transport methods include Real-time Transport Protocol (RTP) with Interactive Connectivity Establishment (ICE) and raw UDP. The relevant specifications also define the state chart for the content transport method in question.

    -

    The generic state machine for any given content transport method is as follows:

    - - START - o - | - | session-initiate - | content-add - | -[PENDING] o-------------+ - | | | transport-info - | |_________| transport-modify - | - | content-accept - | session-accept - | transport-accept - | - | ___________________o [MODIFYING] - | / transport-modify / \ - |/ / | - [ACTIVE] o------------------/ | - |\ transport-decline | - | \____________________/ - | transport-accept - | - | content-remove - | session-terminate - | - o [ENDED] - -

    The states related to management of content transport methods are:

    -
      -
    1. PENDING
      2. -
    2. ACTIVE
      3. -
    3. MODIFYING
      4. -
    4. ENDED
      5. -
    -

    The actions related to management of content transport methods are as follows:

    -
      -
    1. transport-accept
      2. -
    2. transport-decline
      3. -
    3. transport-info
      4. -
    4. transport-modify
      5. -
    -

    These actions are defined in greater detail under Jingle Actions.

    -     + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ActionDescription
    content-acceptAccept a content-add or content-remove action received from another party.
    content-addAdd one or more new content types to the session. This action MUST NOT be sent while the session is in the PENDING state. In the event that a session contains two unidirectional streams of the same type because a content-add was issued simultaneously by both parties, it is RECOMMENDED that participants close the duplicate stream in favour of that created by the session initiator, which should be made bidirectional with a 'content-modify' action by the responder.
    content-modifyChange an existing content type. The recipient MUST NOT reply to a content-modify action with another content-modify action.
    content-removeRemove one or more content types from the session. A client MUST NOT return an error upon receipt of a 'content-remove' action for a content description that is received after a 'content-remove' action has been sent but before the action has been acknowledged by the peer.
    session-acceptDefinitively accept a session negotiation. Implicitly this action also serves as a content-accept (which in turn serves as a description-accept and transport-accept).
    session-infoSend session-level information / messages, such as (for Jingle audio) a ringing message.
    session-initiateRequest negotiation of a new Jingle session.
    session-terminateEnd an existing session.
    transport-infoExchange transport candidates; it is mainly used in XEP-0176 but may be used in other transport specifications.
     @@ -401,7 +331,7 @@ PENDING o---------------------+ |

    If a contact has more than one XMPP resource that supports Jingle and the desired content description format, it is RECOMMENDED for a client to use &xep0168; in order to determine which is the best resource with which to initiate the desired Jingle session.

    -

    Once the initiating entity has discovered which of the receiver's XMPP resources is ideal for the desired content description format, it sends a session initiation request to the receiver. This request is an IQ-set containing a &JINGLE; element qualified by the 'http://www.xmpp.org/extensions/xep-0166.html#ns' namespace. The &JINGLE; element MUST possess the 'action', 'initiator', and 'sid' attributes (the latter two uniquely identify the session). For initiation, the 'action' attribute MUST have a value of "session-initiate" and the &JINGLE; element MUST contain one or more &CONTENT; elements, each of which defines a content type to be transferred during the session; each &CONTENT; element in turn contains one &DESCRIPTION; child element that specifies a desired content description format and one or more &TRANSPORT; child elements that specify potential content transport methods.

    +

    Once the initiating entity has discovered which of the receiver's XMPP resources is ideal for the desired content description format, it sends a session initiation request to the receiver. This request is an IQ-set containing a &JINGLE; element qualified by the 'http://www.xmpp.org/extensions/xep-0166.html#ns' namespace. The &JINGLE; element MUST possess the 'action', 'initiator', and 'sid' attributes (the latter two uniquely identify the session). For initiation, the 'action' attribute MUST have a value of "session-initiate" and the &JINGLE; element MUST contain one or more &CONTENT; elements, each of which defines a content type to be transferred during the session; each &CONTENT; element in turn contains one &DESCRIPTION; child element that specifies a desired content description format and one &TRANSPORT; child element that specifies a potential content transport method. If either party wishes to propose the use of multiple transport methods for the same content description, it must send multiple &CONTENT; elements.

    The following example shows a Jingle session initiation request for a session that contains both audio and video content:

    @@ -409,22 +339,16 @@ PENDING o---------------------+ | action='session-initiate' initiator='romeo@montague.net/orchard' sid='a73sjjvkla37jfea'> - + ... - - - - + ... - - - @@ -442,6 +366,7 @@ PENDING o---------------------+ |
    • The 'creator' attribute is REQUIRED; it specifies which party originally generated the content description (used to prevent race conditions regarding modifications).
    • The 'name' attribute is REQUIRED; it specifies a unique name or identifier for the content type (this identifier is opaque and does not have semantic meaning).
      • +
    • The 'profile' attribute is RECOMMENDED; for some content types, it specifies the profile in use (e.g., "RTP/AVP" in the context of the Real-time Transport Protocol).
    • The 'senders' attribute is RECOMMENDED; it specifies which entities in the session will be generating content; the allowable values are "initiator", "recipient", or "both" (where "both" is the default).
     @@ -453,18 +378,27 @@ PENDING o---------------------+ |

    If the receiver acknowledges receipt of the initation request, both parties must consider the session to be in the PENDING state.

    There are several reasons why the receiver might return an error instead of acknowledging receipt of the initiation request:

      -
    • The initiating entity is unknown to the receiver (e.g., via presence subscription).
      • +
    • The initiating entity is unknown to the receiver (e.g., via presence subscription) and the receiver does not communicate with unknown entities.
      • +
    • The receiver wishes to redirect to another address.
    • The receiver does not support Jingle.
    • The receiver does not support any of the specified content description formats.
    • The receiver does not support any of the specified content transport methods.
    • The initiation request was malformed.
    -

    The initiating entity is unknown to the receiver (e.g., via presence subscription) and the receiver has a policy of not communicating via Jingle with unknown entities, it MUST return a &unavailable; error.

    +

    If the initiating entity is unknown to the receiver (e.g., via presence subscription) and the receiver has a policy of not communicating via Jingle with unknown entities, it SHOULD return a &unavailable; error.

    + + ]]> +

    If the receiver wishes to redirect to another address, it SHOULD return a &redirect; error.

    + + + xmpp:voicemail@capulet.com + ]]>

    If the receiver does not support Jingle, it MUST return a &unavailable; error.

    @@ -502,31 +436,6 @@ PENDING o---------------------+ | ]]> - -

    After acknowledging receipt of the initiation request, the receiver MAY redirect the session to another address (e.g., because the principal is not answering at the original resource). This is done by sending a Jingle redirect action to the initiating entity:

    - - - xmpp:voicemail@capulet.com - - - ]]> -

    The recipient then acknowledges the redirection:

    - - ]]> -

    Both entities MUST now consider the original session to be in the ENDED state, and if the initiating entity wishes to initiate a session with the redirected address it MUST do so by sending a session initiation request to that address with a new session ID.

    -

    In order to decline the session initiation request, the receiver MUST acknowledge receipt of the session initiation request, then terminate the session as described under Termination.

     @@ -539,7 +448,7 @@ PENDING o---------------------+ | action='content-remove' initiator='romeo@montague.net/orchard' sid='a73sjjvkla37jfea'> - + ]]> @@ -559,14 +468,13 @@ PENDING o---------------------+ | initiator='romeo@montague.net/orchard' responder='juliet@capulet.com/balcony' sid='a73sjjvkla37jfea'> - + ... - @@ -589,14 +497,13 @@ PENDING o---------------------+ | action='content-add' initiator='romeo@montague.net/orchard' sid='a73sjjvkla37jfea'> - + ... - @@ -608,17 +515,16 @@ PENDING o---------------------+ | - + ... - @@ -661,66 +567,6 @@ PENDING o---------------------+ |     - -

    This section provides more detailed descriptions for each Jingle-related action.

    - -

    This action enables a party to accept a content-add or content-remove action received from another party. Implicitly this action also serves as a description-accept and transport-accept.

    -     - -

    This action enables a party to add one or more new content types to the session. This action MUST NOT be sent while the session is in the PENDING state.

    -

    In the event that a session contains two unidirectional streams of the same type, due to content-add being issued simultaneously by both participants of the session, it is RECOMMENDED that participants close the duplicate stream in favour of that created by the session initiator, which should be made bidirectional with a 'content-modify' action by the responder.

    -     - -

    This action enables a party to reject a content-add or content-modify action received from another party.

    -     - -

    This action enables a party to change an existing content type. The recipient MUST NOT reply to a content-modify action with another content-modify action. The content-modify action is mainly used to modify the directionality of the session.

    -     - -

    This action enables a party to remove one or more content types from the session.

    -

    Clients MUST NOT return an error upon recipt of a 'content-remove' action for a content description which is received after a 'content-remove' action has been sent, but before the action has been acknowledged by the peer.

    -     - -

    This action enables a party to accept a description-modify action received from another party.

    -     - -

    This action enables a party to decline a description-modify action received from another party.

    -     - -

    This action enables a party to sent description-level information / messages.

    -     - -

    This action enables a party to request a change to a content description format.

    -     - -

    This action enables a party to definitively accept a session negotiation. Implicitly this action also serves as a content-accept (which in turn serves as a description-accept and transport-accept).

    -     - -

    This action enables a party to request negotiation of a new Jingle session.

    -     - -

    This action enables a party to send session-level information / messages.

    -     - -

    This action enables a party to redirect an initiate request to another address.

    -     - -

    This action enables a party to end an existing session.

    -     - -

    This action enables a party to accept a transport-modify action received from another party.

    -     - -

    This action enables a party to decline a transport-modify action received from another party.

    -     - -

    This action enables a party to send transport-level information / messages.

    -     - -

    This action enables a party to request a change to the content transport methods.

    -     -     -

    The Jingle-specific error conditions are as follows.

    @@ -752,12 +598,35 @@ PENDING o---------------------+ |
    + +

    If an entity supports Jingle, it MUST advertise that fact by returning a feature of "http://www.xmpp.org/extensions/xep-0167.html#ns" &NSNOTE; in response to &xep0030; information requests.

    + + + + ]]> + + + ... + + ... + + + ]]> +     +

    There is a one-to-one relationship between content types and sessions. This reduces the complexity of managing a given session, since it avoids the need to de-multiplex traffic for different content types sent over the same connection. However, it may be desirable to share different kinds of content at the same time (e.g., during a video chat one party may want to share a file); in order to do this, the parties must establish a separate session for each content type. Management of multiple sessions is a client implementation matter and is not discussed in this specification.

     -

    Note: This section is not yet complete.

    Jingle sessions may be resource-intensive. Therefore, it is possible to launch a denial-of-service attack against an entity by burdening it with too many Jingle sessions. Care must be taken to accept content sessions only from known entities and only if the entity's device is able to process such sessions.

     @@ -772,10 +641,10 @@ PENDING o---------------------+ | -

    The ®ISTRAR; shall include 'http://www.xmpp.org/extensions/xep-0166.html#ns' and 'http://www.xmpp.org/extensions/xep-0166.html#ns-errors' in its registry of protocol namespaces.

    +

    Until this specification advances to a status of Draft, its associated namespaces shall be "http://www.xmpp.org/extensions/xep-0166.html#ns" and "http://www.xmpp.org/extensions/xep-0167.html#ns-errors"; upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.

     -

    The XMPP Registrar shall maintain a registry of Jingle content description formats. All content description format registrations shall be defined in separate specifications (not in this document). Content description formats defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URIs of the form "http://www.xmpp.org/extensions/xep-0166.html#ns/description/name" (where "name" is the registered name of the content description format).

    +

    The XMPP Registrar shall maintain a registry of Jingle content description formats. All content description format registrations shall be defined in separate specifications (not in this document). Content description formats defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URNs of the form "urn:xmpp:jingle:description:name" (where "name" is the registered name of the content description format).

    ®PROCESS; @@ -786,7 +655,7 @@ PENDING o---------------------+ | ]]>     -

    The XMPP Registrar shall maintain a registry of Jingle content transport methods. All content transport method registrations shall be defined in separate specifications (not in this document). Content transport methods defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URIs of the form "http://www.xmpp.org/extensions/xep-0166.html#ns/transport/name" (where "name" is the registered name of the content transport method).

    +

    The XMPP Registrar shall maintain a registry of Jingle content transport methods. All content transport method registrations shall be defined in separate specifications (not in this document). Content transport methods defined within the XEP series MUST be registered with the XMPP Registrar, resulting in protocol URNs of the form "urn:xmpp:jingle:transport:name" (where "name" is the registered name of the content transport method).

    ®PROCESS; @@ -818,22 +687,13 @@ PENDING o---------------------+ | - - - - - - - - - @@ -850,8 +710,16 @@ PENDING o---------------------+ | - + + + + + + + + + @@ -893,6 +761,6 @@ PENDING o---------------------+ |     -

    The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Rob Taylor, Dafydd Harries, Jussi Laako, Saku Vainio, Antti Ijäs, Brian West, Anthony Minessale, Matt O'Gorman, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and (earlier) Jingle Before this specification was accepted as a XMPP Extension Protocol specification, it was discussed on the semi-private <jingle@jabber.org> mailing list; although that list is no longer used (the Standards list is the preferred discussion venue), for historical purposes it is publicly archived at <http://mail.jabber.org/pipermail/jingle/>. mailing lists.

    +

    The authors would like to thank Rohan Mahy for his valuable input on early versions of this document. Dafydd Harries, Antti Ijäs, Jussi Laako, Anthony Minessale, Matt O'Gorman, Rob Taylor, Saku Vainio, Brian West, and others have also provided helpful input. Thanks also to those who have commented on the &SSIG; and (earlier) Jingle Before this specification was accepted as a XMPP Extension Protocol specification, it was discussed on the semi-private <jingle@jabber.org> mailing list; although that list is no longer used (the Standards list is the preferred discussion venue), for historical purposes it is publicly archived at <http://mail.jabber.org/pipermail/jingle/>. mailing lists.