unREGISTER not working on recent master (built Saturday evening) when usrloc db_mode = 3
This un-REGISTER:
REGISTER sip:...domain... SIP/2.0 Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 Max-Forwards: 16 To: sip:...user...@...domain... From: sip:...user...@...domain...;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Contact: sip:pufj2a59@18vku8fabcfq.invalid;transport=ws;reg-id=1;+sip.instance="urn:uuid:d098383b-5d6d-4816-9c6e-f1aa00b7cef5";expires=0 Supported: path, outbound, gruu Content-Length: 0 Path: sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob
Results in this 200 OK (with 0 bindings):
SIP/2.0 200 OK Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 To: sip:...user...@...domain...;tag=8ab1eb0246bb313f703b656487ebc696.9519 From: sip:...user...@...domain...;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Path: sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob Supported: outbound Require: outbound Content-Length: 0
But with usrloc db_mode set to 3 the corresponding record remains in the database.
When I set usrloc db_mode to 0 I can use "mi ul_dump" with kamcmd and see that the records are removed from the hash-table.
It looks like some recent change to the way usrloc interacts with the database has broken something.
Regards,
Peter
It looks like the unregister() using RUID might be broken in db_mode = 3 too.
Regards,
Peter
On 20/05/13 15:15, Peter Dunkley wrote:
This un-REGISTER:
REGISTER sip:...domain... SIP/2.0 Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 Max-Forwards: 16 To:<sip:...user...@...domain...> From:<sip:...user...@...domain...>;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Contact:<sip:pufj2a59@18vku8fabcfq.invalid;transport=ws>;reg-id=1;+sip.instance="<urn:uuid:d098383b-5d6d-4816-9c6e-f1aa00b7cef5>";expires=0 Supported: path, outbound, gruu Content-Length: 0 Path:<sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob>Results in this 200 OK (with 0 bindings):
SIP/2.0 200 OK Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 To:<sip:...user...@...domain...>;tag=8ab1eb0246bb313f703b656487ebc696.9519 From:<sip:...user...@...domain...>;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Path:<sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob> Supported: outbound Require: outbound Content-Length: 0But with usrloc db_mode set to 3 the corresponding record remains in the database.
When I set usrloc db_mode to 0 I can use "mi ul_dump" with kamcmd and see that the records are removed from the hash-table.
It looks like some recent change to the way usrloc interacts with the database has broken something.
Regards,
Peter
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
iirc, Juha did some commits recently related to this part, perhaps something got broken.
The version before commit 6c3853981a7574cd162117ef0d98dba205193d1b can be checked to see if goes fine.
There were some notes in those commits that somehow triggered a warning and I added on my list to review, but I had no time yet.
Cheers, Daniel
On 5/20/13 4:17 PM, Peter Dunkley wrote:
It looks like the unregister() using RUID might be broken in db_mode = 3 too.
Regards,
Peter
On 20/05/13 15:15, Peter Dunkley wrote:
This un-REGISTER:
REGISTER sip:...domain... SIP/2.0 Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 Max-Forwards: 16 To:<sip:...user...@...domain...> From:<sip:...user...@...domain...>;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Contact:<sip:pufj2a59@18vku8fabcfq.invalid;transport=ws>;reg-id=1;+sip.instance="<urn:uuid:d098383b-5d6d-4816-9c6e-f1aa00b7cef5>";expires=0 Supported: path, outbound, gruu Content-Length: 0 Path:<sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob>Results in this 200 OK (with 0 bindings):
SIP/2.0 200 OK Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 To:<sip:...user...@...domain...>;tag=8ab1eb0246bb313f703b656487ebc696.9519 From:<sip:...user...@...domain...>;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Path:<sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob> Supported: outbound Require: outbound Content-Length: 0But with usrloc db_mode set to 3 the corresponding record remains in the database.
When I set usrloc db_mode to 0 I can use "mi ul_dump" with kamcmd and see that the records are removed from the hash-table.
It looks like some recent change to the way usrloc interacts with the database has broken something.
Regards,
Peter
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi,
I don't have time to roll-back and check right now, but will hopefully do so later in the week.
Regards,
Peter
On 20/05/13 15:28, Daniel-Constantin Mierla wrote:
iirc, Juha did some commits recently related to this part, perhaps something got broken.
The version before commit 6c3853981a7574cd162117ef0d98dba205193d1b can be checked to see if goes fine.
There were some notes in those commits that somehow triggered a warning and I added on my list to review, but I had no time yet.
Cheers, Daniel
On 5/20/13 4:17 PM, Peter Dunkley wrote:
It looks like the unregister() using RUID might be broken in db_mode = 3 too.
Regards,
Peter
On 20/05/13 15:15, Peter Dunkley wrote:
This un-REGISTER:
REGISTERsip:...domain... SIP/2.0 Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 Max-Forwards: 16 To:<sip:...user...@...domain...> From:<sip:...user...@...domain...>;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Contact:<sip:pufj2a59@18vku8fabcfq.invalid;transport=ws>;reg-id=1;+sip.instance="<urn:uuid:d098383b-5d6d-4816-9c6e-f1aa00b7cef5>";expires=0 Supported: path, outbound, gruu Content-Length: 0 Path:<sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob>Results in this 200 OK (with 0 bindings):
SIP/2.0 200 OK Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 To:<sip:...user...@...domain...>;tag=8ab1eb0246bb313f703b656487ebc696.9519 From:<sip:...user...@...domain...>;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Path:<sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob> Supported: outbound Require: outbound Content-Length: 0But with usrloc db_mode set to 3 the corresponding record remains in the database.
When I set usrloc db_mode to 0 I can use "mi ul_dump" with kamcmd and see that the records are removed from the hash-table.
It looks like some recent change to the way usrloc interacts with the database has broken something.
Regards,
Peter
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 *http://asipto.com/u/katu *
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
On 5/20/13 4:34 PM, Peter Dunkley wrote:
Hi,
I don't have time to roll-back and check right now, but will hopefully do so later in the week.
I just said in case you an workaround for it quickly and also to point to Juha for a double-check.
Doesn't look I will have time for it in the next days as well.
Cheers, Daniel
Regards,
Peter
On 20/05/13 15:28, Daniel-Constantin Mierla wrote:
iirc, Juha did some commits recently related to this part, perhaps something got broken.
The version before commit 6c3853981a7574cd162117ef0d98dba205193d1b can be checked to see if goes fine.
There were some notes in those commits that somehow triggered a warning and I added on my list to review, but I had no time yet.
Cheers, Daniel
On 5/20/13 4:17 PM, Peter Dunkley wrote:
It looks like the unregister() using RUID might be broken in db_mode = 3 too.
Regards,
Peter
On 20/05/13 15:15, Peter Dunkley wrote:
This un-REGISTER:
REGISTERsip:...domain... SIP/2.0 Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 Max-Forwards: 16 To:<sip:...user...@...domain...> From:<sip:...user...@...domain...>;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Contact:<sip:pufj2a59@18vku8fabcfq.invalid;transport=ws>;reg-id=1;+sip.instance="<urn:uuid:d098383b-5d6d-4816-9c6e-f1aa00b7cef5>";expires=0 Supported: path, outbound, gruu Content-Length: 0 Path:<sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob>Results in this 200 OK (with 0 bindings):
SIP/2.0 200 OK Via: SIP/2.0/TCP 10.244.155.159:5080;branch=z9hG4bKc449.b2edda67c9b4a8c76a60a96e2855f29f.0 Via: SIP/2.0/WSS 18vku8fabcfq.invalid;rport=50434;received=90.152.0.102;branch=z9hG4bK5064405 To:<sip:...user...@...domain...>;tag=8ab1eb0246bb313f703b656487ebc696.9519 From:<sip:...user...@...domain...>;tag=ksmq223j0u Call-ID: pv465kef31j1l3qagh2bu7 CSeq: 84 REGISTER Path:<sip:7n4oJa+O7yfY4QYK9JufAbtamABmxQI=@10.244.155.159:5080;transport=tcp;lr;ob> Supported: outbound Require: outbound Content-Length: 0But with usrloc db_mode set to 3 the corresponding record remains in the database.
When I set usrloc db_mode to 0 I can use "mi ul_dump" with kamcmd and see that the records are removed from the hash-table.
It looks like some recent change to the way usrloc interacts with the database has broken something.
Regards,
Peter
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013 *http://asipto.com/u/katu *
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Daniel-Constantin Mierla writes:
iirc, Juha did some commits recently related to this part, perhaps something got broken.
i just checked and my commit only dealt with location attributes, not location itself. i have
modparam("usrloc", "db_mode", 3) modparam("usrloc", "db_ops_ruid", 1) modparam("usrloc", "db_check_update", 1)
i have not set xavp_contact param.
-- juha
Hello,
you did several, iirc, one was something related to unregister without aor -- the one that i thought needs to be doublechecked. Here I listed the first you started with.
Cheers, Daniel
On 5/20/13 6:04 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
iirc, Juha did some commits recently related to this part, perhaps something got broken.
i just checked and my commit only dealt with location attributes, not location itself. i have
modparam("usrloc", "db_mode", 3) modparam("usrloc", "db_ops_ruid", 1) modparam("usrloc", "db_check_update", 1)
i have not set xavp_contact param.
-- juha
Daniel-Constantin Mierla writes:
you did several, iirc, one was something related to unregister without aor -- the one that i thought needs to be doublechecked. Here I listed the first you started with.
ok, looks like unregister does not remove the record from db if db_ops_ruid is NOT set. i'll try to investigate.
by the way, is there some good reason not to set db_ops_ruid?
-- juha
Peter Dunkley writes:
It looks like the unregister() using RUID might be broken in db_mode = 3.
i just tried with two different UAs and with latest master and unregister worked fine in db_mode=3, i.e., the contact disappeared from location table. i wonder how to reproduce the problem?
-- juha
That does make it work.
I think that the code needs to make sure that option is set implicitly when db_mode=3 if it won't work without it any more.
Regards,
Peter
On 20/05/13 18:27, Juha Heinanen wrote:
Peter Dunkley writes:
It looks like the unregister() using RUID might be broken in db_mode = 3
peter,
can you try with
modparam("usrloc", "db_ops_ruid", 1)
or is there some reason that prevents you setting "db_ops_ruid?
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 5/20/13 8:07 PM, Juha Heinanen wrote:
Peter Dunkley writes:
I think that the code needs to make sure that option is set implicitly when db_mode=3 if it won't work without it any more.
i got the bug fixed, but it might still make sense to remove db_ops_ruid param and set it automatically to 1 if db_mode=3.
the parameter is used also for the other db modes, not only for db only.
However, it can be made default 1 and set to 0 if needed/wanted in config - if it is 1, is also more efficient for db operations, but i set it to 0 in order to be able to backport as it fixes call-id changes in subsequent registrations.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Juha Heinanen -
Peter Dunkley