<div dir="ltr"><div dir="ltr"><div>Thanks for implementing the fix! We've updated our Python SIPSimple
 version to v3.4.1 and the SylkServer to v5.2.0. Looks like the problem 
with the growing number of ports is now gone - we haven't seen the 
PJ_ETOOMANY exception for more than a month now. </div><div><br></div><div>However,
 recently we saw the logging error that we mentioned in the previous 
emails. Looks like this might be an independent problem. Our logs show 
the following two lines:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace">Traceback (most recent call last):<br></font><font face="monospace, monospace">File "/usr/lib/python2.7/logging/__init__.py", line 861, in emit</font></blockquote><div><br></div><div>The traceback ends there. After this happens, SylkServer stops responding to session create requests until we restart it.</div><div><br></div><div>I
 understand the error is not very helpful and this might even be an 
issue with the Python logging library or something related, but I 
thought it makes sense to ask you anyway in case you might have some 
advice.</div><div><br></div><div>Our operating system info is as follows:</div><div><br></div><div>Debian GNU/Linux 9.6 (stretch)</div><div>Kernel: Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27)</div><div><br></div><div>The Python version is 2.7.13.</div><div><br></div><div>Please let me know if you have any clue as to what might be the problem. </div><div><br></div><div>Thanks for your time!</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 19, 2019 at 7:52 PM Dan Pascu <<a href="mailto:dan@ag-projects.com">dan@ag-projects.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It turns out that the fix was completely different that what was proposed in the patch and it had to be applied in python-sipsimple. The whole issue originated with a memory leak in sipsimple that happened with streams that were created but ended up not being used (like a canceled or refused call).<br>
<br>
To fix your issue you'll need to get and build the latest version of python-sipsimple (either from darcs or github). While you're at it, you can also grab the latest version of sylkserver from the same sources, as it contains a few additional fixes, including a smaller memory leak that affects canceling mid-session proposals (re-invites).<br>
<br>
Let me know if it fixes your problems. If nothing else shows up, I'll make new releases for both.<br>
<br>
On 14 Feb 2019, at 14:56, Dan Pascu wrote:<br>
<br>
> Thanks for the patch. I'll check it and integrate it.<br>
> <br>
> On 13 Feb 2019, at 16:55, Penelope Vennisse wrote:<br>
> <br>
>> We've continued analysing the issue with the growing number of mixer ports and here's what we've learned.<br>
>> <br>
>> 1. We've been having multiple incoming SIP connections from unknown (probably, attacker) SIP servers as our SylkServer instance was not protected by a firewall. These connections were initiated and then failed after a second or so.<br>
>> <br>
>> 2. We tried using the 'trusted_peers' setting in the SylkServer config.ini to only allow connections from our own servers. According to our logs, there is still a new audio stream created for each incoming SIP connection from the  addresses, not listed in 'trusted_peers'. These streams don't seem to be destroyed properly since, for each such stream, 2 ports are allocated in the audio mixer and they're never removed.<br>
>> <br>
>> So enabling the 'trusted_peers' option in our case only lead to a steadily growing number of used audio ports, which, as we understand, would eventually lead to the PJ_ETOOMANY exception from our previous email.<br>
>> <br>
>> We ended up setting firewall rules on the machine so that unwanted SIP connections never reach SylkServer.<br>
>> <br>
>> 3. We also discovered that whenever an incoming SIP connection is canceled, it creates 2 extra ports in the audio mixer as well that stay until the SylkServer restart.<br>
>> <br>
>> I'm attaching a patch that seems to have addressed (2) and (3) for us. We're not sure though that this would cover all the cases when audio streams are not terminated properly. Let me know if it looks correct to you.<br>
>> <br>
>> Also, we have no new info on the python logging exception from the previous email, so there might still be another independent problem leading to similar consequences.<br>
>> <br>
>> Please let me know what you think.<br>
>> <br>
>> <br>
>> On Wed, Jan 30, 2019 at 4:18 PM Penelope Vennisse <<a href="mailto:studio.pqv9@gmail.com" target="_blank">studio.pqv9@gmail.com</a>> wrote:<br>
>> We're using SylkServer as an audio conference server for webRTC and SIP clients. Only the Conference and the WebRTC Gateway applications are enabled in the config. Our SylkServer version is 5.0.0, checked out from this GitHub tag.<br>
>> <br>
>> Once in several days, we observe the following problem: the CPU usage by the SylkServer process starts to grow and all the webRTC client connection attempts fail. After some time (usually a few hours), the following exception appears in the logs:<br>
>> <br>
>> ERROR    [sylk.core]     Exception occurred while setting up stream from SDP: Could not add audio object to audio mixer: Too many objects of the specified type (PJ_ETOOMANY)<br>
>> ERROR    [sylk.core]     Traceback (most recent call last):<br>
>> ERROR    [sylk.core]       File "/srv/sylkserver/sylk/session.py", line 394, in init_incoming<br>
>> ERROR    [sylk.core]         stream = stream_type.new_from_sdp(self, remote_sdp, index)<br>
>> ERROR    [sylk.core]       File "/usr/lib/python2.7/dist-packages/sipsimple/streams/rtp/__init__.py", line 425, in new_from_sdp<br>
>> ERROR    [sylk.core]         stream = cls()<br>
>> ERROR    [sylk.core]       File "/usr/lib/python2.7/dist-packages/sipsimple/streams/rtp/audio.py", line 24, in __init__<br>
>> ERROR    [sylk.core]         self.bridge = AudioBridge(self.mixer)<br>
>> ERROR    [sylk.core]       File "/usr/lib/python2.7/dist-packages/sipsimple/audio.py", line 129, in __init__<br>
>> ERROR    [sylk.core]         self.multiplexer.start()<br>
>> ERROR    [sylk.core]       File "sipsimple/core/_core.sound.pxi", line 1310, in sipsimple.core._core.MixerPort.start (sipsimple/core/_core.c:38212)<br>
>> ERROR    [sylk.core]       File "sipsimple/core/_core.sound.pxi", line 1307, in sipsimple.core._core.MixerPort.start (sipsimple/core/_core.c:38143)<br>
>> ERROR    [sylk.core]       File "sipsimple/core/_core.sound.pxi", line 471, in sipsimple.core._core.AudioMixer._add_port (sipsimple/core/_core.c:24844)<br>
>> <br>
>> We've added some logs to the SylkServer and the Python SipSimple library to clear things up a bit. What we discovered is that during the period when the connection attempts fail, the number of used audio mixer ports (we were logging the conf->port_cnt counter in pjsip/pjmedia/src/pjmedia/conference.c) grows steadily and reaches the limit (9999) in the end. Right before this period starts there are these two lines in the logs:<br>
>> <br>
>> Traceback (most recent call last):<br>
>> File "/usr/lib/python2.7/logging/__init__.py", line 861, in emit<br>
>> <br>
>> This looks like a cropped exception message, but there is nothing more. It might be that some log message is ill-formatted but we're not sure where to look for it.<br>
>> <br>
>> Please let us know if this is a known issue or if you have any advice on how we could track it down.<br>
>> <br>
>> Thanks.<br>
>> <session.patch>_______________________________________________<br>
>> SIPBeyondVoIP mailing list<br>
>> <a href="mailto:SIPBeyondVoIP@lists.ag-projects.com" target="_blank">SIPBeyondVoIP@lists.ag-projects.com</a><br>
>> <a href="http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip" rel="noreferrer" target="_blank">http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip</a><br>
> <br>
> <br>
> --<br>
> Dan<br>
> <br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> SIPBeyondVoIP mailing list<br>
> <a href="mailto:SIPBeyondVoIP@lists.ag-projects.com" target="_blank">SIPBeyondVoIP@lists.ag-projects.com</a><br>
> <a href="http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip" rel="noreferrer" target="_blank">http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip</a><br>
> <br>
<br>
<br>
--<br>
Dan<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
SIPBeyondVoIP mailing list<br>
<a href="mailto:SIPBeyondVoIP@lists.ag-projects.com" target="_blank">SIPBeyondVoIP@lists.ag-projects.com</a><br>
<a href="http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip" rel="noreferrer" target="_blank">http://lists.ag-projects.com/mailman/listinfo/sipbeyondvoip</a><br>
</blockquote></div>