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

[Jonas Swiatek (JIRA)]

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

Jonas Swiatek commented on ASTERISK-28962:
------------------------------------------

A quick thought:

The PCAP is incomplete, likely because homer simply wasn't designed to shove that much data into one. One thing that I could've happened, since the user had like 4 or 5 devices registered at the time is that one of the other devices answered the call. When that happened, Kamailio would've sent out a CANCEL to the other devices, but the defective SIP device would've kept just spamming 180 Ringing like it was the end of the world. Perhaps Asterisk receiving a metric f...ton of those to a call that has already been answered would be provoking it?

> 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: Unassigned
>
> 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)