Unathorized by PBX

Asterisk Asterisk SIP
1

Hi Team,

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.40:5060;branch=z9hG4bK7422b18a;received=192.168.1.40;rport=5060
From: sip:904@192.168.1.40;tag=as69bc3738
To: sip:XXXXXXXXXX@192.168.1.220:2022;tag=as09cd6fc7

Two asterisk are interconnected via SIP Trunk.

If I call from Server A to B with any number as caller ID, Server B allows the call. But If i fix the same caller ID as one of the extensions in Server B, then that call is unauthroized by Server B.

For EG:
Server B has 904 Extension number, If I call from Server A to Server B with Caller ID 904, then that call was un authorized by server B. How to avoid that?

Note: I cannot change either Extension number or caller ID of incoming call from other server. Any Idea?

2

Unauthorized is not an error. This is usually understood as a request for authorization. You need to look at the entire dialog.

I am not sure what you mean with the last two paragraphs. You may have misunderstood what the Caller ID is about. Please show the all of the conversation and your SIP configuration.

3

SIP Debugging enabled

<--- SIP read from UDP:192.168.1.40:5060 --->
INVITE sip:7502519749@192.168.1.220:2022 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.40:5060;branch=z9hG4bK20638727;rport
Max-Forwards: 70
From: <sip:904@192.168.1.40>;tag=as62391d02
To: <sip:7502519749@192.168.1.220:2022>
Contact: <sip:904@192.168.1.40:5060>
Call-ID: 15c45d42484426be3a7fd56b2e4283e4@192.168.1.40:5060
CSeq: 102 INVITE
User-Agent: IPBX-2.11.0(11.25.3)
Date: Mon, 01 Jan 2024 11:55:02 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 281

v=0
o=root 181958847 181958847 IN IP4 192.168.1.40
s=Asterisk PBX 11.25.3
c=IN IP4 192.168.1.40
t=0 0
m=audio 15008 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<------------->
--- (14 headers 13 lines) ---
Sending to 192.168.1.40:5060 (NAT)
Sending to 192.168.1.40:5060 (NAT)
Using INVITE request as basis request - 15c45d42484426be3a7fd56b2e4283e4@192.168.1.40:5060
Found peer '904' for '904' from 192.168.1.40:5060

<--- Reliably Transmitting (no NAT) to 192.168.1.40:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.40:5060;branch=z9hG4bK20638727;received=192.168.1.40;rport=5060
From: <sip:904@192.168.1.40>;tag=as62391d02
To: <sip:7502519749@192.168.1.220:2022>;tag=as3ccf0dad
Call-ID: 15c45d42484426be3a7fd56b2e4283e4@192.168.1.40:5060
CSeq: 102 INVITE
Server: IPBX-2.11.0.47(11.25.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3565f503"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '15c45d42484426be3a7fd56b2e4283e4@192.168.1.40:5060' in 6400 ms (Method: INVITE)

<--- SIP read from UDP:192.168.1.40:5060 --->
ACK sip:7502519749@192.168.1.220:2022 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.40:5060;branch=z9hG4bK20638727;rport
Max-Forwards: 70
From: <sip:904@192.168.1.40>;tag=as62391d02
To: <sip:7502519749@192.168.1.220:2022>;tag=as3ccf0dad
Contact: <sip:904@192.168.1.40:5060>
Call-ID: 15c45d42484426be3a7fd56b2e4283e4@192.168.1.40:5060
CSeq: 102 ACK
User-Agent: IPBX-2.11.0(11.25.3)
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---
Reliably Transmitting (NAT) to 192.168.1.204:5060:
OPTIONS sip:900@192.168.1.204:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.220:2022;branch=z9hG4bK77d34688;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@192.168.1.220:2022>;tag=as1663be47
To: <sip:900@192.168.1.204:5060>
Contact: <sip:Unknown@192.168.1.220:2022>
Call-ID: 1e667d3115773d2515b141e62d9f7569@192.168.1.220:2022
CSeq: 102 OPTIONS
User-Agent: IPBX-2.11.0.47(11.25.3)
Date: Mon, 01 Jan 2024 11:55:02 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


---
Retransmitting #1 (NAT) to 192.168.1.160:5060:
OPTIONS sip:192.168.1.160 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.220:2022;branch=z9hG4bK1d40d078;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@192.168.1.220:2022>;tag=as1dbd5889
To: <sip:192.168.1.160>
Contact: <sip:Unknown@192.168.1.220:2022>
Call-ID: 715f9c76226be7df1a4c51d424be78fc@192.168.1.220:2022
CSeq: 102 OPTIONS
User-Agent: IPBX-2.11.0.47(11.25.3)
Date: Mon, 01 Jan 2024 11:55:01 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


---
Retransmitting #1 (NAT) to 192.168.1.204:5060:
OPTIONS sip:900@192.168.1.204:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.220:2022;branch=z9hG4bK77d34688;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@192.168.1.220:2022>;tag=as1663be47
To: <sip:900@192.168.1.204:5060>
Contact: <sip:Unknown@192.168.1.220:2022>
Call-ID: 1e667d3115773d2515b141e62d9f7569@192.168.1.220:2022
CSeq: 102 OPTIONS
User-Agent: IPBX-2.11.0.47(11.25.3)
Date: Mon, 01 Jan 2024 11:55:02 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


---

<--- SIP read from UDP:192.168.1.205:5060 --->
OPTIONS sip:heartbeat@192.168.1.220:2022 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.205:5060;rport;branch=z9hG4bKZNcmFZ92g4SNF
Max-Forwards: 70
From: <sip:heartbeat@192.168.1.205>;tag=0K9SZ8eK69jvr
To: <sip:heartbeat@192.168.1.220:2022>
Call-ID: e0434c9f-21c5-123d-6898-f8a03d20bdb4
CSeq: 77414567 OPTIONS
Contact: <sip:heartbeat@192.168.1.205;transport=UDP>
User-Agent: DAG1000-8S DAG 2.81.10.03
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER
Supported: replaces
Allow-Events: refer, ua-profile, message-summary, check-sync, dialog, presence
Content-Length: 0

<------------->
--- (13 headers 0 lines) ---
Sending to 192.168.1.205:5060 (NAT)
Looking for heartbeat in from-CRM (domain 192.168.1.220)

<--- Transmitting (NAT) to 192.168.1.205:5060 --->
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 192.168.1.205:5060;branch=z9hG4bKZNcmFZ92g4SNF;received=192.168.1.205;rport=5060
From: <sip:heartbeat@192.168.1.205>;tag=0K9SZ8eK69jvr
To: <sip:heartbeat@192.168.1.220:2022>;tag=as4a43b4e4
Call-ID: e0434c9f-21c5-123d-6898-f8a03d20bdb4
CSeq: 77414567 OPTIONS
Server: IPBX-2.11.0.47(11.25.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'e0434c9f-21c5-123d-6898-f8a03d20bdb4' in 32000 ms (Method: OPTIONS)
Retransmitting #2 (NAT) to 192.168.1.160:5060:
OPTIONS sip:192.168.1.160 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.220:2022;branch=z9hG4bK1d40d078;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@192.168.1.220:2022>;tag=as1dbd5889
To: <sip:192.168.1.160>
Contact: <sip:Unknown@192.168.1.220:2022>
Call-ID: 715f9c76226be7df1a4c51d424be78fc@192.168.1.220:2022
CSeq: 102 OPTIONS
User-Agent: IPBX-2.11.0.47(11.25.3)
Date: Mon, 01 Jan 2024 11:55:01 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


---
Retransmitting #2 (NAT) to 192.168.1.204:5060:
OPTIONS sip:900@192.168.1.204:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.220:2022;branch=z9hG4bK77d34688;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@192.168.1.220:2022>;tag=as1663be47
To: <sip:900@192.168.1.204:5060>
Contact: <sip:Unknown@192.168.1.220:2022>
Call-ID: 1e667d3115773d2515b141e62d9f7569@192.168.1.220:2022
CSeq: 102 OPTIONS
User-Agent: IPBX-2.11.0.47(11.25.3)
Date: Mon, 01 Jan 2024 11:55:02 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


---
Retransmitting #3 (NAT) to 192.168.1.160:5060:
OPTIONS sip:192.168.1.160 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.220:2022;branch=z9hG4bK1d40d078;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@192.168.1.220:2022>;tag=as1dbd5889
To: <sip:192.168.1.160>
Contact: <sip:Unknown@192.168.1.220:2022>
Call-ID: 715f9c76226be7df1a4c51d424be78fc@192.168.1.220:2022
CSeq: 102 OPTIONS
User-Agent: IPBX-2.11.0.47(11.25.3)
Date: Mon, 01 Jan 2024 11:55:01 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

Here From 192.168.1.40 Server to 192.168.1.220 I make a call with caller ID as 904. But that call is unauthorized. Because 904 is an extension in 192.168.1.220 Server. Suppose If I fix different caller ID other than extension numbers(220 server extensions) then calls are accepted.

The Problem is external incoming call CallerID is one of the internal extension numbers then call is rejected.

4

This is a problem that typically happens when you use type=friend with chan_sip, but you should no longer be using chan_sip (it is not even in the latest source code), and you should not use type=friend without understanding where it is really needed - too many people copy and paste from examples where it is not needed.

If you really do need type=friend, you definitely need to upgrade to chan_pjsip, although you could modify the caller ID, or fix the From user and use other means to convey the caller ID.

With chan_pjsip you have to change the match order from the default for this to be a problem.

This also indicates why you need to provide details of your configuration.

Incidentally, neither the SIP RFCs, not Asterisk have a concept of a SIP trunk.

5

In 220 Server:

[SIPTrunk]
disallow=all
type=peer
qualify=yes
nat=yes
insecure=port,invite
host=192.168.1.40
dtmfmode=auto
context=from-internal
allow=ulaw
allow=alaw
allow=gsm
allow=all

This is in 40 Server.
[SIP]
type=peer
qualify=yes
nat=yes
insecure=port,invite
host=192.168.1.220
port=2022
dtmfmode=auto
disallow=all
context=from-pstn
allow=ulaw&alaw&gsm&al

I changed the type=peer also. Same call is rejected.


<--- SIP read from UDP:192.168.1.40:5060 --->
INVITE sip:7502519749@192.168.1.220:2022 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.40:5060;branch=z9hG4bK27b034f0;rport
Max-Forwards: 70
From: <sip:904@192.168.1.40>;tag=as1639db69
To: <sip:7502519749@192.168.1.220:2022>
Contact: <sip:904@192.168.1.40:5060>
Call-ID: 4fc3f60150c2a249457a866f42304850@192.168.1.40:5060
CSeq: 102 INVITE
User-Agent: IPBX-2.11.0(11.25.3)
Date: Mon, 01 Jan 2024 12:23:21 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 283

v=0
o=root 2132731282 2132731282 IN IP4 192.168.1.40
s=Asterisk PBX 11.25.3
c=IN IP4 192.168.1.40
t=0 0
m=audio 15960 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<------------->
--- (14 headers 13 lines) ---
Sending to 192.168.1.40:5060 (NAT)
Sending to 192.168.1.40:5060 (NAT)
Using INVITE request as basis request - 4fc3f60150c2a249457a866f42304850@192.168.1.40:5060
Found peer '904' for '904' from 192.168.1.40:5060

<--- Reliably Transmitting (no NAT) to 192.168.1.40:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.40:5060;branch=z9hG4bK27b034f0;received=192.168.1.40;rport=5060
From: <sip:904@192.168.1.40>;tag=as1639db69
To: <sip:7502519749@192.168.1.220:2022>;tag=as39a1f4d0
Call-ID: 4fc3f60150c2a249457a866f42304850@192.168.1.40:5060
CSeq: 102 INVITE
Server: IPBX-2.11.0.47(11.25.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="0202f2b6"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '4fc3f60150c2a249457a866f42304850@192.168.1.40:5060' in 6400 ms (Method: INVITE)

<--- SIP read from UDP:192.168.1.40:5060 --->
ACK sip:7502519749@192.168.1.220:2022 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.40:5060;branch=z9hG4bK27b034f0;rport
Max-Forwards: 70
From: <sip:904@192.168.1.40>;tag=as1639db69
To: <sip:7502519749@192.168.1.220:2022>;tag=as39a1f4d0
Contact: <sip:904@192.168.1.40:5060>
Call-ID: 4fc3f60150c2a249457a866f42304850@192.168.1.40:5060
CSeq: 102 ACK
User-Agent: IPBX-2.11.0(11.25.3)
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---
Retransmitting #4 (NAT) to 192.168.1.160:5060:
OPTIONS sip:192.168.1.160 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.220:2022;branch=z9hG4bK575754ea;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@192.168.1.220:2022>;tag=as35ef6ecf
To: <sip:192.168.1.160>
Contact: <sip:Unknown@192.168.1.220:2022>
Call-ID: 3787a07545922c7817b87d720d1825ff@192.168.1.220:2022
CSeq: 102 OPTIONS
User-Agent: IPBX-2.11.0.47(11.25.3)
Date: Mon, 01 Jan 2024 12:23:17 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


---
Really destroying SIP dialog '3787a07545922c7817b87d720d1825ff@192.168.1.220:2022' Method: OPTIONS
Really destroying SIP dialog '07b3982a5572f036548e370f146064ac@192.168.1.40:5060' Method: OPTIONS

<--- SIP read from UDP:192.168.1.205:5060 --->
OPTIONS sip:heartbeato@192.168.1.220:2022 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.205:5060;rport;branch=z9hG4bKXQevUc5cXrZDe
Max-Forwards: 70
From: <sip:heartbeato@192.168.1.205>;tag=D2Km2me6rNKvj
To: <sip:heartbeato@192.168.1.220:2022>
Call-ID: d4ee7311-21c9-123d-6898-f8a03d20bdb4
CSeq: 77415075 OPTIONS
Contact: <sip:heartbeato@192.168.1.205;transport=UDP>
User-Agent: DAG1000-8S DAG 2.81.10.03
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER
Supported: replaces
Allow-Events: refer, ua-profile, message-summary, check-sync, dialog, presence
Content-Length: 0

<------------->
--- (13 headers 0 lines) ---
Sending to 192.168.1.205:5060 (NAT)
Looking for heartbeato in from-CRM (domain 192.168.1.220)

<--- Transmitting (NAT) to 192.168.1.205:5060 --->
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 192.168.1.205:5060;branch=z9hG4bKXQevUc5cXrZDe;received=192.168.1.205;rport=5060
From: <sip:heartbeato@192.168.1.205>;tag=D2Km2me6rNKvj
To: <sip:heartbeato@192.168.1.220:2022>;tag=as54f72489
Call-ID: d4ee7311-21c9-123d-6898-f8a03d20bdb4
CSeq: 77415075 OPTIONS
Server: IPBX-2.11.0.47(11.25.3)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0

Please advice what to check and change? If I change Caller ID with other than remote server extension number, then call is accepted.

6

Do not use this unless you understand what it does. Asterisk doesn’t need insecure=port, and insecure=invite is meaningless without a secret, and in this case would nullify the use of the secret, if there were one. This is another example of copy and paste coding.

Your network topology does not require this, and, even if it did, the default of auto* should work.

This breaks some versions of Asterisk and can break the non-Asterisk remote systems.

al is not a valid codec. If you meant all, see above.

You haven’t shown the configuration for 904 on the UAS side. It is a type=friend there that will break this.

The channel driver. There is no real point in going into detail of how to avoid this on chan_sip given that you should not be using chan_sip.

7

This can be easily solved using the ‘from’ parameter on your SIP peer trunks.

8

I think you mean “fromuser”. However that will lose him the caller ID, and, as setting the caller ID wasn’t a solution, that appears to be important to him. Whist getting the caller ID back is easy, it means learning how to do it on an obsolete channel driver, when it would be better to start with the current one.

They shouldn’t have a problem on the current one as it matches IP addresses before user names, in its default configuration.

9

Correct the ‘fromuser’ parameter. ‘From’ is the SIP header related to losing the caller ID. You already know there are ways to override the caller ID set in the ‘fromuser’ parameter

10

The same configuration with different caller ID calls are no problem. Calls are landing perfectly.

The problem appearance when I fix the incoming call caller ID as one of the extension number that time only calls are rejected.

The Remote server has 904 as extension. I call the remote server from my server with caller ID 904 then call rejected. If I fix other than extension number then calls are accepted.

Due to other caller ID calls are working, I hope no problem in the SIP Trunk configuration. While I am sending CID as extension number then call is rejected because same number(904) is registered with different IP as extension.

11

It’s not because it is registered, it is because it is defined as type=friend, or type=user.

12

Hi @david551 ,

I solved this scenario using a fake caller id from my server 1(192.168.1.40) to server 2(192.168.1.220).

I set caller Id with prefix 0000. So if actual caller id is 904, then while reaching server 1 it will take as 0000904.

At remote server(192.168.1.220), I receive the call and then remove the caller id prefix 0000. Now calls are accepting and then in log also it is registerd as 904.

exten => _X.,1,Set(CDK=${CALLERID(num)})
exten => _X.,n,Set(CALLERID(num)=${CDK:4})
exten => _X.,n,Goto(from-internal,${EXTEN},1)
exten => _X.,n,Hangup()

Now I can get the call from remote server even I fix the server 2’s extension number as server 1’s incoming caller id.

13

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