The SIP INVITE request starts an IMS multimedia session. In VoLTE and other IMS call flows, this message carries the called party, routing information, originating UE identity, service capability, and the SDP offer that describes the media streams requested for the session.
This page focuses on the INVITE message content itself. Use it to identify which headers control SIP routing, which headers describe IMS service behavior, and how the SDP body describes audio, video, or application media.
Contents
Main INVITE Message
This example shows an INVITE with a SIP header section followed by an SDP offer. The SIP header section identifies the call target, route, UE contact, supported features, and transaction identifiers. The SDP section gives the media and session parameters that the terminating side will accept, reject, or modify in the answer.
[ Line 1 ] INVITE sip:+10123456789@ims.sharetechnote.com SIP/2.0
[ Line 2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3298736468smg;transport=UDP
[ Line 3 ] Supported: 100rel,timer
[ Line 4 ] Allow: INVITE, ACK, CANCEL, UPDATE, BYE
[ Line 5 ] P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=0000054200000000
This SIP message clip highlights the following parameters: Via, P-Access-Network-Info, Supported, Allow. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
[ Line 8 ] Session-Expires: 1800;refresher=uac
[ Line 9 ] Content-Type: application/sdp
[ Line 10 ] Route: <sip:192.168.1.2:5060;lr>
[ Line 11 ] Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
[ Line 12 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293
[ Line 13 ] To: <sip:+10123456789@ims.sharetechnote.com>
[ Line 14 ] Call-ID: 131949458@192.168.1.15
[ Line 15 ] CSeq: 1 INVITE
[ Line 16 ] Max-Forwards: 70
[ Line 17 ] Contact: <sip:+11234567890@192.168.1.15:5060;transport=UDP>;
This SIP message clip highlights the following parameters: Route, Contact, CSeq, Call-ID, From, To, Content-Type, Session-Expires, Accept-Contact, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
[ Line 18 ] Content-Length: 387
This SIP message clip highlights the following parameters: Content-Length. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
[ Line 19 ] v=0
[ Line 20 ] o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
[ Line 21 ] s=SDP Seminar
[ Line 22 ] i=A Seminar on the session description protocol
[ Line 24 ] e=mjh@isi.edu (Rob)
[ Line 25 ] c=IN IP4 224.2.17.12/127
[ Line 26 ] t=2873397496 2873404696
[ Line 27 ] a=recvonly
[ Line 28 ] m=audio 49170 RTP/AVP 0
[ Line 29 ] m=video 51372 RTP/AVP 31
[ Line 30 ] m=application 32416 udp wb
This INVITE clip highlights Request-URI, Via, Supported, Allow, P-Access-Network-Info, User-Agent, Session-Expires, Content-Type, Route, Accept-Contact, From, To, Call-ID, CSeq, Max-Forwards, Contact, Content-Length, and the SDP fields v, o, s, i, u, e, c, t, a, and m. The most useful SIP troubleshooting parameters are Request-URI and Route for routing, From and To for dialog identity, Call-ID and CSeq for transaction tracking, Contact for the UE signaling address, and Content-Type/Content-Length for the SDP body.
Note : Line 19-31 is from the example in RFC 2327
Request-Line and SIP Headers
The first part of the INVITE controls SIP routing and dialog setup. These headers tell the IMS core where the request is going, where responses should return, what features the UE supports, and which service or media capability the call is trying to use.
- Called Number : +10123456789
- Destination domain or router : ims.sharetechnote.com
- SIP version : 2.0
This SIP message clip highlights the following parameters: Via. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
The Via header identifies the UE transport endpoint and branch value for this transaction. The response follows this path back toward the UE.
This SIP message clip highlights the following parameters: Session-Expires. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Session-Expires sets the session timer to 1800 seconds and marks the UE as the refresher. This controls how the dialog is refreshed after the call is established.
This SIP message clip highlights the following parameters: Accept-Contact. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Accept-Contact carries the IMS Communication Service Identifier feature tag. In this example, +g.3gpp.icsi-ref indicates the IMS multimedia telephony service.
This SIP message clip highlights the following parameters: Call-ID. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Call-ID uniquely identifies the SIP dialog together with From and To tags. It is one of the first fields to correlate when comparing UE, P-CSCF, and application-server traces.
This SIP message clip highlights the following parameters: Contact. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Contact gives the UE signaling address for subsequent in-dialog requests. The +g.3gpp.icsi-ref parameter repeats the IMS service identity associated with the INVITE.
SDP Body
The SDP body is the media offer carried by the INVITE. It describes the SDP version, origin, session identity, connection address, active time, media direction, and each offered media stream.
This SIP message clip highlights the following parameters: v. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
The v field indicates the SDP version. In normal SDP this value is 0.
This SIP message clip highlights the following parameters: o. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
The o field gives the originator, session identifier, version, network type, address type, and address. It changes when the SDP offer changes.
This SIP message clip highlights the following parameters: s. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
The s field gives the session name. In IMS traces this may be generic, but the field is still part of the SDP session-level information.
This SIP message clip highlights the following parameters: c. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
The c field gives connection information. When it is present at session level, media streams can inherit this address unless they provide their own media-level connection line.
This SIP message clip highlights the following parameters: a. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
The a field carries an SDP attribute. Here, recvonly indicates that the endpoint expects to receive media only for the described session or stream.
This SIP message clip highlights the following parameters: m. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
- audio means this media line describes an audio stream.
- 49170 indicates the RTP port used for the audio stream.
- RTP/AVP 0 indicates RTP Audio/Video Profile payload type 0, normally PCMU.
This SIP message clip highlights the following parameters: m. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
- video means this media line describes a video stream.
- 51372 indicates the RTP port used for the video stream.
- RTP/AVP 31 indicates RTP Audio/Video Profile payload type 31.
This SIP message clip highlights the following parameters: m. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
The m=application line describes an application media stream, including the transport protocol and format token.
This SIP message clip highlights the following parameters: a. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
The a=orient attribute gives orientation information for the media stream. In this example the value is portrait.
Additional INVITE Request-URI Examples
These examples show alternative Request-URI forms. The first targets an IP address and port directly, while the second uses phone-context and user=phone parameters to express a telephone-number style destination.
Example 1 : INVITE sip:1234567890@192.168.1.2:5060 SIP/2.0
Example 2 : INVITE sip:0123456789;phone-context=one.att.net@one.att.net;user=phone
This partial INVITE clip highlights the Request-URI parameterization. The user part identifies the called number, the host part identifies the destination domain or address, phone-context qualifies the numbering context, and user=phone tells SIP entities to treat the user portion as a telephone number.