Protocols Used for Your Call Legs Using Asterisk (SIP, SDP, RTP, SRTP, TLS, WebRTC)

When calls “connect but there’s no audio”, “one-way voice happens”, or “WebRTC fails randomly”, the real cause is almost always inside the call legs: which protocols are used for signaling, which for media, and where NAT/firewall breaks the flow.

This guide explains—clearly and practically—what protocols are used in each call leg when you run Asterisk (PJSIP), including SIP/SDP for signaling, RTP/SRTP for audio, TLS for encryption, and how WebRTC (DTLS-SRTP + ICE) changes the picture.

You’ll also get real troubleshooting commands (Asterisk CLI + tcpdump/Wireshark) and the exact “failure patterns” people search for: one-way audio, 488 Not Acceptable Here, 401/403 auth errors, SRTP negotiation failed, DTMF not working, and more.

The Fast Mental Model: Signaling vs Media

Almost every VoIP problem becomes easy once you separate:

• Signaling: “Start the call, ring, answer, hang up” (mostly SIP messages)
• Media: “Actual audio packets” (RTP or SRTP streams)
• Negotiation: “Which codecs? which IP/ports?” (SDP carried inside SIP)

Many failures look like “SIP is fine” but audio fails—because SIP uses one set of ports and RTP uses another.

What “Call Legs” Mean in Asterisk

Asterisk usually creates two call legs (channels):

• Leg A: Caller → Asterisk
• Leg B: Asterisk → Destination

Each leg negotiates its own SDP and codec set. Asterisk may:

• Bridge media directly (RTP flows endpoint-to-endpoint) if conditions allow
• Anchor media (RTP flows through Asterisk) for recording, features, NAT safety, transcoding

That “direct media vs anchored media” choice can be the difference between stable calls and one-way audio.

Protocol Map: SIP, SDP, RTP, SRTP, TLS, WebRTC (Who Uses What?)

• SIP: call setup/teardown messages (INVITE, 180 Ringing, 200 OK, BYE)
• SDP: media negotiation (codecs, RTP IP/ports, SRTP keys, ICE candidates)
• RTP: real-time voice packets
• RTCP: quality/control (jitter, packet loss reporting), sometimes blocked by firewalls
• SRTP: encrypted RTP
• TLS: encrypts SIP signaling (SIPS / SIP over TLS)
• WebRTC: uses ICE + DTLS-SRTP; signaling can be SIP (WSS) or app-defined signaling

Official references: SIP (RFC 3261), SDP (RFC 4566), RTP (RFC 3550), SRTP (RFC 3711), DTLS-SRTP (RFC 5764), WebRTC overview (MDN).

How SIP Signaling Actually Looks (Real Messages You’ll See)

SIP is text-based. When a call starts, you usually see: INVITE → 100 Trying → 180 Ringing → 200 OK → ACK.

INVITE sip:1001@pbx.example.com SIP/2.0
Via: SIP/2.0/UDP 203.0.113.10:5060;branch=z9hG4bK...
From: "Caller" <sip:+911234567890@trunk.example>;tag=abc
To: <sip:1001@pbx.example.com>
Call-ID: 1a2b3c4d@203.0.113.10
CSeq: 1 INVITE
Content-Type: application/sdp

v=0
o=- 12345 67890 IN IP4 203.0.113.10
s=-
c=IN IP4 203.0.113.10
t=0 0
m=audio 40000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

The SDP part is where audio gets decided: codec list + RTP port (40000 above).

SDP: The #1 Reason Calls “Connect But No Audio”

If you only remember one thing: SDP tells each side where to send RTP. If SDP contains a private IP or a blocked port, you get silence or one-way audio.

What to look for in SDP:

• c=IN IP4 ... (the media IP)
• m=audio PORT ... (the RTP port)
• RTP profile (RTP/AVP vs RTP/SAVP vs UDP/TLS/RTP/SAVPF in WebRTC)
• Codec payloads (0=PCMU, 8=PCMA, 111=Opus commonly in WebRTC)

“Bad SDP” examples people hit:

• SDP advertises 192.168.x.x to the internet → remote side sends RTP to a private IP
• SDP advertises an RTP port your firewall blocks → RTP never arrives
• SDP offers only codecs the other side doesn’t support → 488 Not Acceptable Here

RTP vs SRTP: Why Encryption Changes Troubleshooting

RTP is plain UDP audio. You can decode it in Wireshark. SRTP encrypts the audio, so packet capture can prove traffic exists—but you can’t listen without keys.

In SIP land, SRTP is usually negotiated via SDP attributes, and you’ll see profiles like:

• RTP/AVP → RTP (no encryption)
• RTP/SAVP or RTP/SAVPF → SRTP

Typical SRTP failure searches:

• “SRTP negotiation failed”
• “Asterisk SRTP does not work with trunk”
• “WebRTC call connects but no audio SRTP”

Root causes:

• One side requires SRTP, the other supports only RTP
• Certificate/DTLS issues (WebRTC)
• Codec mismatch + no transcoding allowed

SIP over TLS: What It Protects (And What It Does Not)

TLS protects SIP signaling (your INVITE/credentials/headers), but it does NOT automatically encrypt audio. Audio is still RTP unless you use SRTP.

Common misunderstanding:

• SIP TLS = encrypted signaling
• SRTP = encrypted media
• You often want both for secure deployments

Asterisk TLS docs: Asterisk TLS configuration (note: the docs may reference chan_sip or pjsip sections depending on version).

WebRTC Call Legs: Why Browsers Don’t Behave Like SIP Phones

WebRTC typically uses:

• ICE to find a working network path (NAT traversal)
• STUN to discover public IP mappings
• TURN to relay media when direct paths fail
• DTLS-SRTP for mandatory encrypted media
• Opus codec commonly (plus PCMU/PCMA as fallback if configured)

This is why WebRTC problems often show up as:

• “Works on office Wi-Fi but not on mobile data”
• “No audio only on some networks”
• “Connected, but immediately hangs up after ICE fails”

WebRTC references: ICE (RFC 8445), STUN (RFC 5389), TURN (RFC 5766).

“One-Way Audio” in Asterisk: The Real Causes (And How to Prove Them)

One-way audio means RTP flows only in one direction. SIP may be perfect. The usual causes are:

• NAT wrong: SDP advertises the wrong IP (private IP leaked, or wrong external address)
• Firewall blocks RTP: you opened SIP 5060 but forgot RTP range
• Direct media fails: endpoints try to send RTP to each other but NAT blocks it
• Symmetric RTP mismatch: the far end changes ports; Asterisk not adapting

Quick proof checklist:

• Does Asterisk see inbound RTP? (rtp set debug on)
• Does the remote endpoint receive RTP? (packet capture at endpoint)
• Does SDP show a public IP + correct RTP ports?

“Call Connects But No Audio” When Using SIP Trunks

This usually happens when:

• Trunk sends RTP to Asterisk, but Asterisk replies to the wrong place (NAT mismatch)
• RTP port range is blocked on firewall or router
• Codec mismatch forces transcoding but it’s disabled / missing modules
• SRTP required by trunk but Asterisk is offering RTP (or vice versa)

The fastest way to isolate: force Asterisk to anchor media and disable direct media temporarily. In PJSIP endpoints/trunks, you’ll see options like direct_media.

; Example idea (exact location depends on your PJSIP config style)
; If direct media causes NAT trouble, turn it off:
direct_media=no

“488 Not Acceptable Here” and “415 Unsupported Media Type” Explained

These errors are about SDP incompatibility.

• 488 Not Acceptable Here: the callee rejects offered media (codecs/profiles/SDP attributes)
• 415 Unsupported Media Type: wrong content type or unsupported offer/answer scenario

What to check:

• Is there at least one common codec (PCMU/PCMA are safest for trunks)?
• Are you offering SRTP to a trunk that expects RTP only (or the reverse)?
• Are you offering WebRTC-only profiles to a SIP trunk (DTLS-SRTP vs plain RTP)?

DTMF Problems: “Press 1 Doesn’t Work” (RFC2833 vs SIP INFO vs Inband)

DTMF typically travels as:

• RFC2833 / RFC4733 events (most common, shown as telephone-event in SDP)
• SIP INFO messages (less common)
• Inband tones inside audio (breaks easily with compression/transcoding)

If IVR works internally but not from a trunk, it’s often a DTMF mode mismatch. SDP usually shows RFC2833 like:

a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

Reference: RTP Payload for DTMF (RFC 4733).

Practical Asterisk CLI Commands to Debug Call Legs

Use these during a live call to identify whether the issue is signaling, SDP, or RTP.

# Enter Asterisk CLI
asterisk -rvvv

# Show PJSIP endpoints/trunks status
pjsip show endpoints
pjsip show registrations
pjsip show contacts

# See active channels (call legs)
core show channels concise
core show channel <CHANNEL_NAME>

# Enable SIP message logging (careful in production)
pjsip set logger on

# RTP debug (shows packet flow)
rtp set debug on
rtp set debug off

# If you need to see codec negotiation details
core show translation

If you can see SIP messages but RTP debug shows nothing, your problem is almost always RTP/ports/NAT.

Wireshark/tcpdump: Prove Where RTP Breaks

Packet capture is the fastest way to end guessing. Capture on the Asterisk server and check:

• Do you see SIP INVITE + SDP? (signaling OK)
• Do you see RTP packets both directions? (media OK)
• Do you see RTP only one direction? (one-way audio root cause)

# Capture SIP and RTP on a Linux server (replace interface)
sudo tcpdump -i eth0 -nn -s0 -w /tmp/call-debug.pcap \
  '(udp port 5060) or (tcp port 5061) or (udp portrange 10000-20000)'

# Quick live view for SIP only
sudo tcpdump -i eth0 -nn 'udp port 5060 or tcp port 5061'

In Wireshark:

• Filter SIP: sip
• Filter RTP: rtp
• Right-click RTP stream → “Decode As…” (for RTP) and analyze direction

Wireshark RTP help: Wireshark documentation.

Firewall Reality: SIP Ports Are Not Enough

People open SIP 5060 and wonder why audio fails. That’s because:

• SIP signaling uses 5060 (UDP/TCP) or 5061 (TLS) commonly
• RTP uses a range of UDP ports (example: 10000–20000)
• WebRTC adds DTLS + ICE traffic patterns (often still UDP, but negotiation differs)

If your RTP range is blocked, you’ll see SIP success and silent audio.

Direct Media vs Anchored Media: A Hidden Cause of Random Failures

When Asterisk allows endpoints to send RTP directly to each other (direct media), NAT and routing complexity increases. Calls may:

• Work on LAN
• Fail across NAT
• Become one-way when one endpoint changes networks

If your environment is mixed (remote agents, mobile networks, SIP trunks), it’s common to keep media anchored on Asterisk for stability—especially when you need:

• call recording
• barge/whisper
• AI voice streaming / RTP bridging
• predictable NAT behavior

Common Failure Patterns People Search (And What They Actually Mean)

“401 Unauthorized” / “403 Forbidden”

• Authentication failed (wrong username/password)
• IP not allowed by identify/match rules
• Trunk expects registration but you configured static peer (or vice versa)

“Call connects but no audio”

• RTP ports blocked
• SDP advertises wrong IP (NAT)
• Direct media tries endpoint-to-endpoint and fails

“One-way audio Asterisk”

• NAT mismatch or firewall blocks one direction
• Symmetric RTP not handled

“488 Not Acceptable Here”

• No common codec
• SRTP/RTP profile mismatch
• WebRTC-only offer sent to SIP device

“DTMF not working”

• RFC4733 vs SIP INFO mismatch
• Inband DTMF lost due to codec/transcoding

Production Checklist: Make Call Legs Predictable

• Decide your codec policy (PCMU/PCMA safest for trunks; Opus for WebRTC)
• Open/forward RTP ranges correctly (and keep them consistent)
• Fix NAT at the source (external address + local nets + symmetric RTP when needed)
• Prefer anchored media when dealing with NAT + recording + AI features
• Use TLS + SRTP when security matters (especially for remote agents)
• Keep packet capture skills ready (Wireshark ends arguments quickly)

Key Takeaway

Asterisk call legs are not “one protocol”. They are a stack: SIP (signaling) carries SDP (negotiation) which decides RTP/SRTP (media). TLS protects SIP, while SRTP protects audio. WebRTC adds ICE + DTLS-SRTP and behaves differently than normal SIP phones.

Once you can read SDP and confirm RTP flow, you can solve 90% of “VoIP mysteries” in minutes.