From be61bf7e89fcc260074c55e5e45a26965e52ecd3 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 31 Oct 2006 20:42:35 +0000 Subject: [PATCH] 0.3 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@142 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0177.xml | 34 +++++++++++++--------------------- 1 file changed, 13 insertions(+), 21 deletions(-) diff --git a/xep-0177.xml b/xep-0177.xml index 027e8f71..e38baca6 100644 --- a/xep-0177.xml +++ b/xep-0177.xml @@ -28,9 +28,9 @@ &seanegan; 0.3 - 2006-10-30 + 2006-10-31 psa - Added informational messages; mentioned that the Raw UDP candidate is conceptually equivalent to the concept of an in-use candidate from the ICE specification; added reference to RFC 4347. + Added informational messages; clarified connectivity checks and acceptance process; mentioned that the Raw UDP candidate is conceptually equivalent to the concept of an in-use candidate from the ICE specification; added reference to RFC 4347. 0.2 @@ -79,7 +79,10 @@ ]]> -

Once the session is provisionally accepted, each entity should send one &TRANSPORT; element in a transport-info meessage, containing exactly one &CANDIDATE; element per channel, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that channel. This is not necessarily the initiator's preferred address for communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. To determine reachability, the client needs classify ahead of time the permissiveness of the NAT or firewall it is behind, if any. If the NAT is symmetric (not permissive), the candidate SHOULD specify a relay address. Otherwise it SHOULD be an address derived via prior discovery using &rfc3489;, which will be an address on the outside of the firewall or NAT.

+ + I'll use the example of a voice chat (only one content type) to simplify .... (1) I send you a session request with (say) one description and two transports and (2) if you want to proceed, you provisionally accept the request (IQ result), then (3) we both start exchanging possible transport candidates as quickly as possible because end users hate to wait for the voice chat to start; (4) as soon as you find a candidate that will work, you send me a session-accept and we start sending mediate over that candidate; (5) if later on we discover a better candidate, we do a transport-modify or content-modify in order to switch to the better candidate + +

Once the session is provisionally accepted, each entity SHOULD send one &TRANSPORT; element in a transport-info meessage, containing exactly one &CANDIDATE; element per channel, whose 'ip' and 'port' attributes specify the IP address and port number of the candidate that the initiator has reason to believe will be most likely to succeed for that channel. This is not necessarily the initiator's preferred address for communication, but instead is the "address most likely to succeed", i.e., the address that is assumed to be reachable by the vast majority of target entities. To determine reachability, the client needs classify ahead of time the permissiveness of the NAT or firewall it is behind, if any. If the NAT is symmetric (not permissive), the candidate SHOULD specify a relay address. Otherwise it SHOULD be an address derived via prior discovery using &rfc3489;, which will be an address on the outside of the firewall or NAT.

Note: The Raw UDP candidate is equivalent to the "in-use" candidate as described in &ice;. (In older versions of XEP-0166, this was referrred to as the "default candidate".)

@@ -94,29 +97,18 @@ ]]>

The 'generation', 'ip', 'name', and 'port' attributes are REQUIRED. The 'name' attribute specifies the name of the channel and the 'generation' attribute provides a tracking mechanism for determining which version of this candidate is in force (this is useful if the candidate is redefined mid-stream, for example if the port is changed).

-

Either entity may send this transport-info message at any time, after which the recipient should attempt to send data to the specified address. If the data can be delivered, the recipient MUST send a Jingle transport-accept, content-accept, or session-accept action to the initiator.

+

Either entity may send this "transport-info" action at any time, after which the recipient should attempt to send media data to the specified address (either entity MAY also send the Informational Messages described below). If media data can be delivered for the candidate, the recipient MUST send a Jingle "transport-accept" action to the initiator (either explicitly, or implicitly via a "content-accept" or "session-accept" action.

- - ]]> - - - - ]]> - - + sid='a73sjjvkla37jfea'> + + + + + ]]>

The initiator MUST then acknowledge acceptance by returning an IQ result (or return a standard XMPP error).