Bogdan,
Apologies for the delay in responding.
I had originally seen this issue on a live server and I believed I had
reproduced it locally, but upon further testing with multiple
scenarios including timeouts I have not been able to reproduce. The
behavior is as you describe that the first received response
terminates the dialog. Thank you for your help with this issue.
Ben Newlin
*From: *Bogdan-Andrei Iancu <[email protected]>
*Date: *Monday, October 8, 2018 at 7:10 AM
*To: *Ben Newlin <[email protected]>, OpenSIPS users mailling
list <[email protected]>
*Subject: *Re: [OpenSIPS-Users] Accounting BYE response
HI Ben,
Could you re-test with the flow I had ? Normally it should not be a
difference between locally and received replies.
But to be more clear, in your case, the first BYE is 481 and the
second is timeout ? or ?
Regards
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 10/02/2018 04:45 PM, Ben Newlin wrote:
Bogdan,
That is a good test, but I am not sure what to say. That is not
the behavior I am seeing and the acc variable is not being set for
me. I am also on 2.4.2.
One difference in my case is that it is not a local timeout
causing the failure. We are receiving a 481 response from the far
end. Perhaps when an actual failure response is received instead
of a local timeout the operation is different in OpenSIPS?
Ben Newlin
*From: *Bogdan-Andrei Iancu <[email protected]>
<mailto:[email protected]>
*Date: *Tuesday, October 2, 2018 at 4:59 AM
*To: *Ben Newlin <[email protected]>
<mailto:[email protected]>, OpenSIPS users mailling list
<[email protected]> <mailto:[email protected]>
*Subject: *Re: [OpenSIPS-Users] Accounting BYE response
Hi Ben,
OK, my experiment with 2.4 :
* Have a call up between two endpoints
* kill the end points, without allowing them to send any BYE or so
* do an dlg_end_dlg from opensips proxy
What I got:
1) the 2 BYE requests are send out, both visiting the local route
(where the failure route is armed)
2) the first BYE ends with internal 408 timeout (based on
retransmissions), failure route is triggered (where an extra acc
var is set), the dialog transits into TERMINATED state, the acc
CDR is generated (holding the value set in failure route)
3) the second BYE ends also with 408 timeout, the failure route is
also triggered (I can see the xlog()), but as the dialog is
TERMINATED, there is no impact on the acc level.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 09/21/2018 03:07 PM, Ben Newlin wrote:
Bogdan,
Yes, as per the script example I provided originally I am
arming failure_route always in local_route and setting the
acc_extra variable in failure_route. Even in the case where
the first BYE response is a failure, the acc_extra variable is
not being set. This seems to indicate the dialog is being
terminated prior to the call to the failure route.
Ben Newlin
*From: *Bogdan-Andrei Iancu <[email protected]>
<mailto:[email protected]>
*Date: *Friday, September 21, 2018 at 5:31 AM
*To: *Ben Newlin <[email protected]>
<mailto:[email protected]>, OpenSIPS users mailling list
<[email protected]> <mailto:[email protected]>
*Subject: *Re: [OpenSIPS-Users] Accounting BYE response
Hi Ben,
The Dialog is not terminated (as status) with the first
successful BYE reply, but with the first reply (whatever the
status is). Even if both caller and callee BYE will turn into
408 or 481, the first to fire will terminate the dialog
session. But you say that if failure_route is triggered for
both BYEs, you still see no acc extra data (even if at first
one should have been executed before dialog termination) ?
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 09/20/2018 06:57 PM, Ben Newlin wrote:
Bogdan,
This is a good point and I did consider that. However,
this only makes sense in the case where there is a
successful response prior to the error response. As I
noted I have seen this occur when both parties reply to
the BYE with a 481 response. If the Dialog and ACC modules
were triggering on the first BYE reply received, then my
flag should still be getting set in this case as the first
reply is guaranteed to be a failure.
Is it possible the dialog termination and CDR generation
are being triggered prior to the failure_route callback?
If so, are they also triggered prior to a reply_route
callback? Would it make sense to delay the dialog
termination until after failure_route processing to allow
the script to make final adjustments to the CDR such as this?
Ben Newlin
*From: *Bogdan-Andrei Iancu <[email protected]>
<mailto:[email protected]>
*Date: *Thursday, September 20, 2018 at 11:42 AM
*To: *OpenSIPS users mailling list
<[email protected]>
<mailto:[email protected]>, Ben Newlin
<[email protected]> <mailto:[email protected]>
*Subject: *Re: [OpenSIPS-Users] Accounting BYE response
Hi Ben,
The issue is a bit more complex. When generating the BYE
requests, the dialog module triggers the event of call
terminated when it gets back the first final reply (to any
of the BYEs). And ACC module generates the CDR when the
dialog is terminated.
So, the second BYE (which probably ends with timeout) ends
in failure route (and set the acc extra) *after* the call
was terminated and the CDR generated.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2018
http://opensips.org/training/OpenSIPS_Bootcamp_2018/
On 09/08/2018 01:00 AM, Ben Newlin wrote:
David,
I agree that there are better ways to do billing, but
I must work within the constraints of the larger
system of which I am only a part.
We do use some other techniques to detect “stuck”
calls, including the (fairly) new Re-Invite pinging
mechanism of the dialog module. We do not process the
audio, so silence detection is not possible.
It is a very small number of calls that are affected
by this, hopefully none now that we have the pinging
in place, but I am still interested in the answer to
the question. It seems to me there could be other use
cases for modifying the CDR based on the response to a
BYE, whether generated from OpenSIPS or not.
Ben Newlin
*From: *Users <[email protected]>
<mailto:[email protected]> on behalf of
David Villasmil <[email protected]>
<mailto:[email protected]>
*Reply-To: *OpenSIPS users mailling list
<[email protected]>
<mailto:[email protected]>
*Date: *Friday, September 7, 2018 at 5:53 PM
*To: *OpenSIPS users mailling list
<[email protected]>
<mailto:[email protected]>
*Subject: *Re: [OpenSIPS-Users] Accounting BYE response
I think you should take care of this on your gateway.
For example, using freeswitch or asterisk, you can
check for rtps, and when the other end stops sending
rtps for 30 seconds (configurable) it will tear down
the call properly.
Unless you're using a rtp-proxy with opensips which
can do this (most can), that's the way to do this.
Anything else is just duct-taping.
My opinion after 20 years on voip.
Hope that helps.
David
On Fri, Sep 7, 2018, 21:43 Ben Newlin
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
I am having an issue trying to add values to
accounting based on the response to the BYE request.
We use the dialog timeout mechanism to terminate
long calls in our system. In some cases, these are
“valid” calls that remained connected for too long
due to some error elsewhere in the application.
But sometimes one or both ends of the call believe
they have disconnected, but we did not receive or
process the disconnect, due to a malformed BYE or
a network disruption. In these cases, when the
Dialog timeout is reached and OpenSIPS generates a
BYE to both parties, they will respond with a 481.
What I want is to set a CDR flag on receipt of
that 481 to indicate that there was an error and
the calculated call time may not be correct. But
it seems that any accounting flags set after the
BYE is sent are not honored. Is there any way to
accomplish this?
This is my attempt:
failure_route[local_failure]
{
$acc_extra(disconnect_error) = "true";
}
local_route
{
t_on_failure("local_failure");
}
Ben Newlin
_______________________________________________
Users mailing list
[email protected]
<mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
