[SR-Users] Dropped registrar bindings with 1.5.3

[Andres]

On 11/17/2011 10:28 PM, Alex Balashov wrote:
> I have a 1.5.3 installation functioning as a registrar that is 
> exhibiting a very curious, if only infrequent set of behaviours.
> The host is CentOS 5.x, with PostgreSQL 9.0 backing usrloc, and 
> db_mode = 1 (immediate write-through).
>
> I have a registration handler in my initial request route that begins 
> with a log message:
>
>    ...
>
>    else if(is_method("REGISTER")) {
>            xlog("L_INFO", "... Processing REGISTER from $si:$sp for 
> AOR $tu\n");
>            route(2);
>            exit;
>    }
>
> I've got a registrant who consistently re-registers with an expiration 
> time of 120, so in theory they ought to be re-registering every two 
> minutes or so.  Most of the time they do.  But, occasionally, I'll see 
> a gap of 5-8 minutes go by, in which the above log message does not 
> appear, and their registration expires so that they can't receive calls.
>
> That's not what's interesting.  What's interesting is that I did a 
> packet capture on the proxy and caught one of these scenarios.  Within 
> that ~8 minute window when the registration expired and calls were 
> failing, the UAC actually re-registered several times, on normal ~2 
> minute boundaries, AND the proxy successfully challenged the request 
> and sent a 200 OK indicating that the binding was stored!
>
> I double-checked all the parameters to ensure that the 401s and 200 
> OKs corresponded to the right REGISTER flow, etc. - yes, it's all 
> correct.
>
> Is there any imaginable set of circumstances or a known bug that would 
> cause Kamailio to successfully authenticate and affirm a registration 
> request, while neither logging its receipt, nor, evidently, storing it 
> to the database?  I can envision a number of database failure modes 
> that would account for the binding not actually being in the 
> 'location' table, but that doesn't explain why the request wouldn't 
> even be logged.  That's what has me baffled.
>
My logic tells me:
1)  If its not hitting your xlog in your register section then its not 
registering to this server
2)  If your packet capture is showing a successful registration and you 
cannot see it registered in this server then its registering somewhere else.
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?  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.   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.
>
>
Cheers.

-- 
Technical Support
http://www.telesip.net