[SR-Users] Possible memory leak dealing with presence in kamailio

[Nuno Reis]

Hi Juha and all.

I understand that and that is what the RFC says. It seems pua module does
that right. Although something is clearly not right in my production
environment because kamailio memory consumption still grows pretty fast.
Kamailio memory usage starts in ~500MB and after ~24H kamailio is using
~3GB. If I disable kamailio from listening on the localhost(127.0.0.1)
where pua is generating the SIP Publishes kamailio just keeps around the
~500MB all the time.
This is a small production environment with 70 extensions with Yealink
phones.
Any ideas on how to chase down this memory leak? Should I open a git issue
for this one?



--

*Nuno Miguel Reis* | *Unified Communication** Systems*
M. +351 913907481 | nreis at wavecom.pt
WAVECOM-Soluções Rádio, S.A.
Cacia Park | Rua do Progresso, Lote 15
3800-639 AVEIRO | Portugal
T. +351 309 700 225 | F. +351 234 919 191
*GPS
<http://maps.google.com/maps/ms?msa=0&msid=202333747613191340808.0004b4b227a6144f0df88>
| www.wavecom.pt <http://www.wavecom.pt/>** <http://www.wavecom.pt/>*

[image: Description: Description: WavecomSignature]
<http://www.wavecom.pt/pt/wavecom/premios.php>

[image: Publicity] <http://www.wavecom.pt/pt/mail_eventos.php>



On Wed, Jan 21, 2015 at 8:45 PM, Juha Heinanen <jh at tutpro.com> wrote:

> Nuno Reis writes:
>
> > Here my publisher is Kamailio itself. Can someone elaborate a bit more on
> > this issue and maybe we can get to bottom of it?
>
> when your application issues initial publish request, it does so without
> SIP-If-Match header.  200 ok from presence server then contains an etag
> in SIP-ETag header. when your application refreshes the publish, it must
> place this etag in SIP-If-Match header to prevent presence server from
> creating a new publication.
>
> for subscribes, your application must place in re-subscribe the
> same event header id param as the previous one had in order for the
> presence server to know that subscribe was not a new subscription.
>
> -- juha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150130/fe673293/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16423 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150130/fe673293/attachment.png>