[OpenSIPS-Users] Accounting BYE response
Bogdan-Andrei Iancu
bogdan at opensips.org
Wed Sep 26 05:39:44 EDT 2018
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 <bogdan at opensips.org>
> *Date: *Friday, September 21, 2018 at 5:31 AM
> *To: *Ben Newlin <Ben.Newlin at genesys.com>, OpenSIPS users mailling
> list <users at lists.opensips.org>
> *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 <bogdan at opensips.org>
> <mailto:bogdan at opensips.org>
> *Date: *Thursday, September 20, 2018 at 11:42 AM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
> <mailto:users at lists.opensips.org>, Ben Newlin
> <Ben.Newlin at genesys.com> <mailto:Ben.Newlin at 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-bounces at lists.opensips.org>
> <mailto:users-bounces at lists.opensips.org> on behalf of David
> Villasmil <david.villasmil.work at gmail.com>
> <mailto:david.villasmil.work at gmail.com>
> *Reply-To: *OpenSIPS users mailling list
> <users at lists.opensips.org> <mailto:users at lists.opensips.org>
> *Date: *Friday, September 7, 2018 at 5:53 PM
> *To: *OpenSIPS users mailling list <users at lists.opensips.org>
> <mailto:users at 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.Newlin at genesys.com
> <mailto:Ben.Newlin at 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 at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
> _______________________________________________
>
> Users mailing list
>
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20180926/1c4a307a/attachment-0001.html>
More information about the Users
mailing list