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.
The STUN Binding Requests generated by the initiator MUST include the ICE-CONTROLLING attribute.
The STUN Binding Requests generated by the responder MUST include the ICE-CONTROLLED attribute.
- The parties MUST use STUN short term credentials to authenticate requests and perform message integrity checks. As in &icecore;, the username in the STUN Binding Request is of the form "ufrag-of-sender:ufrag-of-peer" and the password is the value of the 'pwd' attribute provided by the peer. Thus when Romeo sends a STUN Binding Request to Juliet the credentials will be STUN username "8hhy:9uB6" and password "YH75Fviy6338Vbrhrlp8Yh" whereas when Juliet sends a STUN Binding Request to Romeo the credentials will be STUN username "9uB6:8hhy" and password "asd88fgpdd777uzjYhagZg".
+ The parties MUST use STUN short term credentials to authenticate requests and perform message integrity checks. As in &icecore;, the username in the STUN Binding Request is of the form "ufrag-of-peer:ufrag-of-sender" and the password is the value of the 'pwd' attribute provided by the peer. Thus when Romeo sends a STUN Binding Request to Juliet the credentials will be STUN username "9uB6:8hhy" (ufrag provided by Juliet concatenated with ufrag provided by Romeo) and password "YH75Fviy6338Vbrhrlp8Yh" (pwd provided by Juliet) whereas when Juliet sends a STUN Binding Request to Romeo the credentials will be STUN username "8hhy:9uB6" (ufrag provided by Romeo concatenated with ufrag provided by Juliet) and password "asd88fgpdd777uzjYhagZg" (pwd provided by Romeo).
When it receives a STUN Binding Request, each party MUST return a STUN Binding Response, which indicates either an error case or the success case. As described in Section 7.1.2.2 of &icecore;, a connectivity check succeeds if all of the following are true: