Asterisk PJSIP: Adding SIP Provider Peer (Latest Versions)

Enterprise-grade SIP trunks often use IP authentication instead of traditional username/password registration.

In this model, the telecom provider does not expect your Asterisk server to send REGISTER requests. Instead, the provider trusts all SIP traffic that originates from your server’s public IP address.

This approach is common in:

• Enterprise SIP trunks replacing PRI/E1 lines
• Data-center hosted Asterisk systems with static IPs
• High-volume outbound dialers and contact centers

Because authentication depends entirely on IP trust, correct network configuration becomes more critical than credential configuration.

How IP-Authenticated SIP Trunks Work (Real Call Flow)

Unlike registration-based trunks, the signaling flow is simpler:

1. Your server sends SIP INVITE directly to provider IP
2. Provider checks the source public IP
3. If IP is whitelisted → call is accepted
4. If IP is unknown → provider rejects with 403 or silently drops

For inbound calls:

1. Customer dials DID number
2. Provider sends INVITE from its signaling IP
3. Asterisk must match that IP using identify
4. Call is routed into the configured dialplan context

Production-Safe PJSIP Configuration (Full Example)

This is a realistic template used in enterprise deployments.

[provider-aor]
type=aor
contact=sip:PROVIDER_IP
max_contacts=1
qualify_frequency=60


[provider-endpoint]
type=endpoint
transport=transport-udp

; Where inbound calls enter the dialplan
context=inbound-provider

disallow=all
allow=ulaw,alaw

aors=provider-aor

; Network stability settings (important for NAT/firewall scenarios)
direct_media=no
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

; Optional caller ID presentation for outbound
; from_user=YOUR_DID
; from_domain=provider.domain


[provider-identify]
type=identify
endpoint=provider-endpoint

; Must match ALL provider signaling IPs or ranges
match=PROVIDER_IP

In real deployments, providers may give:

• Multiple signaling IP addresses
• Entire IP ranges
• Different IPs for inbound vs outbound

Every valid IP must be added to identify matching.

Inbound DID Routing in the Dialplan

After identify matching succeeds, the call enters the context=inbound-provider.

Example DID routing:

[inbound-provider]
exten => 1800123456,1,NoOp(Inbound DID call)
 same => n,Goto(ivr-main,s,1)

exten => 1800654321,1,NoOp(Support DID)
 same => n,Queue(support-queue)

Providers may send the DID in different headers:

• Request-URI
• To header
• P-Called-Party-ID

Always confirm using SIP logs or Wireshark.

Outbound Call Routing Example

[outbound]
exten => _X.,1,NoOp(Outbound via provider)
 same => n,Dial(PJSIP/provider-endpoint/${EXTEN},60)
 same => n,Hangup()

Important production notes:

• Provider may restrict allowed caller IDs
• Invalid caller ID can cause 403 Forbidden
• Some providers rewrite caller ID automatically

NAT and Firewall Requirements for IP-Based Trunks

Even without registration, NAT still matters for RTP media.

Required firewall ports:

sudo ufw allow 5060/udp
sudo ufw allow 10000:20000/udp

Missing RTP ports cause:

• Calls connect successfully
• No audio or one-way audio occurs

Real Production Failure Scenarios

1. Provider IP Changed

• Inbound calls suddenly stop
• No SIP error appears in Asterisk
• Fix: update identify match with new IP range

2. Firewall Blocking RTP

• Call connects but silence occurs
• Fix: open RTP port range

3. Caller ID Rejected

• Outbound calls fail with 403
• Fix: use provider-approved DID in from_user

Debugging Workflow Used by Telecom Engineers

1. Enable SIP logging → pjsip set logger on
2. Confirm inbound INVITE source IP
3. Verify identify match occurs
4. Check RTP flow using rtp set debug on
5. Capture packets with tcpdump if unclear

This structured approach avoids blind configuration changes.

Key Takeaway

IP-authenticated SIP trunks remove credential complexity but increase dependence on:

• Correct public IP configuration
• Accurate identify matching
• Proper firewall and RTP handling

When designed correctly, IP-based trunks are extremely stable and ideal for enterprise call centers.