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

Reply via email to