[OpenSIPS-Users] Dialog replication problems

Thu Nov 3 10:09:55 CET 2016

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>
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\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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20161103/4d67def7/attachment-0001.htm>