Clarified several small points regarding candidate gathering procedures and STUN connectivity checks.
The first step in negotiating connectivity is for each party to immediately begin sending transport candidates to the other party.
The first step in negotiating connectivity is for each party to immediately begin sending transport candidates to the other party.
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.
@@ -392,8 +398,8 @@ INITIATOR RESPONDER priority='1694498815' protocol='udp' pwd='asd88fgpdd777uzjYhagZg' - raddr='10.0.1.1' - rport='8998' + rel-addr='10.0.1.1' + rel-port='8998' type='srflx' ufrag='8hhy'/> @@ -459,7 +465,7 @@ INITIATOR RESPONDERWhen 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.
@@ -522,7 +528,7 @@ INITIATOR NAT RESPONDERFirst the initiator sends a Jingle content-modify action to the responder. The content-modify MUST contain information about the nominated pair, including the "rem-addr" and "rem-port" attributes (which specify the IP address and port for the responder's end of the pair, which is a "remote address" according to the initiator).
+First the initiator sends a Jingle content-modify action to the responder. The content-modify MUST contain information about the nominated pair, including the "rem-addr" and "rem-port" attributes (which specify the IP address and port for the responder's end of the pair, which is a "remote address" according to the initiator). This enables both parties to explicitly agree to both ends of the connection pair (i.e., the local address+port and the remote address+port).
Thanks to Steffen Larsen for his helpful feedback.
+