[OpenSIPS-Users] Dialog replication problems

Liviu Chircu liviu at opensips.org
Thu Nov 3 11:27:23 CET 2016


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 <<EOF
ZGlmZiAtLWdpdCBhL21vZHVsZXMvZGlhbG9nL2RsZ19yZXBsaWNhdGlvbi5jIGIvbW9kdWxlcy9k
aWFsb2cvZGxnX3JlcGxpY2F0aW9uLmMKaW5kZXggYTg0NTVhZi4uZGE2MmRiNiAxMDA2NDQKLS0t
IGEvbW9kdWxlcy9kaWFsb2cvZGxnX3JlcGxpY2F0aW9uLmMKKysrIGIvbW9kdWxlcy9kaWFsb2cv
ZGxnX3JlcGxpY2F0aW9uLmMKQEAgLTE4Miw3ICsxODIsNiBAQCBpbnQgZGxnX3JlcGxpY2F0ZWRf
Y3JlYXRlKHN0cnVjdCBkbGdfY2VsbCAqY2VsbCwgc3RyICpmdGFnLCBzdHIgKnR0YWcsIGludCBz
YWZlKQogCWRsZy0+bGVnc19ub1tETEdfTEVHXzIwME9LXSA9IERMR19GSVJTVF9DQUxMRUVfTEVH
OwogCiAJLyogbGluayB0aGUgZGlhbG9nIGludG8gdGhlIGhhc2ggKi8KLQlkbGctPmhfaWQgPSBk
X2VudHJ5LT5uZXh0X2lkKys7CiAJaWYgKCFkX2VudHJ5LT5maXJzdCkKIAkJZF9lbnRyeS0+Zmly
c3QgPSBkX2VudHJ5LT5sYXN0ID0gZGxnOwogCWVsc2Ugewo=
EOF
)

Liviu Chircu
OpenSIPS Developer
http://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:+48226522655 at XXX.XXX.XXX.250
> to_uri:: sip:+48501657887 at XXX.XXX.XXX.250
> caller_tag:: 86343576
> caller_contact:: 
> sip:+48226522655 at 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:+48226522655 at XXX.XXX.XXX.250
> to_uri:: sip:+48501657887 at XXX.XXX.XXX.250
> caller_tag:: 86343576
> caller_contact:: 
> sip:+48226522655 at 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:  <BYE>
> Nov  3 09:44:38.571475 DEB 10180  DBG:core:parse_msg:  uri:     
> <sip:XXX.XXX.XXX.250:5061;did=9f8.6c217783>
> Nov  3 09:44:38.571479 DEB 10180  DBG:core:parse_msg:  version: <SIP/2.0>
> ...
> 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 
> <dawid.mielnik at gmail.com <mailto:dawid.mielnik at gmail.com>> 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
>     <tel:%2B48226522655>\f\x00+48226522655
>     <tel:%2B48226522655>\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
>     <tel:%2B48226522655>\f\x00+48226522655
>     <tel:%2B48226522655>\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 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/20161103/0c0885cc/attachment-0001.htm>


More information about the Users mailing list