What SIP trunking actually connects
SIP trunking connects a SIP-capable communications system to another SIP network for session signaling, while RTP or SRTP normally carries media separately. A trunk is not a physical cable and does not guarantee capacity, identity authorization, emergency-service behavior or media security; those are defined by configuration, interconnection and service terms.
SIP and RTP call flow
SIP messages negotiate participants and carry SDP. SDP advertises codecs, addresses and ports but does not transport audio. RTP sequence numbers and timestamps support playout of media packets. Because signaling and media can follow different paths, a completed SIP dialog can still have one-way or no audio.
Read a basic INVITE
INVITE sip:+12025550123@sip.example.net SIP/2.0
Via: SIP/2.0/UDP 198.51.100.20:5060;branch=z9hG4bK-basic1
From: "Example caller" <sip:+12025550123@example.com>;tag=abc123
To: <sip:+12025550123@sip.example.net>
Call-ID: basic-001@example.com
CSeq: 101 INVITE
Contact: <sip:pbx@198.51.100.20:5060>
P-Asserted-Identity: <sip:+12025550123@example.com>
Content-Type: application/sdp| Field | Operational meaning |
|---|---|
| Request-URI | Destination requested from the current hop. |
| From | Logical initiator identity for the dialog; not automatic proof of authorization. |
| To | Logical target identity. |
| Contact | Address for subsequent dialog requests. |
| Via | Transaction return path and branch correlation. |
| Call-ID | Dialog correlation value. |
| CSeq | Sequence number plus method. |
| P-Asserted-Identity | Asserted identity within an agreed trusted domain. |
Response ladder
PBX SIP peer
| INVITE |
|---------------------------->|
| 100 Trying |
|<----------------------------|
| 183 Session Progress + SDP |
|<----------------------------|
| 200 OK + SDP |
|<----------------------------|
| ACK |
|---------------------------->|
|<========== RTP ==========> |
| BYE |
|---------------------------->|
| 200 OK |
|<----------------------------|100 is provisional transaction handling. 180 commonly indicates ringing; 183 can carry early-media SDP. 200 accepts the INVITE, and ACK completes that exchange. BYE ends an established dialog. Real paths may include proxies and separate early-media behavior.
Registration authentication versus IP authentication
REGISTER sip:sip.example.net SIP/2.0
Contact: <sip:pbx@198.51.100.20:5060>
# Registrar challenges; PBX retries with protected digest authorization.[carrier-identify]
type=identify
endpoint=carrier-endpoint
match=203.0.113.10
# Static IP-auth model may not send REGISTER.REGISTER creates or refreshes a contact binding and commonly uses digest authentication. IP-auth trunks may trust requests arriving from approved network sources and use a static AOR for outbound routing. Neither model is universally better; each has distinct credential, source-spoofing, topology and availability risks.
E.164 and identity normalization
Request-URI: sip:+12025550123@sip.example.net
From: <sip:+12025550123@example.com>
P-Asserted-Identity: <sip:+12025550123@example.com>A plus-prefixed E.164 representation expresses a globally scoped number format, but providers can require specific URI forms and authorization. Formatting does not prove ownership. Normalize only under an explicit dial plan, preserve the original evidence for troubleshooting, and avoid publishing real customer telephone numbers.
SDP chooses the media parameters
v=0
o=pbx 5000 5000 IN IP4 198.51.100.20
s=Example call
c=IN IP4 198.51.100.20
t=0 0
m=audio 16000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000The c= address and m=audio port tell the peer where to send media for this offer. Payload mappings name formats. The answer selects a compatible subset. NAT, firewalls and encryption must all agree with the negotiated path.
Verify a trunk concept with evidence
For a controlled call, record UTC time and Call-ID, identify the endpoint and contact selected, preserve the response ladder, compare offer and answer, then confirm RTP packets and intelligible audio in both directions. Registration or OPTIONS status is supporting evidence, not a substitute for an end-to-end call test.
Common failure boundaries
| Boundary | Evidence | Related guide |
|---|---|---|
| Object/contact selection | Endpoint and AOR CLI output | PJSIP object relationships |
| Request rejection | Response source, Call-ID and Reason | 403 or 503 guide |
| Offer/answer | SDP codec and encryption intersection | 488 guide |
| Media path | Both RTP directions at each NAT boundary | NAT/RTP guide |
| Identity verification | Identity token and protected verification result | STIR/SHAKEN guide |
Security note
A public SIP listener attracts scanning and abuse. Use bounded source policy where appropriate, strong authentication, restricted dialplan contexts, fraud limits, protected logs and current supported software. TLS/SRTP, identity frameworks and Fail2Ban address different risks and should not be represented as interchangeable controls.
Related engineering resources
Operational boundaries beyond the protocol
A production trunk also depends on numbering authorization, route eligibility, concurrency and rate controls, emergency-service handling, lawful process, monitoring and support escalation. SIP syntax cannot answer those business and regulatory questions. Document the service boundary separately from the protocol boundary and avoid presenting a reachable peer as evidence that every destination or identity is authorized.
Quality should be measured across representative calls using latency, loss, jitter, post-dial delay, answer behavior and release causes. The media path may change by destination or failover route. Keep test numbers and customer traffic protected, and use synthetic or approved destinations for public runbooks.
Change safety
Any trunk change should have a saved baseline, controlled test, monitoring window and rollback. Even a codec-order or contact change can alter routing, transcoding or media. Preserve one sanitized transaction before and after the change so the effect is demonstrable.
Authoritative references
Implementation closure
PBX ownership, peer signaling address, media ranges, number format, authentication model, and security requirements; each belongs to the trunk design record.
Architecture and interconnection plan; no production file is changed by this conceptual guide.
Use the model to review the peer-specific implementation runbook. No reload or restart applies here.
Signaling, SDP, media, identity, routing, and ownership boundaries are all named and testable.
If any boundary is unknown, obtain it from the responsible peer or system owner before configuration.
Stop before deployment when media addresses, number authorization, emergency-service scope, or security ownership is unresolved.
The design identifies both SIP and RTP paths, the authentication model, numbering rules, verification evidence, and the responsible party for every boundary.