Summary:	ASTERISK-28185: chan_pjsip: Subsequent same responses are not stopped
Reporter:	Julien (tigood)	Labels:	patch pjsip
Date Opened:	2018-11-27 07:28:15.000-0600	Date Closed:	2021-01-11 11:35:14.000-0600
Priority:	Minor	Regression?	Yes
Status:	Closed/Complete	Components:	Channels/chan_pjsip
Versions:	16.3.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) ASTERISK-28185.diff
Description:	If i use Pjsip, every calls with a Session Progress will be sent 2 times to the first channel. With ChanSip, only one Session Progress is sent (good). The problem is the same in Asterisk 13/15/16.
Comments:	By: Asterisk Team (asteriskteam) 2018-11-27 07:28:16.401-0600 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: Joshua C. Colp (jcolp) 2018-11-27 07:30:25.682-0600 Is this causing an actual problem? The fact that it was sent twice shouldn't matter and is permitted in SIP. By: Julien (tigood) 2018-11-27 07:35:03.449-0600 Yes, because i use Asterisk in a clood : Gateway operator (asterisk) -> Backbone (Asterisk) ->  loadbalancer(Asterisk) -> Centrex (Asterisk). On that way, any Session Progress will be repeated 2^(number voice router). In my case, i have 16 Session progress on one call, and i am blacklisted for flooding. With ChanSIP, the behaviour was different and correct. But Pjsip is the futur.... By: Julien (tigood) 2018-12-12 02:53:05.413-0600 i have tried the version 16.1.0. The problem is the same. Do you think the problem is in the source Asterisk, or in the PjSip bundle code ? By: Joshua C. Colp (jcolp) 2018-12-12 04:40:18.533-0600 The chan_pjsip module does not keep track of the response that was sent and thus does not prevent it from being sent again. It's in Asterisk code. By: Julien (tigood) 2019-04-09 06:21:40.280-0500 The problem is not to track is a response has already been sent. The problem is that a receive only ONE 183, but Asterisk transmits TWO. By: Julien (tigood) 2019-04-09 06:37:58.038-0500 i have made a patch in asterisk 16.3.0 : Only one 183 Session Progress will be send : <inline patch removed> Thank works fine for me. Can you merge this for a futur release ? Thank you. By: Joshua C. Colp (jcolp) 2019-04-09 06:39:29.794-0500 The patch contribution process is documented on the wiki[1]. You are free to attach a patch, but putting it through code review will get it into the tree quicker. [1] https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process By: Julien (tigood) 2019-04-10 03:55:57.016-0500 My patch. By: Gregory Massel (gmza) 2020-11-06 11:32:28.977-0600 Please may I request that this be reviewed for escalation. While I didn't report it, I am struggling with the same issue and it has been logged for almost two years now. We have loop mitigations in place, however, where a SIP trunk has, for example, 30 channels, and a series of numbers are forwarded in a loop, it is still possible to cause 2^30 (over a billion) 183 messages. The result is routine denial-of-service of our Asterisk boxes with a flood of log entries "channel.c: Exceptionally long queue length queuing to PJSIP/[..]" and hanging of the Asterisk processs. Aside from the denial-of-service, there are various CPE devices that cannot cope with a large number of 183's. e.g. Yealink W80B multi-dect base will, if it receives ~8x 183 messages, immediately issue a CANCEL and tear the call down. RTX iServ units with older firmware also tear down the calls (although newer firmware does seem to allow more - but not infinite - repeated 183's before tearing the call down). I don't believe that the rating of "Trivial" is appropriate. Perhaps having multiple production Asterisk boxes crashed on more ocassions than I can even recall and having forced clients to replace costly CPE equipment means that I have a different perspective to most of the triviality of this, but I find it difficult to believe that others are not encountering similar problems and, in particular, suffering denial-of-service where calls loops happen because a basic hop counter cannot mitigate a 2^n amplification of resource consumption. Note this is still an issue as of Asterisk 16.14.0. By: Florian Floimair (f.floimair) 2020-12-17 08:50:25.615-0600 We are running into the same problem and Joshua pointed me to this issue. I will try looking into that after the christmas holidays and see if I can come up with a solution. Btw: Why was the inline patch removed by the submitter? It might be a good hint on where to start looking, that's why I'm asking. By: Joshua C. Colp (jcolp) 2020-12-17 08:55:57.308-0600 We don't allow inline patches to ensure that all patches on the issue tracker are under a license agreement. By: Julien (tigood) 2020-12-17 09:33:46.438-0600 Hi @florian. I've sent you by email the patch if it can helps. By: Friendly Automation (friendly-automation) 2021-01-11 11:35:15.468-0600 Change 15304 merged by Friendly Automation: chan_pjsip: Stop queueing control frames twice on outgoing channels [https://gerrit.asterisk.org/c/asterisk/+/15304|https://gerrit.asterisk.org/c/asterisk/+/15304] By: Friendly Automation (friendly-automation) 2021-01-11 12:16:56.826-0600 Change 15286 merged by Friendly Automation: chan_pjsip: Stop queueing control frames twice on outgoing channels [https://gerrit.asterisk.org/c/asterisk/+/15286|https://gerrit.asterisk.org/c/asterisk/+/15286] By: Friendly Automation (friendly-automation) 2021-01-11 12:48:09.721-0600 Change 15287 merged by George Joseph: chan_pjsip: Stop queueing control frames twice on outgoing channels [https://gerrit.asterisk.org/c/asterisk/+/15287|https://gerrit.asterisk.org/c/asterisk/+/15287]