[asterisk-bugs] [JIRA] (ASTERISK-28962) Asterisk Memory Leak after SIP Reply Flood

[Asterisk Team (JIRA)]

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

Asterisk Team commented on ASTERISK-28962:
------------------------------------------

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

> Asterisk Memory Leak after SIP Reply Flood
> ------------------------------------------
>
>                 Key: ASTERISK-28962
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28962
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 16.6.1
>         Environment: Amazon Linux 2 (CentOS based)
>            Reporter: Jonas Swiatek
>            Assignee: Jonas Swiatek
>         Attachments: invite_recv.xml
>
>
> I've got a user with a SIP Client (MicroSIP) that some times goes haywire, and responds to the initial INVITE from Asterisk by retransmitting it's 180 Ringing on a loop, seemingly unbounded. We're talking thousands of the same reply. I haven't been able to retrieve all of them from Homer as there are simply too many for their UI to cooperate. But the 100 or so I did manage to pull was all sent within a handful of milliseconds.
> When Asterisk received these, it's memory usage shots up significantly, and the log file started printing hundreds of these lines:
> WARNING[13337] channel.c: Exceptionally long queue length queuing to PJSIP/registrar-0000d96a
> The channel noted is the outgoing call to the user with the defective SIP Client.
> There was nothing else in the messages log file related to this at all.
> Asterisk CPU spiked (thought not to 100%), which is not a surprise as it does need to process all these SIP Replies, however the memory usage did not go down afterwards, even 12 hours after.
> Normally it'll sit around 5 mb or something, but after this it had allocated a good 6GB of ram and there was no sign it was about to give any of it up 12 hours later when I restarted it.
> I've got a PCAP file, though it contains sensitive information so I'd prefer not to share it publicly
> I've also moved this customer to a separate Asterisk instance running 16.11.1, and I can probably enable whatever other logging might be helpful on it, in case this client goes haywire again and takes out that instance.



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