VoIP.infoThe independent guide to business communications.
VoIP.info Protocol reference

SDP for VoIP: read addresses, ports and media direction

Interpret the session description without confusing an offered parameter with a working network path.

Reviewed 2026-10-19Foundational

A description carried by signaling

SDP describes a multimedia session. In SIP calls it commonly conveys media addresses, ports, formats and direction attributes through an offer/answer exchange. SDP does not itself transport sound or reserve network capacity.

Read session-level and media-level information together. A media-level setting can change how a particular stream is interpreted. The current SDP specification is RFC 8866; offer/answer behavior is described separately by RFC 3264 and relevant updates.

Compare the offer with the answer
An offer proposes media addresses, codecs and parameters. The answer selects compatible media details or the request is rejected. RTP must then follow the negotiated path.

A negotiated codec does not prove packet delivery. Check both session description and actual media packets.

Questions to answer in a trace

Identify the address and port offered for audio, the permitted formats and the accepted direction. Determine which participant sent each description. For a PBX with two call legs, inspect both negotiations rather than assuming the same codec and address pass unchanged through the system.

An address can be syntactically valid but unreachable from the peer. Private addressing advertised toward an unrelated carrier is a topology problem even when the SIP exchange itself succeeds.

Hold and renegotiation

A call can change its media parameters after initial setup. Hold, transfer and network changes can trigger a new negotiation. A trace that stops at the first answer can miss the point where sound disappeared.

Compare the last successfully applied description with the current one. Look for changed destination, direction or format, then confirm whether packets follow that negotiation.

Keep the conclusion bounded

An accepted codec does not prove usable audio at the speaker. It establishes a negotiated format under the protocol. Verify packet delivery and endpoint behavior separately. Preserve a sanitized complete exchange when asking for help, including the offer and answer relevant to the failure.

Use Flowroute SDP to find the Direct Media path

Compare advertised addresses and ports with NAT and the PBX public media range, then confirm packets. The Flowroute audio diagnostic supplies the evidence sequence.

A Yay.com TLS session does not establish SRTP

The Yay.com diagnostic requires the offer, answer, negotiated profile, packet directions and decoded result.

Use negotiated SDP to locate SIPTRUNK direct media

The SIPTRUNK diagnostic compares advertised endpoints with the first observed RTP packet and audible result.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Continue your research

Hub

SIP reference

Understand registration, call setup and response codes in the context of the request and call leg.

Explore topic →
Guide

How VoIP works

Follow call setup and audio separately to understand why a ringing phone can still have no sound.

Read guide →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →
Reference · SIP standards; extension support depends on both peers

SDP offer/answer: negotiate one session change at a time

Read codec, address and direction choices as a negotiation rather than two unrelated configuration files.

Read guide →
Troubleshooting · Current first-party Flowroute and BCM One documentation reviewed October 18, 2026. The current support pages were updated August 27, 2026 and list the Oregon and Virginia PoPs, require all listed signaling ranges for provider-side failover and load balancing, and describe Direct Media as RTP from potentially any source IP to the customer system public media-port range. Older but still public first-party route documentation distinguishes route objects from each number's primary and failover relationships, registration from Host or URI delivery, and preferred inbound PoP selection from customer-destination failover. Documentation and examples are not observed tenant state. No Flowroute account, credential, number, route, registration, DNS answer, certificate, PBX, firewall, packet, media stream, invoice, emergency workflow or live call was inspected or tested

Flowroute call signaling works but audio is missing

Separate SIP completion from Direct Media by preserving SDP, public media ports, translated addresses, observed RTP sources, packet direction and decoded audio.

Read guide →
Troubleshooting · Current first-party Yay.com SIP-trunk creation, authentication, number assignment, inbound destination, encryption, firewall and FreePBX-example documentation reviewed October 18, 2026. The material separates number-to-trunk assignment, inbound identity selection, IP address or FQDN destination, port and transport, outbound IP or username/password authorization, optional registration, TLS signaling, dashboard and endpoint SRTP settings, PBX routing and media. The public FreePBX example uses legacy chan_sip-style fields and is retained only as historical field-orientation context, not a FreePBX 17 PJSIP template. Provider examples are documentation evidence rather than observed account state. No Yay.com account, number, trunk, credential, address, FQDN, DNS answer, registration, certificate, PBX, firewall, packet, media stream, price, availability, compatibility, capacity or live call was inspected or tested

Yay.com trunk connects but inbound routing or audio fails

Trace number assignment, inbound identity, destination, TLS, PBX matching, SDP and SRTP without changing a working outbound authorization path.

Read guide →
Provider research · Current first-party SIPTRUNK device, registration, inbound-call, IP-authentication, failover, registration-status, interconnection and direct-media documentation was reviewed October 19, 2026. Credential registration and static-IP authentication remain different service paths; portal registration, Contact address, observed public source, inbound route, signaling gateways, direct-media RTP sources and failover treatments remain separate evidence. No SIPTRUNK account, trunk, credential, registration, number, route, gateway, DNS answer, PBX, firewall, packet, media stream, failover event, price, availability, compatibility or live call was inspected or tested

SIPTRUNK registration, inbound Contact routing and direct-media evidence

Keep credential registration or IP authentication, Contact delivery, inbound number matching, gateway redundancy, direct-media RTP and failover treatment independently observable.

Read guide →
Troubleshooting · Current first-party SIPTRUNK device, registration, inbound-call, IP-authentication, failover, registration-status, interconnection and direct-media documentation was reviewed October 19, 2026. Credential registration and static-IP authentication remain different service paths; portal registration, Contact address, observed public source, inbound route, signaling gateways, direct-media RTP sources and failover treatments remain separate evidence. No SIPTRUNK account, trunk, credential, registration, number, route, gateway, DNS answer, PBX, firewall, packet, media stream, failover event, price, availability, compatibility or live call was inspected or tested

SIPTRUNK is registered but inbound calls or audio fail

Trace the selected authentication mode, registered Contact, provider attempt, PBX route and direct-media RTP without treating portal registration as end-to-end proof.

Read guide →