| Protocol | ims | Network | 5G and LTE |
|---|---|---|---|
| Spec | RFC 3261 / 3GPP TS 24.229 | Spec Section | SIP INVITE method and IMS session establishment |
| Direction | UE <-> IMS network | Message Type | SIP request method |
| Full message name | IMS SIP INVITE |
|---|---|
| Protocol | IMS |
| Technology | 5G and LTE |
| Common deployment | VoNR and VoLTE |
| Direction | UE <-> IMS network |
| Interface | Gm (UE <-> P-CSCF) with onward IMS routing |
| Signaling bearer / channel | IMS SIP signaling / Session-establishment SIP transaction |
| Typical trigger | UE starts a call, network delivers a call attempt, or an existing session needs a new offer. |
| Main purpose | Carries the offer to create a voice, video, or multimedia session and defines the core dialog that later SIP signaling follows. |
| Main specification | RFC 3261 / 3GPP TS 24.229, SIP INVITE method and IMS session establishment |
| Release added | See specification history |
| Procedures where used | IMS Mobile Originated Call, IMS Mobile Terminated Call, VoNR Mobile Originated Call, VoNR Mobile Terminated Call, VoLTE Mobile Originated Call |
INVITE is the SIP request that starts or modifies the main session dialog in IMS.
Carries the offer to create a voice, video, or multimedia session and defines the core dialog that later SIP signaling follows.
INVITE is the SIP request that starts the IMS session itself.
Call flow position: The opening SIP request for the call session.
Typical state: UE is registered in IMS and is asking to start a session.
Preconditions:
Next likely message: Provisional or final SIP response
Call flow position: The opening session request delivered toward the called side.
Typical state: A terminating dialog branch is being created in IMS.
Preconditions:
Next likely message: Provisional alerting or final acceptance
Previous message(s): IMS registration is active
Next message(s): 100 Trying, 180 Ringing, 183 Session Progress, 200 OK
Security context: Usually sent after IMS registration is already active and over the protected IMS access path.
INVITE sip:user@example.net SIP/2.0
Via:
From:
To:
Call-ID:
CSeq:
Contact:
Supported: OPTIONAL
Allow: OPTIONAL
Content-Type: OPTIONAL
Content-Length:
SDP body OPTIONAL
This is SIP message syntax. In practical IMS reading, the request line and SDP body matter more than any ASN.1-style view.
INVITE sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-inv1
From: <sip:alice@example.net>;tag=mo1
To: <sip:bob@example.net>
Call-ID: call-001@example.net
CSeq: 1 INVITE
Contact: <sip:alice@192.0.2.10:5060>
Content-Type: application/sdp
Content-Length: 129
v=0
o=- 1 1 IN IP4 192.0.2.10
s=-
c=IN IP4 192.0.2.10
t=0 0
m=audio 49170 RTP/AVP 96 0 8
a=rtpmap:96 AMR/8000
| IE | Required | Description |
|---|---|---|
Request-URI | Yes | Identifies the target user or service. |
From | Yes | Carries the originating identity. |
To | Yes | Carries the target identity. |
Call-ID | Yes | Creates the dialog correlation context. |
CSeq | Yes | Orders the INVITE transaction. |
Contact | Yes | Provides the reachable contact for the dialog. |
Content-Type | Optional | Usually indicates SDP when session parameters are carried. |
SDP body | Optional | Carries media offer details such as codecs, ports, and transport expectations. |
Request-URIIdentifies the target user or service.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
FromCarries the originating identity.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
ToCarries the target identity.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Call-IDCreates the dialog correlation context.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
CSeqOrders the INVITE transaction.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
ContactProvides the reachable contact for the dialog.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Content-TypeUsually indicates SDP when session parameters are carried.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
SDP bodyCarries media offer details such as codecs, ports, and transport expectations.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Likely cause: The INVITE may carry an unsupported route, identity, or SDP offer.
What to inspect: Check Request-URI, Route, Contact, and the full SDP body.
Next step: Compare the request with the first failure or rejection response.
Likely cause: The INVITE may already show the media mismatch that surfaces later in the session.
What to inspect: Read the original SDP offer before focusing only on the answer.
Next step: Compare the offer against the later 183 or 200 OK SDP.
REGISTER creates service reachability. INVITE creates the session dialog.
It starts the main session dialog and usually carries the media offer for the voice or multimedia session.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.