IMS SIP INFO | IMS Message

Message Fact Sheet

Protocol	ims	Network	5G and LTE
Spec	RFC 6086 / 3GPP TS 24.229	Spec Section	SIP INFO method and mid-session information transfer
Direction	UE <-> IMS network	Message Type	SIP request method

Full message name	IMS SIP INFO
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 / In-dialog service-information transaction
Typical trigger	The active session needs in-dialog service information or control data that does not require a new INVITE.
Main purpose	Lets one side transfer service information during an active dialog without treating it as a new session setup.
Main specification	RFC 6086 / 3GPP TS 24.229, SIP INFO method and mid-session information transfer
Release added	See specification history
Procedures where used	IMS In-Dialog Service Control

What is IMS SIP INFO in simple terms?

INFO is the SIP request used to carry mid-session information inside an existing dialog.

Lets one side transfer service information during an active dialog without treating it as a new session setup.

Why this message matters

INFO carries extra service information inside an existing SIP dialog.

Where this message appears in the call flow

IMS in-dialog service control

Call flow position: Mid-session information transfer step.

Typical state: The dialog is active and only additional service information needs to be sent.

Preconditions:

A valid SIP dialog already exists.

Next likely message: 200 OK

Mid-call DTMF relay

IMS SIP INFO flow carrying DTMF or similar mid-call user input across an established dialog — In a DTMF relay path, INFO carries mid-call user input without changing the main session dialog.

Mid-session service-control payload

IMS SIP INFO flow carrying mid-session service-control information across an established IMS dialog — In a mid-session control path, INFO carries service information inside an existing dialog without rebuilding the session.

Call flow position

Previous message(s): Established SIP dialog

Next message(s): 200 OK

Message direction and transport

Sender and receiver: UE <-> IMS network

Interface: Gm (UE <-> P-CSCF) with onward IMS routing

Domain: IMS mid-session service control

Signaling bearer: IMS SIP signaling

Logical channel: In-dialog service-information transaction

Transport / encapsulation: SIP over UDP, TCP, or TLS

Security context: Sent inside an already established dialog.

Message Structure Overview

INFO is an in-dialog method. The useful reading path is dialog identity first, then the package and body.

ASN.1 Message Syntax for IMS SIP INFO

INFO sip:user@example.net SIP/2.0
Via:
From:
To:
Call-ID:
CSeq:
Info-Package:                      OPTIONAL
Content-Type:                      OPTIONAL
Content-Length:

Info body                          OPTIONAL

How to read this message syntax

INFO is SIP in-dialog transport syntax. The package name and body semantics matter more than an ASN.1-style view.

IMS SIP INFO - Example Dump

INFO sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-info1
From: <sip:alice@example.net>;tag=mo1
To: <sip:bob@example.net>;tag=term1
Call-ID: call-001@example.net
CSeq: 5 INFO
Info-Package: dtmf
Content-Type: application/dtmf-relay
Content-Length: 12

Signal=5

How to read this dump

INFO is usually only meaningful if you already know what package or service behavior is in play.

Important Information Elements

IE	Required	Description
`Info-Package`	Optional	Identifies the package of information being transported.
`Content-Type`	Optional	Identifies the format of the INFO body.
`Info body`	Optional	Carries the mid-session information content.
`Call-ID`	Yes	Binds INFO to the active dialog.

Detailed field explanation

`Info-Package`

Identifies the package of information being transported.

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.

`Content-Type`

Identifies the format of the INFO body.

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.

`Info body`

Carries the mid-session information content.

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-ID`

Binds INFO to the active 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.

What to check in logs and traces

Check that the dialog already exists.
Inspect Info-Package and Content-Type.
Read the body only after the service context is clear.

Common Issues and Troubleshooting

Mid-call service control behaves unexpectedly.

Likely cause: The INFO package or body may not match what the far side expects.

What to inspect: Check Info-Package, Content-Type, and the exact body content.

Next step: Compare the request with the service feature that triggered it.

FAQ

What does INFO do in IMS?

It transfers service information during an active dialog without starting a new session setup request.

Related Procedures

Related Tools

Use This Reference in Practice

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.