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.
Keep the answered 200 response distinct from earlier messages
Asterisk response-header functions expose fields from the 200 response to an outbound INVITE. The focused guide does not generalize that result to provisional responses, failures or later in-dialog requests.
Treat an Asterisk header list as one INVITE view
Use the PJSIP inbound-header inventory guide to distinguish unique names from repeated rows, values and other SIP messages.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261 — SIP, including linked updates ↗
- IETF RFC 8866 — Session Description Protocol ↗
- Asterisk PJSIP_RESPONSE_HEADER dialplan function ↗
- Asterisk PJSIP_RESPONSE_HEADERS dialplan function ↗
- Asterisk pre-bridge handlers ↗
- Asterisk 22 Dial application ↗
- Asterisk res_pjsip header-function source ↗
- RFC 3261: SIP Session Initiation Protocol ↗
- Asterisk PJSIP_HEADERS dialplan function ↗
- Asterisk PJSIP_HEADER dialplan function ↗