A request for a session
An initial INVITE asks another participant to establish a session. Its request URI, routing information and offered media parameters help determine where it goes and what the receiver can accept. An INVITE within an existing dialog can modify an established session, such as a media change.
Do not treat every INVITE in a trace as a new customer call. Retransmissions and in-dialog requests have different roles. Use transaction and dialog identifiers to understand which exchange you are reading.
A negotiated codec does not prove packet delivery. Check both session description and actual media packets.
Follow responses in order
Provisional responses indicate progress without final success. A final success response to INVITE is followed by ACK. A rejection should be interpreted on the leg that produced it, with any useful response details and associated SDP.
A PBX may originate a separate INVITE toward a carrier, using a different Call-ID. A failure on that leg can be translated into another response toward the phone. Follow both sides before attributing the failure to the handset.
Separate destination and media rejection
A request aimed at an unavailable destination raises routing and reachability questions. A request rejected because offered media cannot be accepted raises codec, SDP or encryption-policy questions. Changing a password will not repair every unsuccessful INVITE.
Capture a bounded example
Record dialed digits before normalization, the resulting destination, the selected route and the response source. Redact private identities before sharing. After a repair, test the original call and a related route, because a broad pattern change can fix one destination while breaking another.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.