Hi there i create a trunk
host=10.26.7.40
type=peer
context=from-internal
insecure=invite,port
port=5060
ad want to receive a call from other Asterisk server
but for some reason my server reply as 401 Unauthorized
Firstly, it is usually better to provide logs as plain text, not images, and for chan_sip protocol traces, to use sip set debug on.
On the limited information available the most likely cause is that 44429 is defined as friend on the destination machine. friend is heavily overused, and, in almost all cases, peer should be used instead.
Note the request is coming from 5060, so there seems to be no valid reason to use insecure=port, although that is not the cause of your problem.
Also, insecure=invite has no effect unless a secret is included in the configuration, which further reinforces the idea that the call is being matched against a different sip.conf entry.
Especially if this is a new system, please note that chan_sip is not supported by the core Asterisk project, only by the community, and will be removed completely, in, maybe, a couple of years, once chan_pjsip covers the remaining niche cases.
44429 is the Extension on IP *.7.40 so yes it is a friend there
2021/05/18 13:32:16.570515 10.26.7.40:5060 → 10.26.141.1:5060
INVITE sip:44444@10.26.141.1 SIP/2.0
Via: SIP/2.0/UDP 10.26.7.40:5060;branch=z9hG4bK2d81f97e;rport
Max-Forwards: 70
From: “oooooooooooooo oo. oo.” sip:44429@10.26.7.40;tag=as77eee13c
To: sip:44444@10.26.141.1
Contact: sip:44429@10.26.7.40:5060
Call-ID: 57727aee7336f90253f05d7f751d655f@10.26.7.40:5060
CSeq: 102 INVITE
User-Agent: FPBX-15.0.16.52(13.32.0)
Date: Tue, 18 May 2021 10:32:16 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 248
v=0
o=root 2059410107 2059410107 IN IP4 10.26.7.40
s=Asterisk PBX 13.32.0
c=IN IP4 10.26.7.40
t=0 0
m=audio 14748 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
2021/05/18 13:32:16.570916 10.26.141.1:5060 → 10.26.7.40:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.26.7.40:5060;branch=z9hG4bK2d81f97e;received=10.26.7.40;rport=5060
From: “oooooooooooooo oo. oo.” sip:44429@10.26.7.40;tag=as77eee13c
To: sip:44444@10.26.141.1;tag=as39ccfaa3
Call-ID: 57727aee7336f90253f05d7f751d655f@10.26.7.40:5060
CSeq: 102 INVITE
Server: FPBX-15.0.17.34(13.36.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce=“1c03e6bc”
Content-Length: 0
I was suggesting that it is a friend on …141.1!
In any case, unless it shares an IP address with something else, it shouldn’t be a friend anywhere; it should be a peer.
Another possibility is that you are running a soft phone on 7.40, which is registered on 141.1. In that case you will need to match the trunk by user name, which is the case where friend is still necessary (for both).
You could also get 401, if you have alwaysauthreject, and it does’t match anything, although it looks like it should be matching, in this case.
Also please note that FreePBX is not supported on this forum. We can only answer in terms of the Asterisk configuration files, and can’t take account of configuration generated by FreePBX.
ok let me describe more carefully
There are 2 Asterisk Servers
Asterisk #1 (10.26.7.40) and Asterisk #2 (10.26.141.1)
i create a new trunk on both Asterisks
#1
[trunk]
host=10.26.141.1
type=peer
context=from-internal
insecure=invite,port
port=5060
#2
[trunk]
10.26.141.1
host=10.26.7.40
type=peer
context=from-internal
insecure=invite,port
port=5060
After i create a dial plan — if anybody want to dial 44444 from server #1
use trunk to server #2
Make Sense ?
END
It doesn’t make sense because you have insecure=invite without a secret, so the insecure=invite is doing nothing. From the logs you provided, the insecure=port doesn’t seem to be giving any benefit, and is reducing security, as the expected source port number is being used.
I’d say the whole insecure line is redundant, but removing it will not solve your problem, as the trunk section isn’t being used on the receiving side.
The 401 will be the result of matching a sip.conf entry that you haven’t provided, or matching none, but with alwaysauthreject set.
There isn’t enough logging to work our what, in sip.conf, the call is actually matching.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.