VoLTE Call Connected but No Audio? Check SIP, SDP, and RTP Separately

 A connected-call indicator does not prove that usable audio is reaching the listener. I separate three questions: was the session established, what media conditions were negotiated, and what packets actually arrived? That separation helps narrow down a VoLTE no-audio problem without guessing the cause.

1. Which request received the 200 OK?

SIP controls session establishment, modification, and termination. A 200 OK for REGISTER is different from a 200 OK for INVITE. Identify the call using its Call-ID and CSeq, then correlate the successful INVITE response with its ACK. This is evidence about call setup; it is not evidence that speech reached either listener.

2. Read SDP as receive destinations and media conditions

Compare the offer and answer currently in effect: audio receive addresses, ports, codecs, and direction. If an UPDATE or re-INVITE changed the session, the initial SDP alone is insufficient.

  • c=: connection address. A media-level c= overrides the session-level address for that media.
  • m=audio: audio port, transport, and media formats.
  • a=rtpmap: mapping between an RTP payload type, codec, and clock rate.
  • a=fmtp: codec-specific format parameters. Matching codec names alone do not replace checking the format conditions.
  • a=sendrecv and related attributes: negotiated media direction. sendrecv does not prove that packets are flowing.

3. A simple example: do not reverse the destination

For this simplified example, the receive addresses and ports specified in SDP are:

  • Endpoint A: 192.0.2.10:40000
  • Endpoint B: 198.51.100.20:50000

In this example, A should send toward B's port 50000, and B should send toward A's port 40000. A's receive port is not the destination port that A uses to send to B.

Suppose a capture at A shows A→B packets but no B→A packets. The observation is limited: the reverse stream was not observed at A's capture point. It does not establish whether B failed to send, an intermediate path dropped the traffic, or the capture missed it. Compare another observation point before assigning a cause. The absence alone does not establish a codec or radio-network fault.

4. Packets present does not necessarily mean audible speech

Compare actual addresses, ports, and payload types with the negotiated conditions, then examine both directions during the problem interval. Even when packets are observed in both directions, decoding, silence in the media, mute settings, or the endpoint's audio output can still explain the symptom. Interpret RTP/RTCP statistics alongside the user's actual audio experience.

A real VoLTE deployment also requires attention to the IMS profile, SBC media anchoring, SRTP, and bearer/QoS configuration. Match each capture segment to its own configuration rather than applying the direct-address example to every network.

How I would structure an interview answer

“First, I would correlate the successful INVITE response and ACK. Next, I would extract the receive addresses, ports, codecs, and direction from the effective SDP offer/answer. I would then compare both media directions for the same call and time interval, separating packet-delivery evidence from audio-decoding and playback evidence.”

The useful habit is to distinguish what you observed from what you still need to verify.

Continue with the English course

In my VoLTE/IMS & 5G/LTE Throughput course on Udemy, I connect SIP, SDP, RTP, bearers, codecs, and call procedures through message examples. The course page includes the curriculum and a preview.

Kihong Kim | Mobile Engineering Problem-Solving Series 01

Technical references: RFC 3261: SIP · RFC 8866: SDP · RFC 3264: Offer/Answer · RFC 3550: RTP/RTCP

Comments

Post a Comment

Popular posts from this blog

Vibe Coding and AI Agents: A 30-Day Project Diary

Prologue: From a personal dashboard to content projects, starting with a $20/month AI subscription Building an AI one-person content studio with ChatGPT, Codex, and human judgment Turning one idea into a finished result requires more roles than it first appears. Someone has to define the problem, break the work into tasks, create the files, review the result, and decide what should happen next. This series documents how I ran that process as an AI-agent collaboration using ChatGPT and Codex. I set the direction and quality bar. ChatGPT structured the requirements and content. Codex handled execution at the level of code, files, documents, and production packages. The first proof case was a personal asset-management automation system. I then applied the same operating model to YouTube Shorts, webtoons, motion comics, blogs, and a future book. The result is becoming a multi-channel publishing system for an AI one-person content studio. Why I started The project did not begin with a grand...
Read more

From Webtoon to Novel: Adapting One Story Across Formats

Image
The creative background behind Learning to Take My Place, from visual storytelling to a published novel What a one-person AI studio taught me about expanding an IP instead of copying it I did not set out to make a film or write a novel. The original plan was much smaller: spend thirty days finding out what a non-developer could actually build with a $20 monthly AI subscription, then turn the experience into a book. The project refused to stay inside that book. One of its lessons became a webtoon. An incident in the webtoon became a motion comic, then a three-minute, fifty-three-second short film. The same characters eventually moved into an eighteen-chapter workplace thriller. From the outside, it may look as if I made one thing and reused it several times. The opposite was true. The moments that failed most often were the ones where I trusted an existing asset to work in a new medium without rebuilding it. Episode 6 opens with a question rather than an explanation: if the accident nev...
Read more