SIP trunk between two trusted Asterisk servers

Asterisk Asterisk SIP
1

Hi,

Sorry for the silly question, but I can’t seem to properly set up a SIP trunk between 2 Asterisk servers in the same LAN. I’ve done this with IAX2 which is really simple.

I require that one peer is an Asterisk 16 with PJSIP, and the other peer is an Asterisk 1.4 with chan_sip. I dont’ care for user authentication as this is a LAN, and I only want endpoints on each system to access both dialplans.

So, here’s what I’ve tried on the “new” Asterisk PJSIP side:
In pjsip_wizard.conf:

[trunk_defaults](!)
type = wizard
transport = transport-udp
endpoint/allow_subscribe = no
endpoint/allow = !all,alaw,ulaw,opus,gsm,vp8,h264
aor/qualify_frequency = 30
registration/expiration = 1800

[meetbox](trunk_defaults)
sends_auth = no
accepts_auth = no
sends_registrations = no
accepts_registrations = no
remote_hosts = 10.215.147.112:5060
endpoint/context = custom-newsystem

where 10.215.147.112 is the IP addr. of the “old” Asterisk system.
Also, I have this in pjsip.conf:


[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060

In my extensions.conf I have the following:

exten => _XXXX,1,NoOp(${CALLERID(all)} is dialing ${EXTEN} through trunk)
same => n,Dial(PJSIP/meetbox/sip:${EXTEN}@10.215.147.112,300,tTWg)
same => n,Hangup()

I’m expecting at the very least to let endpoints from the “new” system dial extensions on the “old” system.

Finally, on the “old” Asterisk system, I have this in sip.conf:

[meetbox]
deny=all
allow=ulaw
allow=alaw
allow=gsm
allow=opus
allow=vp8
allow=h264
context=custom-newsystem
type=peer
qualify=yes
host=10.215.144.92
videosupport=yes
insecure=no

where 10.215.144.92 is the IP addr. of the “new” system.

Now, on the old system I ran this:

# asterisk -rx "sip show peer meetbox" | grep Status
  Status       : OK (1 ms)

And on the new Asterisk system pjsip shows me this:


 Endpoint:  meetbox                                              Not in use    0 of inf
        Aor:  meetbox                                            0
      Contact:  meetbox/sip:10.215.147.112:5060            029c19e659 Avail         2.629
  Transport:  transport-udp             udp      0      0  0.0.0.0:5060
   Identify:  meetbox-identify/meetbox
        Match: 10.215.147.112/32

However, when I make a call from the new ssystem to the old one, I get this on the CLI:

[Sep 26 10:07:14] NOTICE[17773]: res_pjsip/pjsip_distributor.c:676 log_failed_request: Request 'OPTIONS' from '"Unknown" <sip:Unknown@10.215.147.115>' failed for '10.215.147.115:5060' (callid: 6538ce441eb7dbda381626e1227a9c19@10.215.147.115) - No matching endpoint found
  == Setting global variable 'SIPDOMAIN' to 'sip.mydomain.org'
    -- Executing [7000@default:1] NoOp("PJSIP/4053-00000002", ""test me" <4053> is dialing 7000 through trunk") in new stack
    -- Executing [7000@default:2] Dial("PJSIP/4053-00000002", "PJSIP/meetbox/sip:7000@10.215.147.112,300,tTWg") in new stack
    -- Called PJSIP/meetbox/sip:7000@10.215.147.112
[Sep 26 10:07:27] WARNING[17773]: res_pjsip_outbound_authenticator_digest.c:178 digest_create_request_with_auth: Endpoint: 'meetbox': Unable to create request with auth. No auth credentials for realm(s) 'asterisk' in challenge.
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Executing [7000@default:3] Hangup("PJSIP/4053-00000002", "") in new stack
  == Spawn extension (default, 7000, 3) exited non-zero on 'PJSIP/4053-00000002'

Nothing shows up in the old system’s CLI, and the callee does not ring, of course.

What am I missing?

2

Your chan_sip side is challenging for authentication. You would need to set “insecure” to “invite” to disable that.

3

I don’t think it should be challenging, as there is no secret specified. It certainly never used to challenge in such cases, when we left insecure at default, which I believe is the same as the “no” that is being explicitly set here.

What could result in a challenge is misusing type=friend for the locally connected phone, in a situation where the identity of the phone on the chan_sip system matched a caller ID from the new system. Devices should almost always be type=peer.

4

Unfortunately, setting insecure=invite in Asterisk 1.4’s chan_sip does not change anything.
This is the PJSIP trace on the “new” Asterisk 16 PBX:

<--- Received SIP request (2496 bytes) from WSS:10.215.144.48:63581 --->
INVITE sip:7000@sip.domain.org SIP/2.0
Via: SIP/2.0/WSS 192.0.2.25;branch=z9hG4bK216126
Max-Forwards: 70
To: <sip:7000@sip.domain.org>
From: "Test" <sip:4053@sip.domain.org>;tag=7qem9l051g
Call-ID: g63csr7jb459iuok9tcs
CSeq: 7776 INVITE
Contact: <sip:8uojug75@192.0.2.25;transport=wss;ob>
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: bp
Content-Type: application/sdp
Content-Length: 1997

[...]

<--- Transmitting SIP response (497 bytes) to WSS:10.215.144.48:63581 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/WSS 192.0.2.25;rport=63581;received=10.215.144.48;branch=z9hG4bK216126
Call-ID: g63csr7jb459iuok9tcs
From: "Test" <sip:4053@sip.domain.org>;tag=7qem9l051g
To: <sip:7000@sip.domain.org>;tag=z9hG4bK216126
CSeq: 7776 INVITE
WWW-Authenticate: Digest realm="asterisk",nonce="1601159168/b538effb9ca5e51e450e1accfa5ff809",opaque="6f164fa65ab3031d",algorithm=md5,qop="auth"
Server: Asterisk PBX 16.11.1
Content-Length:  0

[...]

<--- Received SIP response (603 bytes) from UDP:10.215.147.115:5060 --->
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 172.16.0.2:5060;branch=z9hG4bKPja2b06394-33b7-4d91-8325-3aadc02dcbfe;received=172.16.0.2;rport=5060
From: "Test" <sip:4053@10.215.144.92>;tag=fe2de869-ca16-4338-a7b8-df839963b32e
To: <sip:7000@10.215.147.112>;tag=as56dc1308
Call-ID: d172b0d6-5982-4f4a-9756-1a7bc2003356
CSeq: 3779 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="1926ecea"
Content-Length: 0

Why is it “unauthorized”?

5

The INVITE is unauthorised. 401 is requesting that you provide authorisation. That is the normal exchange when there is a secret (password) to check.

My suspicion is that you have a friend called SIP/7000 on the old system, in which case you will be asked to authenticate with its secret, which is why local devices should be peers, not friends.

The 407 relates to a different call and either one in the opposite direction, or it is from a different machine. It isn’t useful without the proper context.

6

No, the “old” system does not have a SIP extension/peer defined in sip*.conf. Neither peer nor friend (nor user). The extension ‘7000’ is defined in extensions.conf and calls an IVR.
No authentication should be required at all.

7

Please refer to:

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.