3.1.5.2.1.1 Processing the STUN Binding Request

If a Simple Traversal of UDP through NAT (STUN) binding request message is received before the remote candidates are received from the peer endpoint in the offer and answer, the endpoint MUST validate the request. If the request is invalid, the endpoint SHOULD send a binding error response for the STUN binding request message, as specified in section 3.1.5.2.1.2. If the request is valid, the endpoint MUST send a STUN binding response message, as specified in section 3.1.5.2.1.3. In addition, the STUN binding request message MUST be cached. When the peer endpoint's candidates are received and candidate pairs are formed, the cached requests MUST be processed and the candidate pair states MUST be updated accordingly. Additional responses or error responses MUST NOT be sent for the cached requests because they have already been acknowledged.

If a STUN binding request message is received after the remote candidates have been received from the peer in an offer and answer, or if a cached request is being processed, the USERNAME attribute in the STUN binding request message is used to identify the transport address pair for which the STUN binding request message was sent, by comparing the complete USERNAME in the STUN binding request message with each transport pair identifier. This transport address pair is called the matching transport address pair for that STUN binding request message. If no matching transport address pair is found, the STUN binding request message MUST be discarded. The corresponding candidate pair, to which the transport address pair belongs, is called the matching candidate pair. If the matching transport address pair is already in the "Invalid" state, the STUN binding request message MUST be discarded.