RFC3261 assumes two situations when more than one INVITE may be part of the same dialog:
- the initial INVITE is not accepted without authentication, so the recipient (the UAS) rejects it with a 401 or 407 with an authentication challenge header, and the sender (the UAC) must repeat the request with a matching authentication response; the repeated INVITE is then processed if the response is correct, and is considered an initial one from the point of view of the dialog and session established
- the initial INVITE is accepted but during the call one of the peers needs to renegotiate the media; to do so, it sends a so-called re-INVITE carrying a new SDP offer (or one without an SDP which should trigger the recipient to send its own SDP offer in 200, and the sender would then answer that offer using an SDP in the ACK).
A re-INVITE is easily distinguishable from an initial INVITE by presence of a tag in the To: header.
Another possibility would be that the request (in this case, INVITE) did not make it to the recipient, or the recipient's response did not make it back to the sender of the request; in either case, the sender retransmits the request several times until it considers it failed.
