Summary:	ASTERISK-29059: Asterisk sends endless INVITE requests even call is ended
Reporter:	Ruslan Lazin (laz)	Labels:
Date Opened:	2020-09-01 04:54:49	Date Closed:	2020-11-03 10:18:16.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	pjproject/pjsip
Versions:	14.7.8 16.11.1 17.5.1	Frequency of Occurrence
Related Issues:	duplicates ASTERISK-29013 res_pjsip: Asterisk doesn't stop sending invites (with auth) on 407 replies
Environment:	CentOS7	Attachments:
Description:	Lets say we have proxy that always return "SIP/2.0 407 Proxy Authentication Required" and "nonce" is different in each answer. Once we originate outgoing call to such server Asterisk falls to infinitive loop sending new INVITE after receiving 407 answer. It might be hundreds of thousands INVITE requests. Even when call is stopped ('core show channels' returns 0 active calls/channels) requests are still sending. Only Asterisk restart can stop INVITE sending. To reproduce: - Create a server that responses with "SIP/2.0 407 Proxy Authentication Required" and new nonce to every INVITE request. For test proposes you can use mine (sip.lazin.pp.ua:5060   - will be active till 31 Sep 2020) or use sipp (scenario attached) - Make an outbound call to anything@your_proxy - stop call in any way (e.g 'channel request hangup all' in cli.) - run ngrep and see that asterisk still sends thousands of INVITE - restart asterisk to stop INVITE requests.
Comments:	By: Asterisk Team (asteriskteam) 2020-09-01 04:54:50.493-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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. 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]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. By: Joshua C. Colp (jcolp) 2020-09-01 04:58:48.195-0500 This is already a known issue. I've marked it as a security issue, but full analysis has not yet been done to determine if it will be treated as a security issue. By: Ruslan Lazin (laz) 2020-09-01 05:01:39.958-0500 SIPp scenario to reproduce the issue {code:xml} <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE scenario SYSTEM "sipp.dtd">                                                                   --> <scenario name="UAS answer 407 with new nonce"> <nop>  <action>    <assign assign_to="var" value="0" />  </action> </nop> <label id="start_of_loop" /> <recv request="ACK" crlf="true" optional="true">  </recv> <recv request="INVITE" crlf="true">  </recv> <send> <![CDATA[  SIP/2.0 407 Proxy Authentication Required  [last_Via:]  [last_From:]  [last_To:];tag=[pid]SIPpTag01[call_number]  [last_Call-ID:]  [last_CSeq:]  Contact: <sip:[local_ip]:[local_port];transport=[transport]>  Proxy-Authenticate: Digest realm="sip.lazin.pp.ua", nonce="5f4cddbd0001196ceb6b5e97c5cd381727630c7cf2bd8f5[$var]", qop="auth"  Server: SIP Proxy  Content-Length: 0 ]]>  </send>   <nop>  <action> <add assign_to="var" value="1" /> <!-- $1 == 0 -->  </action> </nop> <nop next="start_of_loop"/> </scenario> {code} By: Benjamin Keith Ford (bford) 2020-11-03 10:18:17.062-0600 I'm closing this issue out as it's a duplicate and not considered a security issue. A review is about to go up on Gerrit for a fix, so it is still being worked!