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
bothcaller and callee BYEwill 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 <bog...@opensips.org>
*Date: *Thursday, September 20, 2018 at 11:42 AM
*To: *OpenSIPS users mailling list <users@lists.opensips.org>, Ben
Newlin <ben.new...@genesys.com>
*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 <users-boun...@lists.opensips.org>
<mailto:users-boun...@lists.opensips.org> on behalf of David
Villasmil <david.villasmil.w...@gmail.com>
<mailto:david.villasmil.w...@gmail.com>
*Reply-To: *OpenSIPS users mailling list
<users@lists.opensips.org> <mailto:users@lists.opensips.org>
*Date: *Friday, September 7, 2018 at 5:53 PM
*To: *OpenSIPS users mailling list <users@lists.opensips.org>
<mailto:users@lists.opensips.org>
*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 <ben.new...@genesys.com
<mailto:ben.new...@genesys.com>> 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
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
