[OpenSIPS-Users] opensips version 2.2 -Cache and location table out of sync for particular registrations.
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Oct 17 04:11:20 EDT 2017
Hi Jonathan,
If you see the state transition from DIRTY to SYNC, it means the INSERT
/ UPDATE into DB was successful from the OpenSIPS perspective.
What you can do :
1) ngrep to traffic between OpenSIPS and DB server to see if the query
is actually pushed
2) run "opensipsctl fifo ul_sync" to force re-writing the whole DB
content based on mem cache:
http://www.opensips.org/html/docs/modules/2.3.x/usrloc.html#idp5721824
Sometimes, if for whatever reasons the original INSERT was lost at
DB level, any sequential UPDATE(s), even if successful, will have no
effect on the DB content.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 10/16/2017 08:27 PM, Jonathan Hunter wrote:
> Hi Guys,
>
> I have an interesting issue and wondered if anyone else has seen this
> issue.
>
> We have a user who is registered with the platform and can make and
> receive calls, however the registration is only ever in the cache, it
> is not being populated in the location table.
>
> When I check its state I can see it registered, and I see its state go
> from CS_DIRTY, to CS_SYNC as it re-registers;
>
> opensipsctl ul show 02033279460 at sip.provider
> AOR:: 02033279460
> Contact:: sip:02033279460 at WANIP:5060 Q=
> Expires:: 266
> Callid:: 5820966e249dce1b6796222708c8d94b at sip.provider
> Cseq:: 11070
> User-agent:: Asterisk PBX
> State:: CS_DIRTY
> Flags:: 0
> Cflags::
> Socket:: udp:91.X.X.X:5060
> Methods:: 4294967295
>
> opensipsctl ul show 02033279460 at sip.provider
> AOR:: 02033279460
> Contact:: sip:02033279460 at WANIP:5060 Q=
> Expires:: 224
> Callid:: 5820966e249dce1b6796222708c8d94b at sip.provider
> Cseq:: 11070
> User-agent:: Asterisk PBX
> State:: CS_SYNC
> Flags:: 0
> Cflags::
> Socket:: udp:91.X.X.X:5060
> Methods:: 4294967295
>
>
> However it isn't contained within the location table, even though
> other registrations are contained in both, as we have the following set;
>
> modparam("usrloc", "db_url", "DBURL")
> modparam("usrloc", "db_mode", 2)
> modparam("usrloc", "timer_interval", 60)
>
> I have tried to reproduce the issue but cant seem to, the REGISTER
> message being sent looks like the below;
>
>
>
> Request-Line: REGISTER sip:sip.provider SIP/2.0
> Message Header
> Via: SIP/2.0/UDP 91.X.X.X:5060;branch=z9hG4bK-25033-1-3
> Max-Forwards: 70
> From: <sip:02033279460 at sip.provider>;tag=1
> To: <sip:02033279460 at sip.provider>
> Call-ID: 1-25033 at 91.X.X.X
> CSeq: 8 REGISTER
> Supported: replaces, timer
> User-Agent: Asterisk PBX
> Authorization: Digest
> username="02033279460",realm="sip.provider",uri="sip:91.X.X.X:5060",nonce="59e4d0ae000000019388ae5161ff1f5d2666a1d2adb6e77d",response="e2f9ffb2ccf33c864adb76c950c2221c",algorithm=MD5
> Expires: 120
> Contact: sip:02033279460 at 91.X.X.X:5060
> Content-Length: 0
>
> Note its send the Auth header in initial REGISTER before the 401
> challenge.
>
> Does anyone have any tips please on where the issue might be or how
> best to trouble-shoot on a busy live platform?
>
> Many thanks!
>
> Jon
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20171017/c35c5d93/attachment.html>
More information about the Users
mailing list