From 0918cad5f239117616b1c9d02c03cda025fa3c21 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Fri, 28 Dec 2007 20:31:54 +0000 Subject: [PATCH] 0.13 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1495 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0176.xml | 240 +++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 186 insertions(+), 54 deletions(-) diff --git a/xep-0176.xml b/xep-0176.xml index 522515ac..8b0ea764 100644 --- a/xep-0176.xml +++ b/xep-0176.xml @@ -27,6 +27,12 @@ &stpeter; &hildjj; &seanegan; + + 0.13 + 2007-12-28 + psa +

Added further details about connectivity checks; defined raddr and rport attributes for complete mapping to SDP.

 + 0.12 2007-11-28 @@ -135,6 +141,49 @@ + +

The overall protocol flow for negotiation of the Jingle ICE-UDP Transport Method is as follows (note: many of these events happen simultaneously, not in sequence). The examples follow the scenario described in Section 17 of &icecore;, except that we substitute the Shakespearean characters "Romeo" and "Juliet" for the generic entities "L" and "R".

+ | + | Jingle ack (XMPP IQ-result) | + |<-----------------------------------| + | Jingle transport-info (candidate) | + |----------------------------------->| + | Jingle ack (XMPP IQ-result) | + |<-----------------------------------| + | Jingle transport-info (candidate) | + |----------------------------------->| + | Jingle ack (XMPP IQ-result) | + |<-----------------------------------| + | Jingle transport-info (candidate) | + |<-----------------------------------| + | Jingle ack (XMPP IQ-result) | + |----------------------------------->| + | STUN Binding Request | + | (dropped) | + | x---------------------------------| + | STUN Binding Request | + |----------------------------------->| + | STUN Binding Result | + |<-----------------------------------| + | STUN Binding Request | + |<-----------------------------------| + | STUN Binding Result | + |----------------------------------->| + | Jingle content-accept | + |<-----------------------------------| + | Jingle ack (XMPP IQ-result) | + |----------------------------------->| + | Jingle session-accept | + |<-----------------------------------| + | Jingle ack (XMPP IQ-result) | + |----------------------------------->| + | | + ]]> +

In order for the initiator in a Jingle exchange to start the negotiation, it MUST send a Jingle "session-initiate" stanza as described in XEP-0166. A content type MUST include one transport method. If the initiator wishes to negotiate the ice-udp transport method for an application format, it MUST include an empty &TRANSPORT; child element qualified by the 'http://www.xmpp.org/extensions/xep-0176.html#ns' namespace &NSNOTE;.

]]> - +

Once the responder acknowledges receipt of the session initiation request as shown above, both initiator and responder MUST immediately negotiate connectivity over the ICE transport by exchanging XML-formatted candidate transports for the channel. This negotiation proceeds immediately in order to maximize the possibility that media can be exchanged as quickly as possible. Concurrent with negotiation of the ICE candidates, it is possible for the initiator and responder to negotiate which content types the session will include, which transport methods will be tried for each content type, etc. Those negotiation flows are shown in other specifications, such as XEP-0166. This document specifies only negotiation of the ICE transport method.

Note: In order to expedite session establishment, the initiator MAY send transport candidates immediately after sending the "session-initiate" message and before receiving acknowledgement from the responder (i.e., the initiator MUST consider the session to be live even before receiving acknowledgement). Given in-order delivery, the responder should receive such "transport-info" messages after receiving the "session-initiate" message; if not, it is appropriate for the responder to return <unknown-session/> errors since it according to its state machine the session does not exist. If either party receives an <unknown-session/> from the other party, it MUST terminate the negotiation and the session.

The candidate syntax and negotiation flow are described below.

- +

The following is an example of the candidate format:

ip The Internet Protocol (IP) address for the candidate transport mechanism; this may be either an IPv4 address or an IPv6 address. IP Address value in a=candidate line - 10.0.1.1 + 192.0.2.3 network @@ -226,7 +275,7 @@ port The port at the candidate IP address. Port value in a=candidate line - 8998 + 45664 priority @@ -234,7 +283,7 @@ In accordance with the rules specified in Section 4.1.1 of &icecore;, the priority values shown in the examples within this document have been calculated as follows. The "type preference" for host candidates is stipulated to be "126" and for server reflexive candidates "100". The "local preference" for network 0 is stipulated to be "4096", for network 1 "2048", and for network 2 "1024". Priority value in a=candidate line - 1678246398 + 2130706431 protocol @@ -248,6 +297,18 @@ a=ice-pwd line asd88fgpdd777uzjYhagZg + + raddr + A related address as defined in &icecore;. + Raddr value in a=candidate line + 10.0.1.1 + + + rport + A related port as defined in &icecore;. + Rport value in a=candidate line + 8998 + type A Candidate Type as defined in &icecore;. The allowable values are "host" for host candidates, "prflx" for peer reflexive candidates, "relay" for relayed candidates, and "srflx" for server reflexive candidates. @@ -262,13 +323,12 @@ - -

The first step in negotiating connectivity is for both parties to immediately begin sending transport candidates methods to the other client. The fact that both parties send candidates means that Jingle requires each party to be a full implementation of ICE, not a "lite" implementation as specified in &icecore;. These candidates SHOULD be gathered by following the procedure specified in Section 4.1.1 of &icecore; and prioritized by following the procedure specified in Section 4.1.2 of &icecore;. Each candidate MUST be sent in a &JINGLE; element with an action of "transport-info".

+ +

The first step in negotiating connectivity is for each party to immediately begin sending transport candidates to the other party. The fact that both parties send candidates means that Jingle requires each party to be a full implementation of ICE, not a lite implementation as specified in &icecore;. These candidates SHOULD be gathered by following the procedure specified in Section 4.1.1 of &icecore; and prioritized by following the procedure specified in Section 4.1.2 of &icecore;. Each candidate MUST be sent in a &JINGLE; element with an action of "transport-info".

If the responder receives and can successfully process a given candidate, it returns an IQ-result (if not, for example because the candidate data is improperly formatted, it returns an error). Note: The responder is only indicating receipt of the candidate, not telling the initiator that the candidate will be used.

The initiator keeps sending candidates, one after the other (without stopping to receive an acknowledgement of receipt from the responder for each candidate) until it has exhausted its supply of possible or desirable candidate transports. (Because certain candidates may be more "expensive" in terms of bandwidth or processing power, the initiator may not want to advertise their existence unless necessary.) For each candidate, the responder acknowledges receipt.

At the same time (i.e., immediately after acknowledging receipt of the session-initiate request, not waiting for the initiator to begin or finish sending candidates), the responder also begins sending potential candidates, in order of desirability according to the responder. As above, the initiator acknowledges receipt of the candidates.

-

As the initiator and responder receive candidates, they probe the various candidate transports for connectivity. In performing these connectivity checks, a client SHOULD follow the procedure specified in Section 7 of &icecore;.

- - ]]> - @@ -322,34 +383,7 @@ ]]> - - - - - - - - - - ]]> -

For each candidate received, the other party MUST acknowledge receipt or return an error:

+

For each candidate received, the other party (in this case the responder) MUST acknowledge receipt or return an error.

- - +

At the same time (i.e., immediately after acknowledging the session-initation request, not waiting for the initiator to begin or finish sending candidates), the responder also sends candidates that may work for it.

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

As above for the candidates sent by the responder, here the initiator acknowledges receipt of the candidates sent by the responder.

+ ]]> + +

As the initiator and responder receive candidates, they probe the various candidate transports for connectivity. In performing these connectivity checks, each party SHOULD follow the procedure specified in Section 7 of &icecore;. The following business rules apply:

+
    +
  1. Each party sends a STUN Binding Request (see &rfc3489bis;) from each local candidate it generated to each remote candidate it received.
    2. +
  2. In accordance with &icecore;, the STUN Binding Request MUST include the PRIORITY attribute (computed according to Section 7.1.1.1. of &icecore;).
    3. +
  3. For the purposes of the Jingle ICE-UDP Transport Method, both parties are full ICE implementations and therefore the controlling role MUST be assumed by the initiator and the controlled role MUST be assumed by the responder.
    4. +
  4. The STUN Binding Requests generated by the initiator MAY include the USE-CANDIDATE attribute to indicate that the initiator wishes to cease checks for this component.
    5. +
  5. The STUN Binding Requests generated by the initiator MUST include the ICE-CONTROLLING attribute.
    6. +
  6. The STUN Binding Requests generated by the responder MUST include the ICE-CONTROLLED attribute.
    7. +
  7. The parties MUST use STUN short term credentials to authenticate requests and perform message integrity checks.
    8. +
+

When it receives a STUN Binding Request, each party MUST return a STUN Binding Response, which may indicate either an error case or the success case. As described in Section 7.1.2.2 of &icecore;, a connectivity check succeeds if the STUN transaction generated a success response, the source IP address and port of the response equals the destination IP address and port that the Binding Request was sent to, and the destination IP address and port of the response match the source IP address and port that the Binding Request was sent from.

+

For the candidates exchanged in the previous section, the connectivity checks would be as follows. In particular, the parties send one STUN Binding Request from each of their local candidates to each of the remote candidates.

+ | | + | | STUN Binding Request | + | | from 192.0.2.3:45664 | + | | to 192.0.2.1:3478 | + | | USE-CANDIDATE | + | |---------------------->| + | | STUN Binding Response | + | | from 192.0.2.1:3478 | + | | to 192.0.2.3:45664 | + | |<----------------------| + | STUN Binding Response | | + | from 192.0.2.1:3478 | | + | to 10.0.1.1:8998 | | + | map 192.0.2.3:45664 | | + |<----------------------| | + |================RTP now can flow==============>| + | | STUN Binding Request | + | | from 192.0.2.1:3478 | + | | to 192.0.2.3:45664 | + | |<----------------------| + | STUN Binding Request | | + | from 192.0.2.1:3478 | | + | to 10.0.1.1:8998 | | + |<----------------------| | + | STUN Binding Response | | + | from 10.0.1.1:8998 | | + | to 192.0.2.1:3478 | | + | map 192.0.2.1:3478 | | + |---------------------->| | + | | STUN Binding Response | + | | from 192.0.2.3:45664 | + | | to 192.0.2.1:3478 | + | | map 192.0.2.1:3478 | + | |---------------------->| + |<===============RTP now can flow===============| + | | | + ]]> +

Note: The initiator (controlling agent) is using "aggressive nomination" as described in Section 8.1.1.2 of &icecore; and therefore includes the USE-CANDIDATE attribute in the STUN Binding Requests it sends.

+ -

If, based on STUN connectivity checks (see &rfc3489; and &rfc3489bis;), the responder determines that it will be able to establish a connection using a given candidate, it sends a &JINGLE; element with an action of 'content-accept' (or 'session-accept') to the initiator, specifying the candidate that succeeded:

+

If, based on STUN connectivity checks, the parties determine that they will be able to exchange media a given candidate, the responder sends a &JINGLE; element with an action of 'content-accept' (or 'session-accept') to the initiator, specifying the candidate that succeeded.

@@ -402,14 +532,14 @@ ]]>

The &JINGLE; element in the content-accept or session-accept stanza SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity. If the 'responder' attribute is provided, all future commmunications SHOULD be sent to the JID provided in the 'responder' attribute.

-

If the initiator can also send data over that candidate, then it acknowledges the responder's acceptance:

+

Since according to the connectivity checks the initiator can also send data over that candidate, it acknowledges the responder's acceptance:

]]> -

Now the initiator and responder can begin sending data over the negotiated connection.

+

Now the initiator and responder can begin sending data over the negotiated connection (in fact, they could have sent data as soon as the connectivity checks succeeded, as shown in the preceding examples).

If a candidate succeeded for the responder but the initiator cannot send data over that candidate, it MUST return a ¬acceptable; error in response to the responder's acceptance of the successful candidate:

+ +