Re: [OpenSIPS-Users] Delayed Bye?

2021-06-28 Thread Calvin Ellison
In the short-duration/dialer market, you would be surprised at the proportion of answered calls that were disconnected by the originating party, not the terminating party. Often these are working-number or fax machine probes, or failed "direct to voicemail" call forks, or Wangiri/ring once schemes.

Re: [OpenSIPS-Users] Delayed Bye?

2021-06-28 Thread Alex Balashov
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

Re: [OpenSIPS-Users] Delayed Bye?

2021-06-28 Thread Jonathan Abrams
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

Re: [OpenSIPS-Users] Delayed Bye?

2021-06-28 Thread Jeff Pyle
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 goi