[asterisk-bugs] [JIRA] (ASTERISK-28185) chan_pjsip: Subsequent same responses are not stopped

[Gregory Massel (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252680#comment-252680 ] 

Gregory Massel edited comment on ASTERISK-28185 at 11/6/20 11:33 AM:
---------------------------------------------------------------------

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.


was (Author: gmza):
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.

> chan_pjsip: Subsequent same responses are not stopped
> -----------------------------------------------------
>
>                 Key: ASTERISK-28185
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28185
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 16.3.0
>            Reporter: Julien
>            Assignee: Unassigned
>            Severity: Trivial
>              Labels: patch, pjsip
>         Attachments: ASTERISK-28185.diff
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)