| Protocol | ims | Network | 5G and LTE |
|---|---|---|---|
| Spec | RFC 3261 / 3GPP TS 24.229 | Spec Section | SIP OPTIONS method and capability query handling |
| Direction | UE <-> IMS network | Message Type | SIP request method |
| Full message name | IMS SIP OPTIONS |
|---|---|
| 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 / Capability-query SIP transaction |
| Typical trigger | A node wants to verify supported methods, liveness, or reachable service capabilities without sending INVITE. |
| Main purpose | Lets one side ask what services, methods, or media capabilities the far side supports before or outside full session setup. |
| Main specification | RFC 3261 / 3GPP TS 24.229, SIP OPTIONS method and capability query handling |
| Release added | See specification history |
| Procedures where used | IMS Capability Query, Service Reachability Check |
OPTIONS is the SIP request used to query capabilities or liveness without creating a full session.
Lets one side ask what services, methods, or media capabilities the far side supports before or outside full session setup.
OPTIONS asks what the far side can do without starting a full session.
Call flow position: Query step outside a full session setup path.
Typical state: The sender wants capability information rather than a voice dialog.
Preconditions:
Next likely message: 200 OK
Previous message(s): IMS registration is active or service reachability is otherwise known
Next message(s): 200 OK
Security context: Usually sent over the existing IMS access path with the same routing and policy controls as other SIP methods.
OPTIONS sip:user@example.net SIP/2.0
Via:
From:
To:
Call-ID:
CSeq:
Accept: OPTIONAL
Content-Length:
OPTIONS is a SIP request method used for capability or liveness checks.
OPTIONS sip:service@example.net SIP/2.0
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-opt1
From: <sip:alice@example.net>;tag=opt1
To: <sip:service@example.net>
Call-ID: opt-001@example.net
CSeq: 1 OPTIONS
Accept: application/sdp
Content-Length: 0
| IE | Required | Description |
|---|---|---|
Request-URI | Yes | Identifies the target user or service being queried. |
Accept | Optional | Limits what type of capability description the sender wants back. |
Allow | Optional | Often used in responses to show supported methods. |
Request-URIIdentifies the target user or service being queried.
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.
AcceptLimits what type of capability description the sender wants back.
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.
AllowOften used in responses to show supported methods.
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: OPTIONS may confirm reachability without guaranteeing that the later INVITE offer will be accepted.
What to inspect: Compare the OPTIONS result against the later session-specific request and response pair.
Next step: Do not treat OPTIONS success as proof that media negotiation will also succeed.
It queries capabilities or liveness without creating a 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.