14 May
2020
14 May
'20
11:21 p.m.
Dear Community,
I wrote before about my random issues with calls disconnection.
We found some issue in our VMWare environment that much packets was lost.
We resolved the issue by moving to other VMWare host however the issue is
still present.
Currently it is random and some calls do not disconnect due to no BYE
forwarded by kamailio to other side.
Here is the pcap of such call :
https://www.dropbox.com/s/7bktz3p4im6ztld/bad-dialog-call.zip?dl=1
We use dialog module and dispatcher.
dlg_manage(); is only executed in this block :
# - flags
# FLT_ - per transaction (message) flags
# FLB_ - per branch flags
#!define FLT_ACC 1
#!define FLT_ACCMISSED 2
#!define FLT_ACCFAILED 3
#!define FLT_DLG 4
.
.
.
# account only INVITEs
if (is_method("INVITE")) {
setflag(FLT_DLG); # create dialog << i added it
setflag(FLT_ACCMISSED); # do accounting even if failed << i added it
setflag(FLT_ACC); # do accounting
#route(LIMIT_CALLS);
dlg_manage();
sip_trace();
}
I really have no idea i am unable to find differences between the bad and
good call.
The SIP packets looking good but the BYE is not processed.
Please help me out how to debug it?
I was thinking of adding a log for checking if request is BYE and if it is
check if it match a dialog using is_known_dlg() method.
Please let me know if you see what is wrong.
Just to mention kamailio is listening on private IP with advertise to
public IP.
Best regards!
14 May
14 May
11:35 p.m.
Hi,
Comparing the e2e ACK (relayed successfully) and the BYEs (not relayed
successfully) side by side, there don't seem to be any structural
differences which would prevent the latter from being relayed.
I can't say for sure without looking at Kamailio logs at higher
verbosity (debug=3 or higher) to ascertain whether the BYE message is
being received, but at first glance, absent nonobvious explanations such
as routing complications, it would seem likely that Kamailio is actually
not receiving the BYE.
Could this be due to firewall rules, or something like fail2ban,
perhaps? Keep in mind that if a packet is filtered by
netfilter/iptables, it does not prevent it from showing up on the wire,
but that doesn't mean it reaches the listening application.
Assuming you've ruled that scenario out, can you turn up logging
verbosity in Kamailio and see if it's getting the BYEs, and if so, what
it's doing with them? Or there might be explanations in the logs even
without the added verbosity, such as failure to forward out of the
correct interface--some kind of condition which was not present at the
time the e2e ACK was processed.
-- Alex
On Thu, May 14, 2020 at 10:21:35PM +0200, Voip support wrote:
Dear Community,
I wrote before about my random issues with calls disconnection.
We found some issue in our VMWare environment that much packets was lost.
We resolved the issue by moving to other VMWare host however the issue is
still present.
Currently it is random and some calls do not disconnect due to no BYE
forwarded by kamailio to other side.
Here is the pcap of such call :
https://www.dropbox.com/s/7bktz3p4im6ztld/bad-dialog-call.zip?dl=1
We use dialog module and dispatcher.
dlg_manage(); is only executed in this block :
# - flags
# FLT_ - per transaction (message) flags
# FLB_ - per branch flags
#!define FLT_ACC 1
#!define FLT_ACCMISSED 2
#!define FLT_ACCFAILED 3
#!define FLT_DLG 4
.
.
.
# account only INVITEs
if (is_method("INVITE")) {
setflag(FLT_DLG); # create dialog << i added it
setflag(FLT_ACCMISSED); # do accounting even if failed << i added it
setflag(FLT_ACC); # do accounting
#route(LIMIT_CALLS);
dlg_manage();
sip_trace();
}
I really have no idea i am unable to find differences between the bad and
good call.
The SIP packets looking good but the BYE is not processed.
Please help me out how to debug it?
I was thinking of adding a log for checking if request is BYE and if it is
check if it match a dialog using is_known_dlg() method.
Please let me know if you see what is wrong.
Just to mention kamailio is listening on private IP with advertise to
public IP.
Best regards!
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
11:59 p.m.
Maybe in request route i should add something like :
is_method("BYE"){
xlog("Received $rm from $si with call id $ci ");
}
Then take wireshark trace and wait for the hung call and check if kamailio
logs has the line that the BYE was received?
This would confirm the BYE is getting received but it will no give me any
information why ist not relayed.
Best regards!
czw., 14 maj 2020 o 22:40 Alex Balashov <abalashov(a)evaristesys.com>
napisał(a):
Hi,
Comparing the e2e ACK (relayed successfully) and the BYEs (not relayed
successfully) side by side, there don't seem to be any structural
differences which would prevent the latter from being relayed.
I can't say for sure without looking at Kamailio logs at higher
verbosity (debug=3 or higher) to ascertain whether the BYE message is
being received, but at first glance, absent nonobvious explanations such
as routing complications, it would seem likely that Kamailio is actually
not receiving the BYE.
Could this be due to firewall rules, or something like fail2ban,
perhaps? Keep in mind that if a packet is filtered by
netfilter/iptables, it does not prevent it from showing up on the wire,
but that doesn't mean it reaches the listening application.
Assuming you've ruled that scenario out, can you turn up logging
verbosity in Kamailio and see if it's getting the BYEs, and if so, what
it's doing with them? Or there might be explanations in the logs even
without the added verbosity, such as failure to forward out of the
correct interface--some kind of condition which was not present at the
time the e2e ACK was processed.
-- Alex
On Thu, May 14, 2020 at 10:21:35PM +0200, Voip support wrote:
Dear Community,
I wrote before about my random issues with calls disconnection.
We found some issue in our VMWare environment that much packets was lost.
We resolved the issue by moving to other VMWare host however the issue is
still present.
Currently it is random and some calls do not disconnect due to no BYE
forwarded by kamailio to other side.
Here is the pcap of such call :
https://www.dropbox.com/s/7bktz3p4im6ztld/bad-dialog-call.zip?dl=1
We use dialog module and dispatcher.
dlg_manage(); is only executed in this block :
# - flags
# FLT_ - per transaction (message) flags
# FLB_ - per branch flags
#!define FLT_ACC 1
#!define FLT_ACCMISSED 2
#!define FLT_ACCFAILED 3
#!define FLT_DLG 4
.
.
.
# account only INVITEs
if (is_method("INVITE")) {
setflag(FLT_DLG); # create dialog << i added it
setflag(FLT_ACCMISSED); # do accounting even if failed << i
added
it
setflag(FLT_ACC); # do accounting
#route(LIMIT_CALLS);
dlg_manage();
sip_trace();
}
I really have no idea i am unable to find differences between the bad and
good call.
The SIP packets looking good but the BYE is not processed.
Please help me out how to debug it?
I was thinking of adding a log for checking if request is BYE and if it
is
check if it match a dialog using is_known_dlg()
method.
Please let me know if you see what is wrong.
Just to mention kamailio is listening on private IP with advertise to
public IP.
Best regards!
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
15 May
15 May
12:10 a.m.
On Thu, May 14, 2020 at 10:59:44PM +0200, Voip support wrote:
Maybe in request route i should add something like :
is_method("BYE"){
xlog("Received $rm from $si with call id $ci ");
}
Then take wireshark trace and wait for the hung call and check if kamailio
logs has the line that the BYE was received?
This would confirm the BYE is getting received but it will no give me any
information why ist not relayed.
Extra information is never bad information, and think logging
fundamental requests is good practice. However, I agree that this won't
give you much insight into why it's not relayed. But perhaps there are
contemporaneous log entries which can shed light on that; Kamailio is
generally pretty good about logging situations where t_relay() fails or
an interface cannot be selected or some other networking-related cause
that is known a priori at the time the relay attempt is made.
I'm thinking either outbound routing issue, or Kamailio isn't getting
the BYE in the first place.
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
10:33 p.m.
Hello Community,
Do you think in case calls coming from public IP to kamailio which is
listening on private IP with advertise and running rtpproxy. It could be
making issues with the signalling packets?
Should i maybe have 2 NIC configured one for public IP second for private
network without advertise?
I am still seeking for solution of this problem.
Today we changed our configuration to public IP's only and so far it works
well. No stuck calls in dialog.
Best regards!
czw., 14 maj 2020 o 23:15 Alex Balashov <abalashov(a)evaristesys.com>
napisał(a):
On Thu, May 14, 2020 at 10:59:44PM +0200, Voip support
wrote:
Maybe in request route i should add something
like :
is_method("BYE"){
xlog("Received $rm from $si with call id $ci ");
}
Then take wireshark trace and wait for the hung call and check if
kamailio
logs has the line that the BYE was received?
This would confirm the BYE is getting received but it will no give me any
information why ist not relayed.
Extra information is never bad information, and think logging
fundamental requests is good practice. However, I agree that this won't
give you much insight into why it's not relayed. But perhaps there are
contemporaneous log entries which can shed light on that; Kamailio is
generally pretty good about logging situations where t_relay() fails or
an interface cannot be selected or some other networking-related cause
that is known a priori at the time the relay attempt is made.
I'm thinking either outbound routing issue, or Kamailio isn't getting
the BYE in the first place.
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1655
days inactive
1656
days old
4 comments
2 participants
participants (2)
-
Alex Balashov -
Voip support