[SR-Users] Dropped registrar bindings with 1.5.3

Alex Balashov abalashov at evaristesys.com
Fri Nov 18 21:27:06 CET 2011


On 11/18/2011 03:16 PM, Andres wrote:

> My logic tells me:
> 1) If its not hitting your xlog in your register section then its not
> registering to this server

The registrar is running inside an OpenVZ container, so the first 
possibility I investigated was that someone had inadvertently cloned 
the container on the same hardware node and that there was an IP 
address conflict.  However, this turned out not to be the case.  I 
also double-checked the MAC addresses on the registrations within the 
successful interval vs. outside of it.

> 2) If your packet capture is showing a successful registration and
> you cannot see it registered in this server then its registering
> somewhere else.

That stands to reason, but I cannot find any evidence apart to support 
that viewpoint, nor anything about the packet capture (e.g. different 
hardware or instance signatures) that would seem to corroborate that.

> 3) Is it possible that your server is simply re-routing the packet
> to another server before it hits your xlog statement and thus the
> client is registering there?

I entertained that possibility, but can't find any indication of how 
this would be possible, particularly in an arbitrary, small number of 
cases for very brief periods.

> A full packet capture in and out of the server might give you a
> hint, but if you have thousands of customers that might be tough.

I took a packet capture at the edge router of the network as well as 
on the hardware node itself, in addition to the container.  All of 
them tell the same story.

> On the other hand, if you have thousands of customers, I would
> venture to guess that you have more than one server where users can
> register and that might explain why the trace shows a successful
> registration.

There is just one registrar -- the one under discussion.  It's the 
main reason Kamailio is used here;  it is the only OSS registrar I 
know of that has enough throughput capacity to sustain thousands of 
devices banging on it with relatively short re-registration intervals.

-- 
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/



More information about the sr-users mailing list