SIP connectivity#
Inbound SIP connectivity consists of two related network flows. SIP signaling establishes, changes, and ends the call. RTP carries the call media after the endpoints negotiate a media path in SDP. A working SIP connection therefore requires both signaling and media to pass between DIDWW and the receiving SIP system.
This page explains how the connectivity components fit together. For exact addresses, ports, protocols, codecs, DTMF methods, and encryption mechanisms, see the SIP connectivity reference.
Connectivity flow#
When DIDWW receives a call to a DID number assigned to an inbound SIP trunk,
it selects the trunk destination and sends an INVITE. The receiving system
returns SIP responses. If the call is answered, the SDP exchange determines
the RTP media addresses and ports used for the call.
%%{init: {
"theme": "base",
"themeVariables": {
"fontSize": "14px",
"actorBkg": "#e0f2fe",
"actorBorder": "#38bdf8",
"actorTextColor": "#1f2d3d",
"actorLineColor": "#38bdf8",
"signalColor": "#0f766e",
"signalTextColor": "#1f2d3d",
"labelBoxBkgColor": "#ccfbf1",
"labelBoxBorderColor": "#14b8a6",
"labelTextColor": "#1f2d3d",
"noteBkgColor": "#fef3c7",
"noteBorderColor": "#f59e0b",
"noteTextColor": "#1f2d3d",
"sequenceNumberColor": "#ffffff"
}
}}%%
sequenceDiagram
participant Caller as Caller
participant DIDWW as DIDWW
participant SIP as Customer SIP system
Caller->>DIDWW: Calls the DID number
DIDWW->>SIP: SIP INVITE
SIP-->>DIDWW: SIP responses and SDP
DIDWW-->>Caller: Call is answered
DIDWW->>SIP: RTP or SRTP media
SIP->>DIDWW: RTP or SRTP media
DIDWW->>SIP: BYE
SIP-->>DIDWW: 200 OK
Signaling destination selection#
The trunk routing method determines how DIDWW obtains the signaling destination.
With Static Endpoint, the destination comes from the user part, host, and optional port configured on the trunk. DIDWW originates signaling from the regional Static Endpoint addresses.
With Dynamic Registration, the customer system sends authenticated
REGISTERrequests to a DIDWW registrar. DIDWW then sends calls to an active Contact supplied by that registration.
The methods do not run simultaneously on one trunk. For destination construction, DNS behavior, registration maintenance, and routing-method selection, see SIP routing methods.
Signaling and media paths#
SIP signaling and RTP media can use different IP addresses and port ranges.
Allowing the SIP INVITE through a firewall does not by itself establish a
working audio path. The firewall or SBC must also allow media from the DIDWW
RTP source subnets.
The SDP offer and answer advertise the media addresses and ports that each side expects to use. NAT, private addresses, or restrictive firewall rules can make an advertised media destination unreachable even when signaling works. The Force Symmetric RTP, Allowed RTP IP Addresses, and RTP Ping settings can help with specific media and NAT behavior. Their exact behavior and security considerations are documented under Media & DTMF.
Firewall and SBC planning#
Build firewall and SBC rules around the selected routing method and the trunk’s Preferred Server, Network Protocol, and Transport values.
A Static Endpoint must accept signaling from each DIDWW location that can deliver its calls. When Preferred Server is Auto, allow all Static Endpoint signaling addresses because DIDWW can use an alternative location.
A Dynamic Registration endpoint must be able to resolve and reach its selected registrar and receive the related return signaling traffic.
Both routing methods require the DIDWW RTP source subnets and RTP port range to be allowed for media.
Hostnames and DNS SRV discovery require working DNS resolution from the systems that use them.
Use the Firewall and SBC allowlist as the factual checklist for these rules.
Authentication direction#
Authentication occurs in a different direction for each routing method.
For a Static Endpoint, authorization is optional. When enabled, DIDWW responds to the receiving server’s SIP digest challenge using the credentials stored on the trunk.
For Dynamic Registration, the customer system authenticates its REGISTER
requests to DIDWW using the generated trunk credentials. Those registrations
must remain active so DIDWW has a current Contact for inbound delivery.
Transport and media encryption#
TLS and SRTP protect different parts of the call.
TLS protects SIP signaling between DIDWW and the customer SIP system.
SRTP protects RTP media. The selected SRTP mode determines how the media keys are negotiated.
Enabling one does not automatically enable the other. Encryption applies to the DIDWW-to-customer call leg and is not maintained end to end across other call legs. Match the trunk’s transport and SRTP settings to the capabilities of the receiving SIP system.
Codec and DTMF interoperability#
The endpoints must negotiate at least one common audio codec for media to be established. DIDWW presents codecs in the order configured on the trunk, with the first codec having the highest preference.
DTMF is configured independently for sending and receiving. DIDWW supports
RTP telephone-event and SIP INFO methods. Select methods compatible
with the remote system to ensure that menu selections and other keypad input
are recognized in both directions.
Connectivity monitoring#
SIP OPTIONS can confirm that a signaling endpoint is reachable without
placing a call. An OPTIONS response does not confirm that a particular
call can be routed or that media, authentication, codecs, and DTMF are
configured correctly.
For call-specific troubleshooting, use the SIP response and routing-attempt details in Inbound Call Logs. See Troubleshooting for the cause of each response.