VoLTE SIP Call Flow from a Real LTE Capture

The SIP layer of the LTE attach and VoLTE walkthrough, followed on its own. SIP normally hides inside IPsec, but in this capture the IPsec encrypts nothing, so every header and SDP line reads in the clear. UE 70 registers with IMS, then places call 1 to UE 71. One annotated diagram captions all 39 messages, with one lane each for the two phones, the P-CSCF, and the media relay.

💡 Read the walkthrough and the diagram side by side: open the interactive diagram in a split-screen window, or open it in a new tab and snap the two windows side by side.

Where SIP sits

SIP (Session Initiation Protocol, RFC 3261) sets up, changes, and ends calls. In VoLTE it runs between the phone and the IMS core (IP Multimedia Subsystem), whose entry point is the P-CSCF (Proxy Call Session Control Function). To the LTE network, SIP is ordinary user data: IP packets on the IMS bearer, DRB 2, which the radio carries without looking inside.

The capture is the same srsRAN eNB log as the main walkthrough, in its re-tagged form. srsRAN marks every frame with UE identity 0, and then Wireshark mixes the two phones' RLC state and fails to reassemble any SIP message that RLC split. The copy used here sets each frame's identity to its C-RNTI and changes nothing else. Why the capture was re-tagged explains the fix.

Three things make the SIP readable. Radio ciphering is EEA0 (null), so the user plane needs no keys. The IMS IPsec chooses ealg=null, so ESP encrypts nothing. And Wireshark's ESP null-encryption heuristic, turned on for this decode, parses what ESP carries. The diagram keeps only the SIP messages and five RTP packets, with their original frame numbers.

The cast

The srsRAN capture header is a bare UDP header with no IP layer, so the only IP addresses in the file belong to the phones' own packets. They identify each party directly:

Two more nodes appear only inside SIP headers: the S-CSCF (Serving CSCF) at 172.22.0.20 port 6060, which registers the users and routes their calls, and a node at 172.22.0.19 port 4060 that the INVITE visits on its way to UE 71.

Registration: IMS-AKA and the security agreement

Before it can call, UE 70 must register: prove who it is, and set up IPsec with the P-CSCF so later SIP can't be forged. IMS does both in two rounds of REGISTER (TS 24.229, TS 33.203).

Frame 42 — REGISTER in the clear. UE 70 opens TCP from port 49294 to the P-CSCF's port 5060 and sends a 1,609-byte REGISTER in two segments. It names the subscriber by the private identity 001011234567895@ims.mnc001.mcc001.3gppnetwork.org, in the format TS 23.003 derives from the IMSI. Its Authorization header has an empty nonce and response. It only says which identity to challenge. Require: sec-agree asks for the security agreement of RFC 3329, and Security-Client lists what the phone supports:

All four offers carry the same UE parameters: protected client port port-c=53360, protected server port port-s=55092, and SPIs spi-c=229971928 and spi-s=173156976. An SPI (Security Parameter Index) is the number at the front of each ESP packet that tells the receiver which security association (SA) to check it against.

Frame 48 — the IMS-AKA challenge. 25 ms later the S-CSCF (Server: Kamailio S-CSCF) answers 401 Unauthorized. The rejection is the point: it carries the challenge. Two headers do the work.

• WWW-Authenticate uses algorithm=AKAv1-MD5 (RFC 3310), and its nonce is base64 for 32 bytes: the 16-byte RAND and 16-byte AUTN of an AKA challenge, the same mechanism the network uses at attach. The SIM card (its ISIM or USIM application) checks AUTN to authenticate the network, computes a response RES, and derives two keys, CK and IK. Under TS 33.203 the S-CSCF hands the same keys to the P-CSCF inside this 401, and the P-CSCF strips them before forwarding it.
• Security-Server is the P-CSCF's choice: alg=hmac-sha-1-96 with ealg=null, offer 4. It adds the P-CSCF's own half: port-c=5100, port-s=6100, spi-c=4096, spi-s=4097.

The P-CSCF chose null encryption although the phone offered AES-CBC. The SAs will check that each SIP message is genuine and unaltered, but anyone on the path can read them. That choice, plus EEA0 on the radio, makes this page possible.

Frame 63 — the protected REGISTER. With both halves known, each side builds four SAs keyed with IK. UE 70 closes the first TCP connection and opens a new one inside ESP, from port 53360 to port 6100. The second REGISTER goes up 335 ms after the 401 and carries three proofs:

• Authorization holds the AKA answer: the same nonce, qop=auth, nc=00000001, and a digest response computed with RES as the password.
• Security-Client repeats the four offers, unchanged.
• Security-Verify echoes the P-CSCF's Security-Server back.

The copies guard against a man in the middle. The first exchange had no protection, so an attacker could have removed the strong offers and forced a weak one. Now the same lists travel under integrity protection, and the P-CSCF checks they match what it saw.

Frame 68 — registered. The 200 OK arrives 21 ms later, 2.25 s into the capture. P-Associated-URI gives the public identities the phone may now use, sip:0598765432100@ims.mnc001.mcc001.3gppnetwork.org and tel:0598765432100. Service-Route names the S-CSCF the phone must send its future requests through.

Four SAs, and the SPI each one carries

The IPsec is transport mode (mod=trans): ESP sits between the IP header and TCP or UDP. Each side has a client port, used to send its own requests, and a server port, where it receives requests. That gives four one-way SAs, and by the end of registration all four have carried traffic:

The rule to remember: the SPI on a packet is always the one its receiver chose, because the receiver uses it to look up the key. Each packet ends in a 12-byte ICV (Integrity Check Value), the 96 bits of hmac-sha-1-96. Wireshark leaves it unchecked, since it has no keys.

UE 71 registers the same way 16 s later, with six offers of its own, and gets its own SA set on P-CSCF ports 5101 and 6101 with SPIs 4098 and 4099.

Subscribing to its own registration

Frames 72–81 — SUBSCRIBE and NOTIFY. UE 70 subscribes to the reg event package (RFC 3680) for its public identity, so the network can tell it if its registration is ended or changed. The S-CSCF's NOTIFY (frame 78) carries an application/reginfo+xml body listing both public identities as active, with Subscription-State: active.

The SUBSCRIBE goes over UDP and the NOTIFY over TCP. The transport section below explains why.

Call 1, end to end

21 s after registering, UE 70 dials UE 71. The call takes 6.6 s from INVITE to the last 200 OK, and every message passes through the IMS core. This timeline also places the radio events, from the main walkthrough, on the same clock. Times are seconds from the start of the capture.

The INVITE's path through the core

The INVITE leaves UE 70 in frame 821 and reaches UE 71 in frame 827, 23 ms later. The Via headers on the delivered copy record every hop: P-CSCF, then the S-CSCF at 172.22.0.20, then the node at 172.22.0.19 port 4060, then the S-CSCF again, then the P-CSCF's port 5101 toward UE 71. Max-Forwards has dropped from 70 to 65.

That shape matches the standard IMS route for a call between two users of one network. The caller's S-CSCF can't know which S-CSCF serves the callee, so it asks an I-CSCF (Interrogating CSCF), which looks it up. Here one S-CSCF serves both phones, so the INVITE returns to it, and 172.22.0.19 is most likely that I-CSCF. Later requests in the dialog skip it: the PRACK's Via path is P-CSCF, S-CSCF, P-CSCF. Each proxy that wants to stay on the path added a Record-Route header to the INVITE, and every later request carries the resulting Route set.

The P-CSCF changed three things on the way through:

• It replaced the phone's P-Preferred-Identity with P-Asserted-Identity: <sip:0598765432100@ims.mnc001.mcc001.3gppnetwork.org>, an identity the network vouches for (RFC 3325).
• It removed Security-Verify and the sec-agree option tags. They only concern the phone and its P-CSCF. On the in-dialog PRACK, UPDATE, ACK, and BYE, though, the P-CSCF forwards them unchanged, and the far phone ignores them.
• It rewrote the SDP's media address, covered below.

The offer and the answer

SDP (Session Description Protocol, RFC 4566) describes the media. SIP carries it in an offer/answer exchange (RFC 3264): one side lists what it can do, the other picks. Here is UE 70's offer, verbatim from frame 821:

c=IN IP4 192.168.101.2
m=audio 49120 RTP/AVP 116 99 97 105 100
a=rtpmap:116 EVS/16000
a=fmtp:116 br=13.2; bw=nb-wb; max-red=220
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 max-red=0; mode-change-capability=2
a=rtpmap:97 AMR/8000
a=fmtp:97 max-red=0; mode-change-capability=2
a=rtpmap:105 telephone-event/16000
a=rtpmap:100 telephone-event/8000
a=ptime:20
a=inactive
a=des:qos mandatory local sendrecv
a=curr:qos local none
a=des:qos optional remote sendrecv
a=curr:qos remote none

The m= line offers payload types 116, 99, and 97, in order of preference: EVS (Enhanced Voice Services) at 13.2 kbit/s, AMR-WB (wideband), and AMR (narrowband). Types 105 and 100 carry keypad digits (telephone events). ptime:20 asks for 20 ms of audio per packet.

UE 71's answer, frame 839, keeps one codec:

c=IN IP4 192.168.101.3
m=audio 50020 RTP/AVP 99 105
a=rtpmap:99 AMR-WB/16000/1
a=fmtp:99 mode-change-capability=2;max-red=0
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
a=conf:qos remote sendrecv
a=inactive
a=ptime:20

AMR-WB, payload type 99, is the codec the voice uses for the rest of the call. The answer comes in a 183 Session Progress, not a 200 OK, because the call can't be answered yet: neither phone has a voice bearer.

Preconditions: no ringing until both bearers exist

Both phones list precondition in Supported, the QoS preconditions of RFC 3312. The idea is simple: the callee's phone must not ring until both ends have the network resources the call needs. Otherwise, a user could answer a call that has no voice path.

SDP tracks this with three attribute types. des is the desired state: which resources are needed, and how strongly (mandatory or optional). curr is the current state. conf asks the other side to confirm when its resources are ready. Each phone says local for its own end and remote for the far end. While any mandatory precondition is unmet, the media stays inactive.

The SIP methods follow from that table:

• The 183 must arrive. It carries the answer, so UE 71 sends it reliably (RFC 3262): Require: 100rel,precondition and RSeq: 1. UE 71 would resend it until acknowledged.
• PRACK acknowledges it. Frame 852 carries RAck: 1 1 INVITE: response number 1 of CSeq 1 INVITE. Its own 200 OK comes back in frame 866.
• UPDATE reports the bearer. UE 70's voice bearer has existed since frame 846, so in frame 872 it sends a new offer with curr:qos local sendrecv (RFC 3311 lets UPDATE change the session before the call is answered). The offer also switches the media to sendrecv and adds Require: precondition.
• The 200 OK to the UPDATE closes the last gap. UE 71's own bearer has existed since frame 844, so it answers with both ends sendrecv.
• Only then: 180 Ringing. It leaves UE 71 1.9 ms after the UPDATE's 200 OK. It has no RSeq, so it needs no PRACK.

The 180 and the UPDATE's 200 OK reach UE 70 in the reverse order (frames 891 and 892, 1.2 ms apart). They belong to different transactions, so the order doesn't matter. UE 71's user answers 1.64 s after the 180, and its 200 OK to the INVITE carries no SDP, since the media is already agreed. It does set a session timer (RFC 4028), Session-Expires: 1800;refresher=uac: UE 70 must refresh the session within 1,800 s or it ends. The ACK in frame 981 completes the INVITE handshake.

The UPDATE and its answer also set the RTCP bandwidth to zero, b=RS:0 and b=RR:0 (RFC 3556). RTCP is RTP's companion report protocol, and with zero bandwidth neither phone sends it: the capture contains no RTCP at all.

The P-CSCF rewrites the media address

Look at the SDP each phone receives, not the one it sent. Every c= line that crosses the P-CSCF is rewritten to 172.22.0.16, and every port changes:

The P-CSCF also adds a=rtcp:49001 and a=rtcp:49017, the relay's RTCP ports. The P-CSCF rewrites the UPDATE and its 200 OK the same way. So each phone thinks the other one lives at the relay, on a separate port. This is how an operator anchors media in its own network, in the role 3GPP gives an IMS access gateway controlled by the P-CSCF. The RTP proves the rewrite was obeyed:

The relay changes only the IP addresses and ports. SSRC (the stream's identifier), sequence numbers, and payload type 99 pass through untouched. Each phone sends to and receives from the same relay port, and neither ever sees the other's address. The first packet leaves UE 70 31 ms after its ACK. The RLC page follows these packets down to the radio.

Where the radio bearers land

The SIP never mentions bearers, yet it drives them. Each call gets a dedicated EPS bearer with QCI 1 (conversational voice, guaranteed bit rate) on both phones. For UE 70 in call 1 that is EPS bearer 7, carried as DRB 3 on logical channel 5 in RLC unacknowledged mode.

Setup. The first SDP answer, in UE 71's 183 (frame 839), is the trigger, as the timing shows. 8 ms after it leaves UE 71, the eNB is already reconfiguring UE 71 with the voice bearer (frame 844). UE 70 gets its bearer in frame 846, 0.8 ms after its own copy of the 183. The callee's bearer comes first in every call. In a standard EPC, the P-CSCF passes the negotiated media to the PCRF (Policy and Charging Rules Function) over the Rx interface, and the PCRF has the P-GW create the bearers (TS 23.203). This capture can't see that exchange, but the S1AP page shows the MME's E-RAB Setup Request leaving 7 ms after frame 839.

Hang-up. Only 9.4 ms after UE 71's BYE (frame 1143, Reason: SIP;text="USER DISCONNECTED"), the eNB removes UE 70's bearer (frame 1146), and UE 71's follows in frame 1147. UE 70's bearer is gone 20 ms before the BYE itself reaches UE 70 in frame 1149. The release most likely started at the P-CSCF, which saw the BYE first, while the BYE itself still had the S-CSCF to cross.

A voice packet after the bearer. 19 ms after the BYE arrives, UE 70's codec is still running and sends one more comfort-noise packet, RTP sequence 36 (frame 1152), to the relay. With DRB 3 and its packet filters gone, the packet falls through to the IMS default bearer and rides DRB 2, alongside the SIP. 9 ms later, UE 70's 200 OK to the BYE follows on the same bearer.

TCP or UDP

UE 70 uses both transports, and its choice follows one rule from RFC 3261 (§18.1.1): a request larger than 1,300 bytes, when the path MTU is unknown, must go over a congestion-controlled transport such as TCP. Every request in the diagram fits the rule:

IMS headers are long: the INVITE's headers alone are 1,474 bytes, before its 713-byte SDP. So most of this call runs over TCP, and RLC on DRB 2 sees large packets it must segment. The INVITE took four RLC PDUs (frames 817–821) and the PRACK three.

Responses follow the transport of their request. Over TCP they return on the same connection, as the 200 OK to the NOTIFY does (frame 81, port 55092 to 5100). Over UDP, the P-CSCF sends the 200 OK to the SUBSCRIBE to the port in the request's Via, UE 70's server port 55092. UE 70's own UDP response, the 200 OK to the BYE (frame 1154), behaves differently. The BYE came in from the P-CSCF's port 5100, and its top Via names that port, but UE 70 answers from its client port 53360 to the P-CSCF's server port 6100, on SPI 4097. The P-CSCF accepts it on that SA and forwards it to UE 71.

Takeaways

1. IMS registration is two REGISTERs by design. The first is challenged with IMS-AKA. The second answers the challenge inside IPsec, which the challenge itself made possible.
2. The security agreement is checked twice. Security-Client and Security-Server set up the SAs in the clear. Security-Verify and a repeated Security-Client confirm them under protection, so the strongest common suite can't be stripped out.
3. The SPI on a packet is the receiver's choice. Four SAs mean four SPIs, and each direction carries the one the receiving side picked.
4. Preconditions decide when the phone rings. The 183 carries the answer reliably, PRACK acknowledges it, UPDATE reports the bearer, and only after the last 200 OK does 180 Ringing go out.
5. The phones never see each other's address. The P-CSCF rewrites every SDP c= line to the media relay, and the relay forwards RTP with its SSRC and sequence numbers intact.
6. SIP drives the bearers. A QCI 1 bearer appears within 9 ms of the callee's 183 and disappears within 11 ms of the BYE, on both phones.

Where this sits in the stack

• An LTE Attach and a VoLTE Call on the Air Interface: the full walkthrough this page is a slice of, with every layer on one timeline.
• RLC-LTE Acknowledged and Unacknowledged Mode: the bearer under this SIP, DRB 2 in RLC acknowledged mode, and the call-1 voice on DRB 3.
• S1AP: Attach, E-RABs, and Six VoLTE Calls: the core network's side, including the E-RAB setup and release behind each voice bearer.
• IMS Registration Sequence Diagram: the same two-pass registration as a modeled flow, including the I-CSCF and S-CSCF steps this capture can't see.