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: <BYE> Nov 3 11:48:55.964191 DEB 29249 DBG:core:parse_msg: uri: <sip: XXX.XXX.XXX.250:5061;did=26d.162fec65> Nov 3 11:48:55.964197 DEB 29249 DBG:core:parse_msg: version: <SIP/2.0> ... 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 <[email protected]> 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 <<EOF > 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:[email protected] > to_uri:: sip:[email protected] > caller_tag:: 86343576 > caller_contact:: sip:[email protected]: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:[email protected] > to_uri:: sip:[email protected] > caller_tag:: 86343576 > caller_contact:: sip:[email protected]: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 <[email protected]> > 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\x0081140Mzk5ZjViNjY5Y >> zI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\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\x0081140Mzk5ZjViNjY5Y >> zI3MDI5NDMxMDUwZTdlNmQ1MDBhNzg\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 > [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
