IMS SIP MESSAGE | IMS Message

Message Fact Sheet

Protocol	ims	Network	5G and LTE
Spec	RFC 3428 / 3GPP TS 24.229	Spec Section	SIP MESSAGE method and standalone message transport
Direction	UE <-> IMS network	Message Type	SIP request method

Full message name	IMS SIP MESSAGE
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 / Standalone SIP messaging transaction
Typical trigger	A service wants to send message content as a standalone SIP transaction.
Main purpose	Lets one side send discrete message content over SIP without treating it as a full voice or multimedia session.
Main specification	RFC 3428 / 3GPP TS 24.229, SIP MESSAGE method and standalone message transport
Release added	See specification history
Procedures where used	IMS Standalone Messaging

What is IMS SIP MESSAGE in simple terms?

MESSAGE is the SIP request used to carry standalone message content without creating a full session dialog.

Lets one side send discrete message content over SIP without treating it as a full voice or multimedia session.

Why this message matters

MESSAGE carries standalone content over SIP without opening a full call session.

Where this message appears in the call flow

IMS standalone messaging

Call flow position: Main request carrying the standalone message content.

Typical state: The sender wants to deliver content without opening a full session dialog.

Preconditions:

IMS service reachability is already available.

Next likely message: 200 OK

Standalone pager-mode message

IMS SIP MESSAGE flow carrying a standalone pager-mode text or service payload through the IMS core — In a standalone messaging path, MESSAGE carries user or service payload without creating a persistent dialog.

Service message over IMS

IMS SIP MESSAGE flow carrying service-related payload across the IMS path — In a service-messaging path, MESSAGE carries application content across IMS without behaving like a full call-setup request.

Call flow position

Previous message(s): IMS registration is active

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 standalone messaging

Signaling bearer: IMS SIP signaling

Logical channel: Standalone SIP messaging transaction

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

Security context: Usually sent over the normal IMS access path after service reachability is already available.

Message Structure Overview

MESSAGE is easiest to read as a standalone transaction plus body content.

ASN.1 Message Syntax for IMS SIP MESSAGE

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

Message body

How to read this message syntax

MESSAGE is SIP standalone messaging syntax. The payload format and body usually matter more than dialog state.

IMS SIP MESSAGE - Example Dump

MESSAGE sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-msg1
From: <sip:alice@example.net>;tag=msg1
To: <sip:bob@example.net>
Call-ID: msg-001@example.net
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 12

Hello world

How to read this dump

The key question is whether the content type and body match the intended service behavior.

Important Information Elements

IE	Required	Description
`Content-Type`	Yes	Identifies the body format being carried.
`Message body`	Yes	Carries the standalone message content.
`Call-ID`	Yes	Correlates the standalone transaction.

Detailed field explanation

`Content-Type`

Identifies the body format being carried.

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.

`Message body`

Carries the standalone message content.

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

Correlates the standalone 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.

What to check in logs and traces

Inspect Content-Type first.
Check the message body and target identity.
Correlate the request with the final response.

Common Issues and Troubleshooting

The message request succeeds but the service meaning is still wrong.

Likely cause: The body or content type may not match what the receiving application expects.

What to inspect: Check the body format, target identity, and final response together.

Next step: Treat MESSAGE as an application-carrying SIP transaction, not only as routing signaling.

FAQ

What does MESSAGE do in IMS?

It sends standalone message content as a SIP transaction without creating a full dialog like INVITE does.

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.