Re: [OpenSIPS-Users] Dialog replication problems

[Adrien Martin]

Hello,

I backported the commit 00be97f151d254af281c4f05611c1905f51fbcde ("dialog: Fix 
incorrect replicated dialog ids") from git in an Opensips 2.2.2.

opensipsctl fifo dlg_list show the same dialogs on both sides, but after 
fail-over the BYE is not routed (no problem if no fail-over).

My setup use topology_hiding (with dialog), topology_hiding_match returns false.


Debug logs show the dialog is found (eg: DBG:dialog:lookup_dlg: dialog 
id=1590931783 found on entry 2370).

There is difference in logs between a normal call and a fail-over call :

  DBG:dialog:run_dlg_callbacks: dialog=0x7f19bfd60f20, type=32
  DBG:dialog:fix_route_dialog: Fixing message. Next hop is Loose router
  DBG:dialog:fix_route_dialog: Setting new URI to ...

Wich are not present when using a replicated dialog.

"ref dlg" and "unref dlg" logs do not have the same ref in both case (don't 
know if relevant).


The request URI of the BYE has the Opensips in the host part, so the BYE is 
routed locally because the request URI is not rewritten.
Opensips search again the same dialog but does not find it at this moment.

Regards,
-- 
Adrien Martin

On 03/11/2016 11:27, Liviu Chircu wrote:
> Hi, Dawid!
> 
> I have looked into the problem and also managed to come up with a fix! Could 
> you please go to your OpenSIPS 2.2 source code directory, apply the below 
> patch, recompile the dialog module and see if it fixes the problem?
> 
> git apply <(base64 -d < ZGlmZiAtLWdpdCBhL21vZHVsZXMvZGlhbG9nL2RsZ19yZXBsaWNhdGlvbi5jIGIvbW9kdWxlcy9k
> aWFsb2cvZGxnX3JlcGxpY2F0aW9uLmMKaW5kZXggYTg0NTVhZi4uZGE2MmRiNiAxMDA2NDQKLS0t
> IGEvbW9kdWxlcy9kaWFsb2cvZGxnX3JlcGxpY2F0aW9uLmMKKysrIGIvbW9kdWxlcy9kaWFsb2cv
> ZGxnX3JlcGxpY2F0aW9uLmMKQEAgLTE4Miw3ICsxODIsNiBAQCBpbnQgZGxnX3JlcGxpY2F0ZWRf
> Y3JlYXRlKHN0cnVjdCBkbGdfY2VsbCAqY2VsbCwgc3RyICpmdGFnLCBzdHIgKnR0YWcsIGludCBz
> YWZlKQogCWRsZy0+bGVnc19ub1tETEdfTEVHXzIwME9LXSA9IERMR19GSVJTVF9DQUxMRUVfTEVH
> OwogCiAJLyogbGluayB0aGUgZGlhbG9nIGludG8gdGhlIGhhc2ggKi8KLQlkbGctPmhfaWQgPSBk
> X2VudHJ5LT5uZXh0X2lkKys7CiAJaWYgKCFkX2VudHJ5LT5maXJzdCkKIAkJZF9lbnRyeS0+Zmly
> c3QgPSBkX2VudHJ5LT5sYXN0ID0gZGxnOwogCWVsc2Ugewo=
> EOF
> )
> 
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com



signature.asc
Description: OpenPGP digital signature
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Dialog replication problems

[Liviu Chircu]

Thanks for the quick test! Will have it pushed upstream today.

Transparent CDR generation for the replicated dialogs is currently not 
working. For that to work, the two nodes would need to _accurately_ 
share state (i.e. "who is the primary?"), otherwise double CDR/billing 
situations could occur.


Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 03.11.2016 13:02, Dawid Mielnik wrote:

Hi Liviu,

Yes - big difference with the patch :

Also, should CDR be generated on the standby server after the 
switch-over ? I am still not getting those (have to keep my own 
variables in dialog and insert in db manually). I am using topology 
hiding module if that makes any difference (manual CDR generation is 
triggered when ( $DLG_status!=NULL && !validate_dialog() ) condition 
fails after which I call fix_route_dialog())..


BR,
Dawd



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Dialog replication problems

[Dawid Mielnik]

Hi Liviu,

Yes - big difference with the patch :

active server:

dialog::  hash=3426:1456403041 dialog_id=14716014359137
state:: 4
user_flags:: 0
timestart:: 1478170024
datestart:: 2016-11-03 11:47:04
timeout:: 1478191625
dateout:: 2016-11-03 17:47:05
callid:: 81140NWQxYTg1ZWRkZDNiYzE2OGExYzI1NmE1N2Y4MjM2MTE
...

standby server:

dialog::  hash=3426:1456403041 dialog_id=14716014359137
state:: 4
user_flags:: 0
timestart:: 1478170024
datestart:: 2016-11-03 11:47:04
timeout:: 1478191625
dateout:: 2016-11-03 17:47:05
callid:: 81140NWQxYTg1ZWRkZDNiYzE2OGExYzI1NmE1N2Y4MjM2MTE
...

BYE after switch-over:

Nov  3 11:48:55.964155 DEB 29249  DBG:core:parse_msg: SIP Request:
Nov  3 11:48:55.964185 DEB 29249  DBG:core:parse_msg:  method:  
Nov  3 11:48:55.964191 DEB 29249  DBG:core:parse_msg:  uri: 
Nov  3 11:48:55.964197 DEB 29249  DBG:core:parse_msg:  version: 
...
Nov  3 11:48:55.964395 DEB 29249  DBG:dialog:w_match_dialog: We found DID
param in R-URI with value of 26d.162fec65
Nov  3 11:48:55.964399 DEB 29249  DBG:dialog:dlg_onroute: route param is
'26d.162fec65' (len=12)
Nov  3 11:48:55.964437 DEB 29249  DBG:dialog:lookup_dlg: ref dlg
0x7f70c12a7b30 with 1 -> 3
Nov  3 11:48:55.964451 DEB 29249  DBG:dialog:lookup_dlg: dialog
id=1456403041 found on entry 3426
...

Thank you.

Also, should CDR be generated on the standby server after the switch-over ?
I am still not getting those (have to keep my own variables in dialog and
insert in db manually). I am using topology hiding module if that makes any
difference (manual CDR generation is triggered when ( $DLG_status!=NULL &&
!validate_dialog() ) condition fails after which I
call fix_route_dialog())..

BR,
Dawd

On Thu, Nov 3, 2016 at 11:27 AM, Liviu Chircu  wrote:

> Hi, Dawid!
>
> I have looked into the problem and also managed to come up with a fix!
> Could you please go to your OpenSIPS 2.2 source code directory, apply the
> below patch, recompile the dialog module and see if it fixes the problem?
>
> git apply <(base64 -d < ZGlmZiAtLWdpdCBhL21vZHVsZXMvZGlhbG9nL2RsZ19yZXBsaWNhdGlvbi5j
> IGIvbW9kdWxlcy9k
> aWFsb2cvZGxnX3JlcGxpY2F0aW9uLmMKaW5kZXggYTg0NTVhZi4uZGE2MmRi
> NiAxMDA2NDQKLS0t
> IGEvbW9kdWxlcy9kaWFsb2cvZGxnX3JlcGxpY2F0aW9uLmMKKysrIGIvbW9k
> dWxlcy9kaWFsb2cv
> ZGxnX3JlcGxpY2F0aW9uLmMKQEAgLTE4Miw3ICsxODIsNiBAQCBpbnQgZGxn
> X3JlcGxpY2F0ZWRf
> Y3JlYXRlKHN0cnVjdCBkbGdfY2VsbCAqY2VsbCwgc3RyICpmdGFnLCBzdHIg
> KnR0YWcsIGludCBz
> YWZlKQogCWRsZy0+bGVnc19ub1tETEdfTEVHXzIwME9LXS
> A9IERMR19GSVJTVF9DQUxMRUVfTEVH
> OwogCiAJLyogbGluayB0aGUgZGlhbG9nIGludG8gdGhlIGhhc2ggKi8KLQlk
> bGctPmhfaWQgPSBk
> X2VudHJ5LT5uZXh0X2lkKys7CiAJaWYgKCFkX2VudHJ5LT5maXJzdCkKIAkJ
> ZF9lbnRyeS0+Zmly
> c3QgPSBkX2VudHJ5LT5sYXN0ID0gZGxnOwogCWVsc2Ugewo=
> EOF
> )
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 03.11.2016 11:09, Dawid Mielnik wrote:
>
> Anyone ?
>
> I have just upgraded to the latest 2.2 version form GIT and am still
> experiencing this.
>
> active server:
>
> dialog::  hash=*2297:947327686* dialog_id=9866487206598
> state:: 4
> user_flags:: 0
> timestart:: 1478162278
> datestart:: 2016-11-03 09:37:58
> timeout:: 1478183878
> dateout:: 2016-11-03 15:37:58
> callid:: 81140ODk1MmU1MGM3MzZkZjMyYjIzY2I1ZDExZTI4ZDFiNjY
> from_uri:: sip:+48226522...@xxx.xxx.xxx.250
> to_uri:: sip:+48501657...@xxx.xxx.xxx.250
> caller_tag:: 86343576
> caller_contact:: sip:+48226522...@zzz.zzz.zzz.34:60603;rinstance=
> eab8d8723e64bbad
> callee_cseq:: 0
> caller_route_set::
> caller_bind_addr:: udp:XXX.XXX.XXX.250:5061
> caller_sdp::
> CALLEES::
> callee::
> callee_tag:: 192571
> callee_contact:: sip:YYY.YYY.YYY.20:5060;transport=UDP
> caller_cseq:: 1
> callee_route_set::
> callee_bind_addr:: udp:XXX.XXX.XXX.250:5060
> callee_sdp::
> ...
>
> standby server:
>
> dialog::  hash=*2297:1952115624* dialog_id=9867491994536
> state:: 4
> user_flags:: 0
> timestart:: 1478162278
> datestart:: 2016-11-03 09:37:58
> timeout:: 1478183877
> dateout:: 2016-11-03 15:37:57
> callid:: 81140ODk1MmU1MGM3MzZkZjMyYjIzY2I1ZDExZTI4ZDFiNjY
> from_uri:: sip:+48226522...@xxx.xxx.xxx.250
> to_uri:: sip:+48501657...@xxx.xxx.xxx.250
> caller_tag:: 86343576
> caller_contact:: sip:+48226522...@zzz.zzz.zzz.34:60603;rinstance=
> eab8d8723e64bbad
> callee_cseq:: 0
> caller_route_set::
> caller_bind_addr:: udp:XXX.XXX.XXX.250:5061
> caller_sdp::
> CALLEES::
> callee::
> callee_tag:: 192571
> callee_contact:: sip:YYY.YYY.YYY.20:5060;transport=UDP
> caller_cseq:: 1
> callee_route_set::
> callee_bind_addr:: udp:XXX.XXX.XXX.250:5060
> callee_sdp::
> ...
>
> After switch-over BYE is received on the standby server:
>
> Nov  3 09:44:38.571442 DEB 10180  DBG:core:parse_msg: SIP Request:
> Nov  3 09:44:38.571471 DEB 10180  DBG:core:parse_msg:  method:  
> Nov  3 09:44:38.571475 DEB 10180  DBG:core:parse_msg:  uri:
> 
> Nov  3 09:44:38.571479 DEB 10180  DBG:core:parse_msg:  version: 
> ...
> Nov  3 09:44:38.571809 DEB 10180  DBG:dialog:w_match_dialog: We found DID
> param in R-URI with value of 9f8.6c217783
> Nov  3 09:4

Re: [OpenSIPS-Users] Dialog replication problems

[Liviu Chircu]

Hi, Dawid!

I have looked into the problem and also managed to come up with a fix! 
Could you please go to your OpenSIPS 2.2 source code directory, apply 
the below patch, recompile the dialog module and see if it fixes the 
problem?


git apply <(base64 -d > wrote:


Hi All,

I have a reduntant OpenSIPS 2.2.1 setup with clusterer, binary
interface replication and a floating IP. I am encountering a few
niuances and am wondering if I am doing something wrong or if
there is a bug.

1) Replicated dialog hash id is different on the standby server
from the active server

active:

dialog::  hash=637:902131071
state:: 4
user_flags:: 0
timestart:: 1477413837
datestart:: 2016-10-25 18:43:57
timeout:: 1477435437
dateout:: 2016-10-26 00:43:57
callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg
...

standby:

dialog::  hash=637:902131072
state:: 4
user_flags:: 0
timestart:: 1477413837
datestart:: 2016-10-25 18:43:57
timeout:: 1477435438
dateout:: 2016-10-26 00:43:58
callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg
...

When a switch overoccurs during a dialog, and a request is
received on the second server the dialog can not be matched by the
DID param and has to fall back to looking for other SIP elements.

DBG:dialog:lookup_dlg: no dialog id=902131071 found on entry 637
DBG:dialog:dlg_onroute: unable to find dialog for BYE with route
param 'd72.f7d65c53'

2) No CDR on the standby server after switch over

When a switch over occurs during a dialog CDR is not generated at
the end of the call (I have to do it manually). I to not see any
run_dlg_callbacks info in debug logs although the replicated
dialog seems to have all the acc flags.

active:

dialog::  hash=637:902131071
...
values::
accX_table:: acc
accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00
accX_db:: \x07\x00\r\x0031.179.202.34\f\x00+48226522655
\f\x00+48226522655
\x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024
accX_leg:: \x00\x00\x00\x00
accX_core::

\x06\x00INVITE\b\x0004027a21\x01\x0030\x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\x07\x00\x00\x00\x00\x00
...
accX_created:: \xcb\x8

Re: [OpenSIPS-Users] Dialog replication problems

[Dawid Mielnik]

Anyone ?

I have just upgraded to the latest 2.2 version form GIT and am still
experiencing this.

active server:

dialog::  hash=*2297:947327686* dialog_id=9866487206598
state:: 4
user_flags:: 0
timestart:: 1478162278
datestart:: 2016-11-03 09:37:58
timeout:: 1478183878
dateout:: 2016-11-03 15:37:58
callid:: 81140ODk1MmU1MGM3MzZkZjMyYjIzY2I1ZDExZTI4ZDFiNjY
from_uri:: sip:+48226522...@xxx.xxx.xxx.250
to_uri:: sip:+48501657...@xxx.xxx.xxx.250
caller_tag:: 86343576
caller_contact:: sip:+48226522...@zzz.zzz.zzz.34
:60603;rinstance=eab8d8723e64bbad
callee_cseq:: 0
caller_route_set::
caller_bind_addr:: udp:XXX.XXX.XXX.250:5061
caller_sdp::
CALLEES::
callee::
callee_tag:: 192571
callee_contact:: sip:YYY.YYY.YYY.20:5060;transport=UDP
caller_cseq:: 1
callee_route_set::
callee_bind_addr:: udp:XXX.XXX.XXX.250:5060
callee_sdp::
...

standby server:

dialog::  hash=*2297:1952115624* dialog_id=9867491994536
state:: 4
user_flags:: 0
timestart:: 1478162278
datestart:: 2016-11-03 09:37:58
timeout:: 1478183877
dateout:: 2016-11-03 15:37:57
callid:: 81140ODk1MmU1MGM3MzZkZjMyYjIzY2I1ZDExZTI4ZDFiNjY
from_uri:: sip:+48226522...@xxx.xxx.xxx.250
to_uri:: sip:+48501657...@xxx.xxx.xxx.250
caller_tag:: 86343576
caller_contact:: sip:+48226522...@zzz.zzz.zzz.34
:60603;rinstance=eab8d8723e64bbad
callee_cseq:: 0
caller_route_set::
caller_bind_addr:: udp:XXX.XXX.XXX.250:5061
caller_sdp::
CALLEES::
callee::
callee_tag:: 192571
callee_contact:: sip:YYY.YYY.YYY.20:5060;transport=UDP
caller_cseq:: 1
callee_route_set::
callee_bind_addr:: udp:XXX.XXX.XXX.250:5060
callee_sdp::
...

After switch-over BYE is received on the standby server:

Nov  3 09:44:38.571442 DEB 10180  DBG:core:parse_msg: SIP Request:
Nov  3 09:44:38.571471 DEB 10180  DBG:core:parse_msg:  method:  
Nov  3 09:44:38.571475 DEB 10180  DBG:core:parse_msg:  uri:

Nov  3 09:44:38.571479 DEB 10180  DBG:core:parse_msg:  version: 
...
Nov  3 09:44:38.571809 DEB 10180  DBG:dialog:w_match_dialog: We found DID
param in R-URI with value of 9f8.6c217783
Nov  3 09:44:38.571812 DEB 10180  DBG:dialog:dlg_onroute: route param is
'9f8.6c217783' (len=12)
Nov  3 09:44:38.571814 DEB 10180  DBG:dialog:lookup_dlg: *no dialog
id=947327686 found on entry 2297*
Nov  3 09:44:38.571816 DEB 10180  DBG:dialog:dlg_onroute: unable to find
dialog for BYE with route param '9f8.6c217783'
...


Is this normal behaviour that dialog hash (and recently added dialog id)
are different on the replicated server ?

BR,
Dawid

On Wed, Oct 26, 2016 at 4:43 PM, Dawid Mielnik 
wrote:

> Hi All,
>
> I have a reduntant OpenSIPS 2.2.1 setup with clusterer, binary interface
> replication and a floating IP. I am encountering a few niuances and am
> wondering if I am doing something wrong or if there is a bug.
>
> 1) Replicated dialog hash id is different on the standby server from the
> active server
>
> active:
>
> dialog::  hash=637:902131071
> state:: 4
> user_flags:: 0
> timestart:: 1477413837
> datestart:: 2016-10-25 18:43:57
> timeout:: 1477435437
> dateout:: 2016-10-26 00:43:57
> callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg
> ...
>
> standby:
>
> dialog::  hash=637:902131072
> state:: 4
> user_flags:: 0
> timestart:: 1477413837
> datestart:: 2016-10-25 18:43:57
> timeout:: 1477435438
> dateout:: 2016-10-26 00:43:58
> callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg
> ...
>
> When a switch overoccurs during a dialog, and a request is received on the
> second server the dialog can not be matched by the DID param and has to
> fall back to looking for other SIP elements.
>
> DBG:dialog:lookup_dlg: no dialog id=902131071 found on entry 637
> DBG:dialog:dlg_onroute: unable to find dialog for BYE with route param
> 'd72.f7d65c53'
>
> 2) No CDR on the standby server after switch over
>
> When a switch over occurs during a dialog CDR is not generated at the end
> of the call (I have to do it manually). I to not see any run_dlg_callbacks
> info in debug logs although the replicated dialog seems to have all the acc
> flags.
>
> active:
>
> dialog::  hash=637:902131071
> ...
> values::
> accX_table:: acc
> accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00
> accX_db:: \x07\x00\r\x0031.179.202.34\f\x00+48226522655\f\x00+48226522655
> \x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024
> accX_leg:: \x00\x00\x00\x00
> accX_core:: \x06\x00INVITE\b\x0004027a21\x01\x0030\
> x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\
> x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\
> x07\x00\x00\x00\x00\x00
> ...
> accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00
> ...
> standby:
>
> dialog::  hash=637:902131072
> ...
> values::
> accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00
> ...
> accX_core:: \x06\x00INVITE\b\x0004027a21\x01\x0030\
> x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\
> x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\
> x07\x00\x00\x00\x00\x00
> accX_leg:: \x00\x00\x00\x00
> accX_db:: \x07\x00\r\x0031.179.202.34\f\x00+48226522655\f\x00+48226522655
> \x01\x001\f\x00+48501657778\

[OpenSIPS-Users] Dialog replication problems

[Dawid Mielnik]

Hi All,

I have a reduntant OpenSIPS 2.2.1 setup with clusterer, binary interface
replication and a floating IP. I am encountering a few niuances and am
wondering if I am doing something wrong or if there is a bug.

1) Replicated dialog hash id is different on the standby server from the
active server

active:

dialog::  hash=637:902131071
state:: 4
user_flags:: 0
timestart:: 1477413837
datestart:: 2016-10-25 18:43:57
timeout:: 1477435437
dateout:: 2016-10-26 00:43:57
callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg
...

standby:

dialog::  hash=637:902131072
state:: 4
user_flags:: 0
timestart:: 1477413837
datestart:: 2016-10-25 18:43:57
timeout:: 1477435438
dateout:: 2016-10-26 00:43:58
callid:: 81140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg
...

When a switch overoccurs during a dialog, and a request is received on the
second server the dialog can not be matched by the DID param and has to
fall back to looking for other SIP elements.

DBG:dialog:lookup_dlg: no dialog id=902131071 found on entry 637
DBG:dialog:dlg_onroute: unable to find dialog for BYE with route param
'd72.f7d65c53'

2) No CDR on the standby server after switch over

When a switch over occurs during a dialog CDR is not generated at the end
of the call (I have to do it manually). I to not see any run_dlg_callbacks
info in debug logs although the replicated dialog seems to have all the acc
flags.

active:

dialog::  hash=637:902131071
...
values::
accX_table:: acc
accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00
accX_db::
\x07\x00\r\x0031.179.202.34\f\x00+48226522655\f\x00+48226522655\x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024
accX_leg:: \x00\x00\x00\x00
accX_core::
\x06\x00INVITE\b\x0004027a21\x01\x0030\x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\x07\x00\x00\x00\x00\x00
...
accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00
...
standby:

dialog::  hash=637:902131072
...
values::
accX_created:: \xcb\x8b\x0fX\x00\x00\x00\x00
...
accX_core::
\x06\x00INVITE\b\x0004027a21\x01\x0030\x0081140Mzk5ZjViNjY5YzI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\x03\x00200\x02\x00OK\x10\x00\xcd\x8b\x0fX\x00\x00\x00\x00]\xb2\x07\x00\x00\x00\x00\x00
accX_leg:: \x00\x00\x00\x00
accX_db::
\x07\x00\r\x0031.179.202.34\f\x00+48226522655\f\x00+48226522655\x01\x001\f\x00+48501657778\f\x00+48501657778\x02\x0024
accX_flags:: \x00\x00\x07\x00\x00\x00\x02\x00
accX_table:: acc
...

My relevant config:
 DIALOG module
loadmodule "dialog.so"

modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "default_timeout", 21600)  # 6 hours timeout
modparam("dialog", "db_mode", 0)
modparam("dialog", "accept_replicated_dialogs", 1)
modparam("dialog", "replicate_dialogs_to", 1)
#modparam("dialog", "accept_replicated_profiles", 1)
#modparam("dialog", "replicate_profiles_to", 1)
modparam("dialog", "profiles_with_value", "trunkCalls")
modparam("dialog", "options_ping_interval", 60)

 CLUSTERER module
loadmodule "clusterer.so"
modparam("clusterer", "db_url", "text:///usr/local/etc/opensips")
modparam("clusterer", "server_id", 2) #2 or 1 depending on node


# for initial requests
do_accounting("db", "cdr|missed", "acc");


Has anyone experienced similar problems ? Is there something that I am
missing ?

Best regards,
Dawid
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users