VoIP Audio Delay After Answer: Find the Cause in a Capture

What causes VoIP audio delay after answer between 200 OK and the first RTP packet?

SIP signaling and RTP media are separate flows. A 200 OK says the call is answered, but audio only exists once RTP packets travel in both directions and each side has learned where to send them. Any delay in that second step is heard as silence or a clipped greeting.

The usual sequence is INVITE, 100 Trying, 180 Ringing or 183 Session Progress, 200 OK with SDP, then ACK. Media can start as soon as SDP has been exchanged, but many devices only open or latch the media path after the 200 OK or ACK.

Clipping happens when your side plays audio before the far end can hear it. The first words are sent into a path that is not open yet, so they are lost, and nothing in signaling looks wrong.

How do I measure the gap with a packet capture?

Capture on the PBX itself so you see both the SIP and RTP legs. Capture the whole call, including the first second after answer, and reproduce the problem on one test call.

Open the file in sngrep for a quick ladder view, or in Wireshark for exact timing.

1. Run the capture, place a test call, and stop it after the greeting.
2. Open it with sngrep -I call.pcap, select the call, and press Enter for the flow. Note the time of 200 OK and ACK.
3. In Wireshark use Telephony > VoIP Calls, select the call, then Flow Sequence and RTP Streams. Note the first packet time for each direction.
4. Compare the RTP source IP and port with the SDP c= and m= lines. A mismatch means NAT or a media proxy.
5. Look for ICMP destination unreachable (port unreachable) replies, which mean the far side was not listening yet or the port is wrong.

# capture SIP and RTP on the PBX
tcpdump -ni any udp port 5060 or portrange 10000-20000 -w call.pcap

# print SIP final responses and RTP timing
tshark -r call.pcap -Y 'sip.Status-Code == 200 || sip.Method == "ACK" || rtp' \
  -T fields -e frame.time_relative -e ip.src -e ip.dst -e sip.Status-Code -e rtp.seq | head -80

# live view in Asterisk
asterisk -rx "pjsip set logger on"
asterisk -rx "rtp set debug on"

Why does NAT and RTP latching cause silence after the call is answered?

Phones behind NAT often put a private address in SDP. Asterisk must ignore it and learn the real address from the first inbound RTP packet (symmetric RTP or latching). Until that packet arrives, outbound audio goes to an unreachable private IP and the greeting is lost.

With strict RTP protection (strictrtp in rtp.conf, on by default), Asterisk also needs a few consecutive packets from a new source before it switches to it. If the remote device only starts sending after it hears you, or after its own timer, you get a gap that is the same length on every call.

The reverse mistake is on your side: if external_media_address or local_net is wrong, Asterisk advertises a private IP to the carrier and the carrier's media goes nowhere until its own latching kicks in.

; pjsip.conf
[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
local_net=192.168.0.0/16
external_media_address=203.0.113.10
external_signaling_address=203.0.113.10

[phone1]
type=endpoint
direct_media=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
disallow=all
allow=ulaw,alaw

Is early media or a direct media re-INVITE causing the delay?

Early media is a 183 Session Progress carrying SDP, which opens RTP before answer so callers hear ringback or prompts. If the carrier ignores or drops early media, the first prompt you play before 200 OK is silent. If your PBX answers first, the same carrier may need time to cut its audio path through after the 200.

Reliable provisional responses matter here. If the far end requires them, the INVITE carries Supported: 100rel and the 183 needs a PRACK. Without it, the 183 is retransmitted and the media path may not open. On PJSIP the endpoint option is 100rel=yes (or required) when the carrier demands it.

Direct media is the other classic. Asterisk answers, then sends a re-INVITE to connect the two endpoints directly. During that renegotiation audio can stop for a second or more, and with NAT it may never recover. Set direct_media=no on both endpoints and compare traces: a re-INVITE shortly after the ACK that disappears is your answer.

A re-INVITE can also come from a codec change, a T.38 probe, or hold/unhold logic. Any INVITE after the ACK within the first seconds deserves an explanation.

What other network and platform causes delay audio start?

Media relays add their own setup time. RTPengine, an SBC or a provider's media proxy allocates ports and waits for the first packet from each side before bridging. If the capture shows RTP leaving your PBX immediately but the far side only starts after a pause, the delay lives in the relay.

WebRTC clients add ICE gathering, STUN or TURN checks and DTLS-SRTP handshakes. Audio does not flow until DTLS completes, which can take a second on slow links. Enable icesupport and a stunaddr in rtp.conf, and check that TURN is reachable.

Firewall and RTP range problems look like working signaling with no audio until a timeout. rtp.conf defaults to rtpstart=10000 and rtpend=20000, and that range must be open to the carrier and match what appears in the SDP m= line. A SIP ALG on the router can rewrite SDP incorrectly, so disable it.

Transcoding adds start-up cost and CPU load. If the offer and answer share no codec, Asterisk transcodes, and G.729 or Opus needs the right module or license. Use core show channel and pjsip show channel to see the native and read/write formats, and prefer ulaw or alaw end to end.

Finally, slow work before Answer() delays the 200 OK itself: DNS lookups in trunk or AGI scripts, database queries, call recording start-up, or a Stasis application that has not attached yet. Those delays show before the 200 OK in the capture, not after it.

How do I fix the clipped greeting in the dialplan?

Once the cause is known, you can add a safety margin in the dialplan. Answer() followed by Wait(1) gives the media path a second to settle, but it only hides the cause. The delay returns whenever the path gets slower, so use it as a stopgap beside the real fix.

The better pattern is to send early media with Progress() and play the prompt before answering. The caller hears the prompt without relying on the post-answer path. The trade-off is that some carriers bill or limit early media, so check the terms before using it for long prompts.

; extensions.conf
exten => s,1,NoOp(Inbound)
 same => n,Progress()
 same => n,Playback(welcome)
 same => n,Answer()
 same => n,Wait(1)        ; stopgap only
 same => n,Goto(ivr,s,1)

Which symptom points to which cause of VoIP audio delay after answer?

Use the direction of the silence and where the calls come from to narrow the cause quickly, then confirm with the capture.