Summary:	ASTERISK-25372: SIP/2.0 401 Unauthorized for incoming calls.
Reporter:	Agasthian P (agasasterisk)	Labels:
Date Opened:	2015-09-03 23:18:47	Date Closed:	2015-09-08 18:08:39
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:	11.19.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	SHMZ release 6.5 (Final) Linux knaufsappdc 2.6.32-431.el6.x86_64 Running on a Virtual Environment. VMWare	Attachments:	( 0) coretracing.txt ( 1) sipconffiles1 ( 2) siptrace.txt
Description:	Running Freepbx on top of Asterisk 11.19.0. SIP trunk between Cisco Call Manager and FreePbx Asterisk. All the incoming calls from the Cisco Call Manager through SIP trunk are getting the error "SIP/2.0 401 Unauthorized". The Cisco Call Manager SIP trunks are treated as peer to peer and do not need any kind of registration. Have checked all the settings required to not enable any kind of authentication, still it seems to be asking for authentication. Tried the forums first, and have taken care of the following settings :- 1. insecure=invite,port 2.qualify=yes 3. type=friend 4. allow sip guests= yes 5. Allow Anonymous Inbound SIP Calls=yes The sip logs and the sip configuration files are attached as files. Call Flow :- FreePBX(20.1.1.58) - CUCM(20.1.1.170) 2723 extension is in both the systems. And 2723(CUCM) is trying to call 2723(Asterisk).
Comments:	By: Asterisk Team (asteriskteam) 2015-09-03 23:18:49.314-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Agasthian P (agasasterisk) 2015-09-03 23:33:34.668-0500 SIP Trace for the call By: Agasthian P (agasasterisk) 2015-09-03 23:34:12.557-0500 SIP configuration files By: Agasthian P (agasasterisk) 2015-09-04 00:04:35.512-0500 Core and Verbose tracing for the call. Just the snippet. By: Rusty Newton (rnewton) 2015-09-05 11:26:42.168-0500 You shouldn't need insecure=invite,port to do what you want and that is probably very unsafe. Your debug indicates that Asterisk is matching up and identifying the peer. So I believe if you remove the "secret" option for your peer then Asterisk should not require password authentication for that peer. You should consult with the FreePBX community about the best way to do that. This appears to be a support issue and not a bug. {noformat} [2723] deny=0.0.0.0/0.0.0.0 secret=7165316a8ba3e6de9b6d8bd28777f1bc dtmfmode=rfc2833 canreinvite=no context=from-internal host=dynamic trustrpid=yes mediaencryption=no sendrpid=pai type=friend nat=force_rport,comedia port=5060 qualify=yes qualifyfreq=60 transport=udp,tcp,tls avpf=no force_avp=no icesupport=no encryption=no callgroup= pickupgroup= dial=SIP/2723 mailbox=2723@default permit=0.0.0.0/0.0.0.0 callerid=Agasthian <2723> callcounter=yes faxdetect=no cc_monitor_policy=generic {noformat} By: Agasthian P (agasasterisk) 2015-09-06 18:44:12.763-0500 Hi Rusty Newton, Thanks a ton for your suggestion. It worked without the insecure=invite,port and removing the secret from the extensions. This was my first query and i never thought i would ever get a reply for this, but just feel good that the team took time to go through this and reply. I thought this is a bug, i am really sorry for that, below is my explanation. I have worked in other companies as an engineer where getting a reply on bug submission to an engineer from the same company takes weeks. And this is quite awesome as an Opensource thingy. I hope i am able to contribute more to the team. Why i felt it is being rejected by the Asterisk server directly, but not by the peer is because it was Asterisk sending "SIP/2.0 401 Unauthorized" directly for the Invite sent by the other PBX. If this was because of the SIP extension, i would expect it later after communicating with the extension. Don;t you think, the logs for the sip call is mis-leading and not as per RFC ? Makes us think, the other PBX requires authentication to initiate a call.  Or maybe i might be still missing something important. CUCM - Asterisk Invite                      ---> 401 Unauthorised <--- Ack                        ----> Logs for the failure call :- {noformat} INVITE sip:2723@20.1.1.58:5060 SIP/2.0 Via: SIP/2.0/UDP 20.1.1.170:5060;branch=z9hG4bK36a362292c0ca From: <sip:2723@20.1.1.170>;tag=730648~4ab333c0-314e-1172-16a8-eca8c1530263-31440129 To: <sip:2723@20.1.1.58> Date: Sun, 06 Sep 2015 09:45:57 GMT Call-ID: 116abe00-5ec10b55-311d9-aa010114@20.1.1.170 Supported: timer,resource-priority,replaces Min-SE: 1800 User-Agent: Cisco-CUCM10.5 Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY CSeq: 101 INVITE Expires: 180 Allow-Events: presence Supported: X-cisco-srtp-fallback,X-cisco-original-called Cisco-Guid: 0292208128-0000065536-0000002366-2852192532 Session-Expires: 1800 P-Asserted-Identity: <sip:2723@20.1.1.170> Remote-Party-ID: <sip:2723@20.1.1.170>;party=calling;screen=yes;privacy=off Contact: <sip:2723@20.1.1.170:5060>;bfcp Max-Forwards: 69 Content-Type: application/sdp Content-Length: 198 v=0 o=CiscoSystemsCCM-SIP 730648 1 IN IP4 20.1.1.170 s=SIP Call c=IN IP4 20.1.1.170 t=0 0 m=audio 25502 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 <-------------> --- (22 headers 9 lines) --- Sending to 20.1.1.170:5060 (no NAT) Sending to 20.1.1.170:5060 (no NAT) Using INVITE request as basis request - 116abe00-5ec10b55-311d9-aa010114@20.1.1.170 Found peer '2723' for '2723' from 20.1.1.170:5060 <--- Reliably Transmitting (NAT) to 20.1.1.170:5060 ---> SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 20.1.1.170:5060;branch=z9hG4bK36a362292c0ca;received=20.1.1.170;rport=5060 From: <sip:2723@20.1.1.170>;tag=730648~4ab333c0-314e-1172-16a8-eca8c1530263-31440129 To: <sip:2723@20.1.1.58>;tag=as37a2e028 Call-ID: 116abe00-5ec10b55-311d9-aa010114@20.1.1.170 CSeq: 101 INVITE Server: FPBX-12.0.76(11.19.0) Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="716cae18" Content-Length: 0 <------------> Scheduling destruction of SIP dialog '116abe00-5ec10b55-311d9-aa010114@20.1.1.170' in 25472 ms (Method: INVITE) knaufsappdc*CLI>  <--- SIP read from UDP:20.1.1.170:5060 ---> ACK sip:2723@20.1.1.58:5060 SIP/2.0 Via: SIP/2.0/UDP 20.1.1.170:5060;branch=z9hG4bK36a362292c0ca From: <sip:2723@20.1.1.170>;tag=730648~4ab333c0-314e-1172-16a8-eca8c1530263-31440129 To: <sip:2723@20.1.1.58>;tag=as37a2e028 Date: Sun, 06 Sep 2015 09:45:57 GMT Call-ID: 116abe00-5ec10b55-311d9-aa010114@20.1.1.170 User-Agent: Cisco-CUCM10.5 Max-Forwards: 70 CSeq: 101 ACK Allow-Events: presence Content-Length: 0 ---------------------------------------------------------------- Thanks a lot ! {noformat} By: Rusty Newton (rnewton) 2015-09-08 19:06:04.190-0500 bq. Thanks a ton for your suggestion. It worked without the insecure=invite,port and removing the secret from the extensions. Great! Glad to help out. bq. This was my first query and i never thought i would ever get a reply for this, but just feel good that the team took time to go through this and reply. I thought this is a bug, i am really sorry for that, below is my explanation. I have worked in other companies as an engineer where getting a reply on bug submission to an engineer from the same company takes weeks. And this is quite awesome as an Opensource thingy. I hope i am able to contribute more to the team. We are glad to have you in the community! The speed of a response in opensource communities often depends on whether someone is interested or not due to the nature of thing. We of course try to get things taken care of quickly where possible. There are plenty of ways to help out.. if you are looking for something to do please ask on #asterisk-dev on irc.freenode.net or the asterisk-dev mailing list. bq. Why i felt it is being rejected by the Asterisk server directly, but not by the peer is because it was Asterisk sending "SIP/2.0 401 Unauthorized" directly for the Invite sent by the other PBX. If this was because of the SIP extension, i would expect it later after communicating with the extension. Don;t you think, the logs for the sip call is mis-leading and not as per RFC ? Makes us think, the other PBX requires authentication to initiate a call. Or maybe i might be still missing something important. Asterisk is a Back to Back user agent. https://en.wikipedia.org/wiki/Back-to-back_user_agent. Asterisk is challenging the request directly and it is according to the RFC. You may have noticed that [~rmudgett] has closed out the issue since there is no bug here.  If you have further questions about the call behavior for chan_sip or for the new chan_pjsip driver (in 13) the appropriate place would be on the Asterisk mailing lists and forums. http://www.asterisk.org/community/discuss Thanks again! Feel free to E-mail me directly if you ever have questions about the community or are looking for specific documentation - rnewton at digium dot com! We are looking forward to your contributions.