[SR-Users] RTP Proxy

Richard Fuchs rfuchs at sipwise.com
Tue Jul 31 15:08:02 CEST 2018


On 2018-07-31 06:54, Alex Tatham wrote:
>
> Hello everyone,
>
> I’m in the process of moving approx. 100 Kamailio/Media Proxy (AG 
> Projects) servers to Kamailio/RTPEngine.  I have all the functionality 
> in place and I have a handful of servers in production.  I’m trying to 
> monitor the RTP engine (using Munin) and I’m graphing the values 
> returned from the RPC command rtpengine.get_hash_total.  This value is 
> slowly increasing over time and I’m trying to find out if this is 
> something I should worry about.  I want to make sure that sessions are 
> not being left open and therefore the software will eventually run out 
> of ports.  To give some values, if I make 100 calls the call will be 
> around 25 after those calls.
>
> From all other tests I have done including a check through the verbose 
> logs I can see the sessions are being closed at the end of the calls.
>
> Can anyone help with this at all or does anyone possibly have any 
> better ideas?
>

The size of the hash table does not necessarily directly correlate with 
the sessions rtpengine itself has open. Normally it should, but it's 
possible for rtpengine to close a session with the entry remaining in 
the hash table, or vice versa.

To get a better idea of how many sessions rtpengine actually has open, 
check out it's CLI interface or the related control script (rtpengine-ctl).

As for the hash table itself, AFAICS entries are deleted when the 
_delete method is used. Otherwise they stay in memory until the timeout 
is reached, defaulting to 1 hour. (They're only actually deleted after 
the timeout if encountered while processing the hash table at some 
point.) If you don't see the hash table decrease in size, it's probably 
not calling the _delete method properly.

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180731/ce40ca91/attachment.html>


More information about the sr-users mailing list