unREGISTER not working on recent master (built Saturday evening) when usrloc db_mode = 3

List overview All Threads
Download

newer

older

ACK sometimes routed incorrectly...

git:master: modules/usrloc: fixed...

Peter Dunkley

20 May 2013 20 May '13

10:15 a.m.

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

Attachments:

attachment.html (text/html — 2.6 KB)

Show replies by date

Peter Dunkley

20 May 20 May

10:17 a.m.

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: 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 _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Daniel-Constantin Mierla

10:28 a.m.

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: 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 _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

_______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Peter Dunkley

10:34 a.m.

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:

...

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: 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 _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

_______________________________________________ sr-dev mailing list sr-dev(a)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(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Daniel-Constantin Mierla

10:58 a.m.

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:

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: 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 _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

_______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Juha Heinanen

12:04 p.m.

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

12:11 p.m.

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.

Juha Heinanen

12:31 p.m.

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

Juha Heinanen

11:48 a.m.

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

Juha Heinanen

1:27 p.m.

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

Peter Dunkley

1:36 p.m.

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(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Juha Heinanen

2:07 p.m.

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. -- juha

Daniel-Constantin Mierla

2:28 p.m.

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 - 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 *

4238

days inactive

4238

days old

sr-dev@lists.kamailio.org

Manage subscription

12 comments

3 participants

tags (0)

participants (3)

Daniel-Constantin Mierla
Juha Heinanen
Peter Dunkley