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.