| Protocol | ims | Network | 5G and LTE |
|---|---|---|---|
| Spec | RFC 6665 / 3GPP TS 24.229 | Spec Section | SIP SUBSCRIBE method and event subscription handling |
| Direction | UE <-> IMS network | Message Type | SIP request method |
| Full message name | IMS SIP SUBSCRIBE |
|---|---|
| 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 / Event-subscription control transaction |
| Typical trigger | The UE or service wants notification-based updates for a subscribed IMS event. |
| Main purpose | Lets one side ask for state-change notifications for a specific SIP event package. |
| Main specification | RFC 6665 / 3GPP TS 24.229, SIP SUBSCRIBE method and event subscription handling |
| Release added | See specification history |
| Procedures where used | IMS Event Subscription, Presence and Service State Subscription |
SUBSCRIBE is the SIP request that creates or refreshes a subscription to an event package.
Lets one side ask for state-change notifications for a specific SIP event package.
SUBSCRIBE asks the far side to send future event updates.
Call flow position: Opening or refresh step for subscription-based service state.
Typical state: The sender is establishing interest in future event notifications.
Preconditions:
Next likely message: 200 OK and later NOTIFY
Previous message(s): IMS registration is active
Security context: Usually sent after IMS registration is already valid and with policy checks appropriate to the event package.
SUBSCRIBE sip:user@example.net SIP/2.0
Via:
From:
To:
Call-ID:
CSeq:
Event:
Expires: OPTIONAL
Contact: OPTIONAL
Content-Length:
SUBSCRIBE is SIP subscription syntax. The most useful fields are Event and Expires.
SUBSCRIBE sip:presence@example.net SIP/2.0
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-sub1
From: <sip:alice@example.net>;tag=sub1
To: <sip:presence@example.net>
Call-ID: sub-001@example.net
CSeq: 1 SUBSCRIBE
Event: presence
Expires: 3600
Content-Length: 0
| IE | Required | Description |
|---|---|---|
Event | Yes | Identifies the subscribed event package. |
Expires | Optional | Requests the subscription lifetime. |
Call-ID | Yes | Correlates the subscription dialog. |
CSeq | Yes | Orders the SUBSCRIBE transaction. |
EventIdentifies the subscribed event package.
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.
ExpiresRequests the subscription lifetime.
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.
Call-IDCorrelates the subscription 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.
CSeqOrders the SUBSCRIBE 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.
Likely cause: The event package may be wrong, the lifetime may be too short, or the NOTIFY path may fail later.
What to inspect: Check Event, Expires, and the subsequent NOTIFY transaction.
Next step: Trace the subscription as a SUBSCRIBE plus NOTIFY pair, not as an isolated request.
It creates or refreshes a subscription so later NOTIFY requests can report event-state changes.
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.