| Protocol | ims | Network | 5G and LTE |
|---|---|---|---|
| Spec | RFC 3261 / 3GPP TS 24.229 | Spec Section | SIP ACK method and INVITE confirmation |
| Direction | UE <-> IMS network | Message Type | SIP request method |
| Full message name | IMS SIP ACK |
|---|---|
| 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 / INVITE follow-up transaction control |
| Typical trigger | A 2xx final response to INVITE is received and must be confirmed. |
| Main purpose | Closes the successful INVITE transaction and confirms that the session can move from setup into active dialog handling. |
| Main specification | RFC 3261 / 3GPP TS 24.229, SIP ACK method and INVITE confirmation |
| 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, VoLTE Mobile Terminated Call |
ACK is the SIP request that confirms a final response to INVITE.
Closes the successful INVITE transaction and confirms that the session can move from setup into active dialog handling.
ACK confirms the successful INVITE result so the session can move into active dialog state.
Call flow position: Session-confirmation step after the final INVITE acceptance.
Typical state: The session is about to become active.
Preconditions:
Next likely message: Media flow, UPDATE, INFO, or BYE
Previous message(s): 200 OK to INVITE
Next message(s): RTP media or later in-dialog SIP methods
Security context: Sent inside an already active IMS dialog context after the final INVITE response is accepted.
ACK sip:user@example.net SIP/2.0
Via:
From:
To:
Call-ID:
CSeq:
Route: OPTIONAL
Content-Length:
ACK is a SIP transaction message used to confirm the INVITE result, not an ASN.1-defined structure.
ACK sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-ack1
From: <sip:alice@example.net>;tag=mo1
To: <sip:bob@example.net>;tag=term1
Call-ID: call-001@example.net
CSeq: 1 ACK
Content-Length: 0
| IE | Required | Description |
|---|---|---|
Request-URI | Yes | Identifies the dialog target for the acknowledgment. |
Via | Yes | Carries the transport branch for the ACK path. |
Call-ID | Yes | Binds ACK to the established INVITE dialog. |
CSeq | Yes | Carries the INVITE sequence number with the ACK method. |
Route | Optional | Preserves the dialog route set when needed. |
Request-URIIdentifies the dialog target for the acknowledgment.
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.
ViaCarries the transport branch for the ACK path.
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-IDBinds ACK to the established INVITE 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.
CSeqCarries the INVITE sequence number with the ACK method.
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.
RoutePreserves the dialog route set when needed.
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 final response may have been sent, but the ACK path was lost or mismatched.
What to inspect: Check whether ACK was generated, routed, and correlated to the same dialog identifiers.
Next step: Compare ACK against the final INVITE response rather than debugging only media.
It confirms the final response to INVITE and closes the successful INVITE transaction.
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.