Hello Guys,
I am using pjsip on the Android app. I receive an error when I send an asterisk system call with the application.
SIP/2.0 401 Unauthorized
How can this problem be solved?
Thankyou.
You haven’t provided enough information to be able to answer this. You’ll need to provide the configuration and the “pjsip set logger on” output with a call attempt.
401 is normal. It is asking the client to provide authentication data.
Dear Jcolp,
The log I see on the Asterisk side. Where can you get the error?
INVITE sip:908507750775@85.111.***.2517000 SIP/2.0
Via: SIP/2.0/UDP 5.11.183.6:50571;rport;branch=z9hG4bKPjcd712557-cd1f-4b0c-a449-c06ac0638cd9
Max-Forwards: 70
From: sip:8507750000@85.111.***.251;tag=66567853-8421-4e95-a8c9-b9ce3ff792c4
To: sip:908507750775@85.111.***.2517000
Contact: sip:8507750000@5.11.183.6:50571;ob;+sip.ice
Call-ID: 9b994fed-d83d-4ae2-99a6-46eb7830024d
CSeq: 15853 INVITE
Route: sip:85.111.:7000***.251;transport=udp;lr;port=7000
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: Pjsua2 Android 2.7-svn
Content-Type: application/sdp
Content-Length: 667
v=0
o=- 3718426220 3718426220 IN IP4 5.11.183.6
s=pjmedia
b=AS:84
t=0 0
a=X-nat:0
m=audio 53711 RTP/AVP 18 3 98 97 99 104 0 8 9 96
c=IN IP4 5.11.183.6
b=TIAS:64000
a=rtcp:44416 IN IP4 5.11.183.6
a=sendrecv
a=rtpmap:18 G729/8000
a=rtpmap:3 GSM/8000
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:99 speex/32000
a=rtpmap:104 iLBC/8000
a=fmtp:104 mode=30
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ice-ufrag:272f9f0b
a=ice-pwd:2ca0c046
a=candidate:H50bb706 1 UDP 2130706431 5.11.183.6 53711 typ host
a=candidate:H50bb706 2 UDP 2130706430 5.11.183.6 44416 typ host
U 2017/10/31 11:10:22.586283 85.111.***.251:5060 -> 5.11.183.6:50571
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 5.11.183.6:50571;branch=z9hG4bKPjcd712557-cd1f-4b0c-a449-c06ac0638cd9;received=5.11.183.6;rport=50571
From: sip:8507750000@85.111.***.251;tag=66567853-8421-4e95-a8c9-b9ce3ff792c4
To: sip:908507750775@85.111.***.2517000;tag=as4e4d2c28
Call-ID: 9b994fed-d83d-4ae2-99a6-46eb7830024d
CSeq: 15853 INVITE
Server: FPBX-2.8.1(1.8.20.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="5b3b4c6e"
Content-Length: 0
U 2017/10/31 11:10:22.621172 5.11.183.6:50571 -> 85.111.***.251:5060
ACK sip:908507750775@85.111.***.2517000 SIP/2.0
Via: SIP/2.0/UDP 5.11.183.6:50571;rport;branch=z9hG4bKPjcd712557-cd1f-4b0c-a449-c06ac0638cd9
Max-Forwards: 70
From: sip:8507750000@85.111.***.251;tag=66567853-8421-4e95-a8c9-b9ce3ff792c4
To: sip:908507750775@85.111.***.2517000;tag=as4e4d2c28
Call-ID: 9b994fed-d83d-4ae2-99a6-46eb7830024d
CSeq: 15853 ACK
Route: sip:85.111.:7000***.251;transport=udp;lr;port=7000
Content-Length: 0
U 2017/10/31 11:10:22.630246 85.111.***.251:5060 -> 5.11.183.6:50571
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 5.11.183.6:50571;branch=z9hG4bKPj6d046aea-2d39-4a97-8a1d-0c3299da9b2c;received=5.11.183.6;rport=50571
From: sip:8507750000@85.111.***.251;tag=66567853-8421-4e95-a8c9-b9ce3ff792c4
To: sip:908507750775@85.111.***.2517000
Call-ID: 9b994fed-d83d-4ae2-99a6-46eb7830024d
CSeq: 15854 INVITE
Server: FPBX-2.8.1(1.8.20.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: sip:908507750775@85.111.:5060***.251
Content-Length: 0
U 2017/10/31 11:10:22.637696 85.111..251:5060 -> 85.111.*.101:5060
INVITE sip:908507750775@register..com:5060 SIP/2.0
Via: SIP/2.0/UDP 85.111..251:5060;branch=z9hG4bK1516ccda
Max-Forwards: 70
From: “908507750000” sip:908507750000@register.*****.com;tag=as23416e22
To: sip:908507750775@register.:5060*****.com
Contact: sip:908507750000@85.111.:5060***.251
Call-ID: 6b144b0d67ede49f3754d6753c226b8f@register.***.com
CSeq: 102 INVITE
User-Agent: FPBX-2.8.1(1.8.20.0)
Date: Tue, 31 Oct 2017 08:10:22 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 262
v=0
o=root 1527931971 1527931971 IN IP4 85.111.***.251
s=Asterisk PBX 1.8.20.0
c=IN IP4 85.111.***.251
t=0 0
m=audio 18640 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
There are no errors in that log. It looks like the phone simply doesn’t know how to authenticate itself, so gives up when asked.
@david551 is correct - we asked for it to authenticate and it didn’t. You’ll need to look at the endpoint itself.
What do you need to do here? I have to look at the asterisk side. Or pjsip on the android side?
Depends on whether it is supposed to be authenticated by anything but IP address.
I need check authentication. But with pjsip I cannot provide this. , I can find the necessary code for this operation.
Dear All,
I need check on my system. As far as I can see, Authorization Header is not found in pjsip.
How can add authorization headers for pjsip
If you are asking how to do it inside of PJSIP on the endpoint then your question is probably better asked on the PJSIP mailing list instead.
1 Like
dear jcolp,
I do not have much experience in this regard. But our system chan_sip works. So asterisk, swich, sbc etc …
An app was written on Android. I see that the app is on pjsip. We have a problem with pjsip located on android, sending calls to chan_sip servers installed on FreeBSD or Centos. Is not that possible? So we do not have to send a call to chan_sip with pjsip?
There are numerous users who are connecting PJSIP based endpoints to chan_pjsip. From the information you’ve provided there is nothing out of the ordinary on the chan_pjsip side. We received a call without authentication, we challenged for authentication, and they didn’t try with authentication.
If you cut out parts of the log then the analysis might be incorrect but based on what you have provided I don’t really have anything else to suggest or say.
What can be the solution in this regard. Any suggestions? What can I do on the Asterisk side.
Asterisk can’t force an endpoint to do things. If it doesn’t retry the call with authentication details, there’s nothing we can do. You should make sure that the logs you have provided aren’t missing any details and check the endpoint configuration. I’ll also add because I misread something, there are also numerous people using PJSIP endpoints against chan_sip.
Finally Asterisk 1.8 has been end of life for quite some time. You can continue to use it, but it probably has numerous security vulnerabilities.
Actually my problem is a bit more complicated. We are successful in the tests we make over the turkey network. But there is an authentication problem other than turkey. At first it looked like a firewall, but it’s not exactly a problem.
I will check the logs in more detail. Thank you for sharing information.
Hi dear,
I solved the problem. In addition, I want to ask you something.
How can I allow sip streaming over tcp on Asterisk 1.8. (first udp, secound tcp)
Install a TCP based VPN. NB this is indadvisable for VoIP because a single lost packet can cause a large and obvious gap in the audio.