[OpenSIPS-Users] Accounting BYE response
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Oct 16 12:25:34 EDT 2018
OK :). If the issue pops up again, let me know.
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/16/2018 06:32 PM, Ben Newlin wrote:
>
> Bogdan,
>
> Apologies for the delay in responding.
>
> I had originally seen this issue on a live server and I believed I had
> reproduced it locally, but upon further testing with multiple
> scenarios including timeouts I have not been able to reproduce. The
> behavior is as you describe that the first received response
> terminates the dialog. Thank you for your help with this issue.
>
> Ben Newlin
>
> *From: *Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Date: *Monday, October 8, 2018 at 7:10 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,
>
> 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>
> <mailto:bogdan at opensips.org>
> *Date: *Tuesday, October 2, 2018 at 4:59 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,
>
> 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/20181016/1892ff62/attachment-0001.html>
More information about the Users
mailing list