From 8c45c3df4acc4cbffce9703952530b4a9199f4ee Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Thu, 26 Feb 2009 21:44:29 +0000 Subject: [PATCH] defined remote-candidate element git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2795 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0176.xml | 85 ++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 62 insertions(+), 23 deletions(-) diff --git a/xep-0176.xml b/xep-0176.xml index b81c7612..a18d0c1e 100644 --- a/xep-0176.xml +++ b/xep-0176.xml @@ -29,6 +29,18 @@ &hildjj; &seanegan; &robmcqueen; + + 0.26 + 2009-02-26 + psa +

Added transport-info payload for communication of the remote candidate.

+
+ + 0.25 + 2009-02-18 + psa +

Specified that pwd and ufrag attributes must be included when sending the first candidate; removed rem-addr and rem-port attributes.

+
0.24 2009-02-17 @@ -295,7 +307,7 @@ INITIATOR RESPONDER ]]> -

The &TRANSPORT; element's 'pwd' and 'ufrag' attributes MUST be included in the session-initiate request, in subsequent content-add and transport-replace actions, and when offering candidates via the transport-info action. The attributes MAY be included in a session-accept action. The values are separately generated for both the initiator and the responder, in accordance with &icecore; and as shown in the examples. The attributes are defined as follows.

+

The &TRANSPORT; element's 'pwd' and 'ufrag' attributes MUST be included whenever sending one or more candidates to the other party, e.g. in a session-initiate, session-accept, transport-info, content-add, or transport-replace message. The values for these attributes are separately generated for both the initiator and the responder, in accordance with &icecore; and as shown in the examples. The attributes are defined as follows.

@@ -392,18 +404,6 @@ INITIATOR RESPONDER - - - - - - - - - - - - @@ -420,7 +420,7 @@ INITIATOR RESPONDER to='romeo@montague.lit/orchard' type='result'/> ]]> -

Depending on the application type, a user agent controlled by a human user might need to wait for the user to affirm a desire to proceed with the session before continuing. When the user agent has received such affirmation (or if the user agent can automatically proceed for any reason, e.g. because no human intervention is expected or because a human user has configured the user agent to automatically accept sessions with a given entity), it returns a Jingle session-accept message. This message SHOULD also contain a &TRANSPORT; element that in turn contain one &CANDIDATE; element for each of the responder's higher-priority transport candidates, just as for the session-initiate message, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).

+

Depending on the application type, a user agent controlled by a human user might need to wait for the user to affirm a desire to proceed with the session before continuing. When the user agent has received such affirmation (or if the user agent can automatically proceed for any reason, e.g. because no human intervention is expected or because a human user has configured the user agent to automatically accept sessions with a given entity), it returns a Jingle session-accept message. This message MUST contain a &TRANSPORT; element qualified by the 'urn:xmpp:jingle:transports:ice-udp:1' namespace, which SHOULD in turn contain one &CANDIDATE; element for each ICE-UDP candidate generated by or known to the responder, but MAY instead be empty (with each candidate to be sent as the payload of a transport-info message).

Note: See the Security Considerations section of this document regarding the exposure of IP addresses on behalf by the responder's client.

Note: Here 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, the parties determine that they will be able to exchange media between a given pair of local candidates and remote candidates (i.e., the pair is "nominated" and ICE processing is "completed"), they can then begin using that candidate pair to exchange media. There is no need for the parties to communicate the chosen candidate pair in the signalling channel.

+

If, based on STUN connectivity checks, the parties determine that they will be able to exchange media between a given pair of local candidates and remote candidates (i.e., the pair is "nominated" and ICE processing is "completed"), they can then begin using that candidate pair to exchange media.

+

Once the parties have connectivity and therefore the initiator has completed ICE as explained in &icecore;, the initiator MAY communicate the in-use candidate pair in the signalling channel by sending a transport-info message that contains a <remote-candidate/> element (this maps to the SDP "remote-candidates attribute as described in Section B.6 of &icecore;, i.e., remote candidates are "the actual candidates at R that were selected by the offerer", of which there will be only one at this stage of the ICE-UDP negotiation).

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

(In accordance with Jingle core, the responder will also acknowledge the transport-info message.)

In the unlikely event that one of the parties determines that it cannot establish connectivity even after sending and checking lower-priority candidates, it SHOULD terminate the session as described in XEP-0166.

@@ -1046,12 +1069,20 @@ Romeo Gateway Juliet - - - + + + + + + + + @@ -1071,8 +1102,6 @@ Romeo Gateway Juliet - - @@ -1087,6 +1116,16 @@ Romeo Gateway Juliet + + + + + + + + + +
Namerport value in a=candidate line 8998
rem-addrA IP address for a remote address as defined in &icecore;.connection-address value in a=remote-candidates line192.0.2.1
rem-portThe port for a remote address as defined in &icecore;.port value in a=remote-candidates line3478
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.