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