Re: [OpenSIPS-Users] Delayed Bye?
This is precisely due to the proportion of short-duration calls. But I agree that it is a very stupid way to approach the problem, particularly when you consider where most of the hangups in short duration calls actually come from. Some of them do you come from the originator, in the case of AMD. But many come from the PSTN callee - “oh, great, it’s another one of these OpenSIPS dialer people calling about an extended car warranty. *click*” That would cause the termination switch to have already processed the BYE, regardless of whether you delay your response to it. — Sent from mobile, with due apologies for brevity and errors. > On Jun 28, 2021, at 9:23 AM, Jeff Pyle wrote: > > > Eek. This sounds like a recipe for future problems with this carrier. If > you really want to try, you could do a sleep() or usleep() on BYE requests in > the section of your script that processes sequential requeststhe > has_totag() and loose_route() part (assuming no topology_hiding). That's > going to occupy the process, though, so you might want to look at doing it > async-style if scale is a concern. If you want to do it only on BYE requests > to the carrier rather than on BYE requests in both directions, then you'll > have to detect the direction, which is possible but gets more involved. > > I know I'm going to regret asking this, but why does your carrier want you to > delay your BYE messages? > > > - Jeff > > >> On Sun, Jun 27, 2021 at 5:07 PM Alexander Perkins >> wrote: >> Hi All. Our carrier has asked us if we can do a 'delayed bye'. I have no >> idea what this means. The way it was explained to me is - the b-let is >> held for x numbers of seconds after the a leg hangs up. >> >> Does that make sense? If so, can someone point me in the right direction? >> >> Thank you, >> Alex >> ___ >> Users mailing list >> 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Delayed Bye?
I'm assuming you have a lot of short ALOC calls in your mix to your vendor? You can do a delayed BYE with OpenSIPS, but it's a bit tricky, as once you do the dialog match on the BYE, the dialog gets torn down automatically by the OpenSIPs logic and the accounting is finalized. In 2.2 I had to write a patch to handle this, but I think you can do this in 3.1 with the load_dialog_ctx() and acc_load_ctx_from_dlg(). See here: http://lists.opensips.org/pipermail/users/2020-June/043346.html - Jon Abrams On Mon, Jun 28, 2021 at 8:25 AM Jeff Pyle wrote: > > Eek. This sounds like a recipe for future problems with this carrier. If > you really want to try, you could do a sleep() or usleep() on BYE requests in > the section of your script that processes sequential requeststhe > has_totag() and loose_route() part (assuming no topology_hiding). That's > going to occupy the process, though, so you might want to look at doing it > async-style if scale is a concern. If you want to do it only on BYE requests > to the carrier rather than on BYE requests in both directions, then you'll > have to detect the direction, which is possible but gets more involved. > > I know I'm going to regret asking this, but why does your carrier want you to > delay your BYE messages? > > > - Jeff > > > On Sun, Jun 27, 2021 at 5:07 PM Alexander Perkins > wrote: >> >> Hi All. Our carrier has asked us if we can do a 'delayed bye'. I have no >> idea what this means. The way it was explained to me is - the b-let is >> held for x numbers of seconds after the a leg hangs up. >> >> Does that make sense? If so, can someone point me in the right direction? >> >> Thank you, >> Alex >> ___ >> Users mailing list >> 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Delayed Bye?
Eek. This sounds like a recipe for future problems with this carrier. If you really want to try, you could do a sleep() or usleep() on BYE requests in the section of your script that processes sequential requeststhe has_totag() and loose_route() part (assuming no topology_hiding). That's going to occupy the process, though, so you might want to look at doing it async-style if scale is a concern. If you want to do it only on BYE requests to the carrier rather than on BYE requests in both directions, then you'll have to detect the direction, which is possible but gets more involved. I know I'm going to regret asking this, but why does your carrier want you to delay your BYE messages? - Jeff On Sun, Jun 27, 2021 at 5:07 PM Alexander Perkins < alexanderhenryperk...@gmail.com> wrote: > Hi All. Our carrier has asked us if we can do a 'delayed bye'. I have no > idea what this means. The way it was explained to me is - the b-let is > held for x numbers of seconds after the a leg hangs up. > > Does that make sense? If so, can someone point me in the right direction? > > Thank you, > Alex > ___ > Users mailing list > 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
[OpenSIPS-Users] Delayed Bye?
Hi All. Our carrier has asked us if we can do a 'delayed bye'. I have no idea what this means. The way it was explained to me is - the b-let is held for x numbers of seconds after the a leg hangs up. Does that make sense? If so, can someone point me in the right direction? Thank you, Alex ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
