Clarified protocol flow.
The overall protocol flow for negotiation of the Jingle Raw UDP Transport Method is as follows (note: many of these events happen simultaneously, not in sequence).
+|
+ | ack |
+ |<-----------------------------------|
+ | session-info: trying |
+ |<-----------------------------------|
+ | ack |
+ |----------------------------------->|
+ | transport-info: candidate |
+ |<-----------------------------------|
+ | ack |
+ |----------------------------------->|
+ | session-info: received |
+ |----------------------------------->|
+ | ack |
+ |<-----------------------------------|
+ | session-accept |
+ |<-----------------------------------|
+ | ack |
+ |----------------------------------->|
+ |<========MEDIA NOW FLOWS===========>|
+ | |
+ ]]>
+ 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. This stanza MUST include at least one content type. If the initiator wishes to negotiate the Raw UDP transport for a given content type, it MUST include a &TRANSPORT; child element qualified by the 'urn:xmpp:jingle:transports:raw-udp:0' namespace &VNOTE;, which MUST
The 'generation', 'ip', and 'port' attributes are REQUIRED. The 'ip' and 'port' attributes are self-explanatory. 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).
+All attributes are REQUIRED. The 'ip' and 'port' attributes are self-explanatory. 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). The 'id' attribute uniquely identifies this candidate for tracking purposes.
Note: The "Raw UDP candidate" is the candidate that the entity has reason to believe will be most likely to succeed for that content type, and thus is equivalent to the "default" candidate as described in &ice;. This is not necessarily the entity'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 sender needs to classify ahead of time the permissiveness of the NAT or firewall it is behind, if any. It then SHOULD assign the Raw UDP candidate as follows, where the candidate types are as described in ICE: