[sip-comm-dev] Possible Memory Leak and Call-ID Header of SIP REGISTER keep-alives


I'm approaching the problem from the fact that SipSecurityManager is
piling up Authorization headers in CredentialsCache using Call-ID as
the keys. Since nothing removes these associations from the
CredentialsCache, the memory retained by them is never reclaimed. I
wonder why these associations are created and never broken but, since
I'm still not ready to answer that question and reclaim the retained
memory, I'm trying to look at it from a different angle.

When SipRegistrarConnection uses REGISTER as a form of keep-alives, it
will invoke its #register() every now and then - quite often in the
default SIP account setup as it's 25 sec. Unfortunately, #register()
creates a new Call-ID header each time it's invoked and thus it causes
a new association to be added to CredentialsCache with a relatively
fast pace. In my case with no actual calls and just staying connected,
it managed to drive what started as an innocent amount of bytes to
explode to approximately 1 MB in 3 hours.

Now, I would obviously not solve the possible memory leak caused by
the associations kept by CredentialsCache but I may as well make it
progress with a slower pace if there aren't that many new Call-IDs
created. Which brings me to RFC 3261 and it saying about REGISTER and
Call-ID that "All registrations from a UAC SHOULD use the same Call-ID
header field value for registrations sent to a particular registrar."
X-Lite seems to comply with the SHOULD and uses the same Call-ID when
it re-registers. Why doesn't SIP Communicator do that?

Help on any of the two subjects will be appreciated.

Thank you,


To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net