SIP/2.0 401 Unauthorized for incoming calls on bsnl wings sip account

Asterisk Asterisk SIP
1

hi,
i have a sip trunk from bsnl wings provider.i have registered successfully using registration string, its configuration is below

[bsnl]
username=+919188993969
secret=xxxxxxx
qualify=yes
;nat=yes
insecure=very
host=kl.voip.ims.bsnl.in
outboundproxy=blr.sbc.ims.bsnl.in
outboundproxyport=80
fromuser=+919188993969
fromdomain=kl.voip.ims.bsnl.in
dtmfmode=inband
dtmf=inband
context=inbound
canreinvite=no
authname=+919188993969
auth=+91918899396
type=peer
port=5060
allow=all

SIP Debug Output for Incoming Call is

<--- SIP read from UDP:218.248.233.142:5060 --->
INVITE tel:+919188993969 SIP/2.0
Via: SIP/2.0/UDP 218.248.233.142:5060;branch=z9hG4bK2406al74v79koafvv609406ttT39436
Call-ID: asbc8nl21lfj6ik2i2nq8m2rlhjiqlq2hmfl@10.191.54.18
From: <sip:9895909009@218.248.233.141>;tag=sbc0505gl2mmq1r
To: <tel:+919188993969>
CSeq: 1 INVITE
Alert-Info: <file:///PacketCableRST/>;info=pattern2
Allow: UPDATE,INFO,PRACK,NOTIFY,REFER,SUBSCRIBE,OPTIONS,INVITE,ACK,BYE,CANCEL
Contact: <sip:218.248.233.142:5060;TRC=ffffffff-ffffffff;Dpt=ecaa-200>
Max-Forwards: 66
Supported: timer,100rel,histinfo,early-session
Session-Expires: 1800
Min-SE: 600
P-Asserted-Identity: <tel:+919895909009>
Privacy: none
P-Called-Party-ID: <tel:+919188993969>
P-Notification: caller-control
Content-Length: 301
Content-Type: application/sdp
Content-Disposition: session

v=0
o=- 128556025 128556025 IN IP4 218.248.233.130
s=SBC call
c=IN IP4 218.248.233.130
t=0 0
m=audio 20962 RTP/AVP 8 96 0 18
c=IN IP4 218.248.233.130
a=rtpmap:8 PCMA/8000/1
a=rtpmap:96 telephone-event/8000/1
a=fmtp:96 0-15
a=sendrecv
a=3gOoBTC
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
<------------->
--- (20 headers 14 lines) ---
Sending to 218.248.233.142:5060 (no NAT)
Sending to 218.248.233.142:5060 (no NAT)
Using INVITE request as basis request - asbc8nl21lfj6ik2i2nq8m2rlhjiqlq2hmfl@10.191.54.18
Found peer 'bsnl' for '9895909009' from 218.248.233.142:5060

<--- Reliably Transmitting (no NAT) to 218.248.233.142:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 218.248.233.142:5060;branch=z9hG4bK2406al74v79koafvv609406ttT39436;received=218.248.233.142
From: <sip:9895909009@218.248.233.141>;tag=sbc0505gl2mmq1r
To: <tel:+919188993969>;tag=as20635fc7
Call-ID: asbc8nl21lfj6ik2i2nq8m2rlhjiqlq2hmfl@10.191.54.18
CSeq: 1 INVITE
Server: Asterisk PBX certified/16.8-cert12
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4e5dca22"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'asbc8nl21lfj6ik2i2nq8m2rlhjiqlq2hmfl@10.191.54.18' in 11008 ms (Method: INVITE)
Retransmitting #1 (no NAT) to 218.248.233.142:5060:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 218.248.233.142:5060;branch=z9hG4bK2406al74v79koafvv609406ttT39436;received=218.248.233.142
From: <sip:9895909009@218.248.233.141>;tag=sbc0505gl2mmq1r
To: <tel:+919188993969>;tag=as20635fc7
Call-ID: asbc8nl21lfj6ik2i2nq8m2rlhjiqlq2hmfl@10.191.54.18
CSeq: 1 INVITE
Server: Asterisk PBX certified/16.8-cert12
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4e5dca22"
Content-Length: 0


---

<--- SIP read from UDP:218.248.233.142:5060 --->
ACK tel:+919188993969 SIP/2.0
Via: SIP/2.0/UDP 218.248.233.142:5060;branch=z9hG4bK2406al74v79koafvv609406ttT39436;received=218.248.233.142
Call-ID: asbc8nl21lfj6ik2i2nq8m2rlhjiqlq2hmfl@10.191.54.18
From: <sip:9895909009@218.248.233.141>;tag=sbc0505gl2mmq1r
To: <tel:+919188993969>;tag=as20635fc7
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---

<--- SIP read from UDP:218.248.233.142:5060 --->
ACK tel:+919188993969 SIP/2.0
Via: SIP/2.0/UDP 218.248.233.142:5060;branch=z9hG4bK2406al74v79koafvv609406ttT39436;received=218.248.233.142
Call-ID: asbc8nl21lfj6ik2i2nq8m2rlhjiqlq2hmfl@10.191.54.18
From: <sip:9895909009@218.248.233.141>;tag=sbc0505gl2mmq1r
To: <tel:+919188993969>;tag=as20635fc7
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0
2

Like many sip.conf samples we see here, your configuration contains many deprecated, misused and non-existent options, typically as a result of copying bad examples. Unfortunately, one of those deprecated options, at least, has gone to the next stage and been completely removed, namely insecure=very (because it is really two options and they both make Asterisk less secure; you only needed one of them).

Rather than fixing insecure, there is a better way of achieving what it was trying to do, which is to replace “secret” by “remotesecret”. This has existed for a long time, although not as long as insecure=very has been deprecated, and better describes what insecure=invite is trying to achieve.

You should also not use allow=all, but rather disallow everything, then allow the codecs you actually expect to use. There is a live bug relating to this, and it is not a sensible thing to do, even without the bug.

As I understand the way that chan_sip handles multiple DNS A records, you may also need to add peer entries for each IP address that your provider can use. You got away with that in the current example, but it may cause intermittent failures.

chan_sip, as a whole, is deprecated, and will be removed next year. However, your provider is using tel: URIs. Neither chan_sip, nor chan_pjsip, officially support these, but to avoid the risk of untested cases involving them leading to a security breach, chan_pjsip rejects them. Please try to get your provider to be compatible with the core SIP requirements and only use sip: URIs, allowing you to move to chan_pjsip.

Failing that, please go carefully through sip.conf.sample and correct your sip.conf based on a proper understanding of the purposes of options.

3

i have changed to

insecure=invite
remotesecret=xxxxx

After changing still facing the same issue, no incoming or outgoing

4

Please provide updated logs. Please do so for both incoming and outgoing.

5 
<--- SIP read from UDP:218.248.233.142:5060 --->
INVITE tel:+919188993969 SIP/2.0
Via: SIP/2.0/UDP 218.248.233.142:5060;branch=z9hG4bKelyegdmfvyjdcs3jzvyizh3zhT02698
Call-ID: asbcizp3jm5y5w5wyxjppr305w5w0mrpr5zy@10.191.54.18
From: <sip:9895909009@218.248.233.141>;tag=sbc0503p5ryg6js
To: <tel:+919188993969>
CSeq: 1 INVITE
Alert-Info: <file:///PacketCableRST/>;info=pattern2
Allow: UPDATE,INFO,PRACK,NOTIFY,REFER,SUBSCRIBE,OPTIONS,INVITE,ACK,BYE,CANCEL
Contact: <sip:218.248.233.142:5060;TRC=ffffffff-ffffffff;Dpt=ec2a-200>
Max-Forwards: 66
Supported: timer,100rel,histinfo,early-session
Session-Expires: 1800
Min-SE: 600
P-Asserted-Identity: <tel:+919895909009>
Privacy: none
P-Called-Party-ID: <tel:+919188993969>
P-Notification: caller-control
Content-Length: 304
Content-Type: application/sdp
Content-Disposition: session

v=0
o=- 120839114 120839114 IN IP4 218.248.233.130
s=SBC call
c=IN IP4 218.248.233.130
t=0 0
m=audio 49268 RTP/AVP 8 101 0 18
c=IN IP4 218.248.233.130
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000/1
a=fmtp:101 0-15
a=sendrecv
a=3gOoBTC
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
<------------->
--- (20 headers 14 lines) ---
Sending to 218.248.233.142:5060 (no NAT)
Sending to 218.248.233.142:5060 (no NAT)
Using INVITE request as basis request - asbcizp3jm5y5w5wyxjppr305w5w0mrpr5zy@10.191.54.18
No matching peer for '9895909009' from '218.248.233.142:5060'

<--- Reliably Transmitting (no NAT) to 218.248.233.142:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 218.248.233.142:5060;branch=z9hG4bKelyegdmfvyjdcs3jzvyizh3zhT02698;received=218.248.233.142
From: <sip:9895909009@218.248.233.141>;tag=sbc0503p5ryg6js
To: <tel:+919188993969>;tag=as361f3f74
Call-ID: asbcizp3jm5y5w5wyxjppr305w5w0mrpr5zy@10.191.54.18
CSeq: 1 INVITE
Server: Asterisk PBX certified/16.8-cert12
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4797d794"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'asbcizp3jm5y5w5wyxjppr305w5w0mrpr5zy@10.191.54.18' in 32000 ms (Method: INVITE)

<--- SIP read from UDP:218.248.233.142:5060 --->
ACK tel:+919188993969 SIP/2.0
Via: SIP/2.0/UDP 218.248.233.142:5060;branch=z9hG4bKelyegdmfvyjdcs3jzvyizh3zhT02698;received=218.248.233.142
Call-ID: asbcizp3jm5y5w5wyxjppr305w5w0mrpr5zy@10.191.54.18
From: <sip:9895909009@218.248.233.141>;tag=sbc0503p5ryg6js
To: <tel:+919188993969>;tag=as361f3f74
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0

<------------->

INCOMING LOG

6

You’ve been caught by the inability of chan_sip to cope with more than one source iP address per peer. See:

There work arounds for this are either to duplicate your peer entries, with different names, using explicit IP addresses, for each IP address returned for the providers’ A record:

kl.voip.ims.bsnl.in. 3600 IN A 218.248.233.198
kl.voip.ims.bsnl.in. 3600 IN A 218.248.233.142

or to enable allowguest and rely on your firewalls to limit traffic to only legitimate addresses. chan_pjsip would, for example, allow you to match 218/248.233/24, and several other ranges so is the better solution, except for tel: URI issue.

You haven’t fixed the allow=all problem, which will probably break outbound calls.

7

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