[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