Hi Ben,
OK, I will need to test this scenario. Let me get back to you!
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]>
*Date: *Friday, September 21, 2018 at 5:31 AM
*To: *Ben Newlin <[email protected]>, OpenSIPS users mailling
list <[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
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
