[OpenSIPS-Users] Accounting BYE response
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Oct 8 07:09:40 EDT 2018
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 <bogdan at opensips.org>
> *Date: *Tuesday, October 2, 2018 at 4:59 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,
>
> 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 <bogdan at opensips.org>
> <mailto:bogdan at opensips.org>
> *Date: *Friday, September 21, 2018 at 5:31 AM
> *To: *Ben Newlin <Ben.Newlin at genesys.com>
> <mailto:Ben.Newlin at genesys.com>, OpenSIPS users mailling list
> <users at lists.opensips.org> <mailto: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/20181008/e8e8926e/attachment-0001.html>
More information about the Users
mailing list