[OpenSIPS-Users] Delayed Bye?

[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. The originating service providers, or their clients, often
use a 7-second  hold (or higher) to mask this behavior downstream. It keeps
the ALOC above the underlying carriers' traffic profile requirements and
makes the Short Call Percentage zero (ratio of connected calls less than 6
seconds).

Editorial: If you or your clients require this kind of tricky billing, it
might be time to reconsider the legitimacy of the business case.



Calvin Ellison

Systems Architect

calvin.ellison at voxox.com


<http://voxox.com>

<https://www.facebook.com/VOXOX/> <https://www.instagram.com/voxoxofficial/>
<https://www.linkedin.com/company/3573541/admin/>
<https://twitter.com/Voxox>

The information contained herein is confidential and privileged information
or work product intended only for the individual or entity to whom it is
addressed. Any unauthorized use, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify me immediately.


On Mon, Jun 28, 2021 at 7:56 AM Alex Balashov <abalashov at evaristesys.com>
wrote:

> 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 <jeff at ugnd.org> 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 requests....the
> 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 <
> alexanderhenryperkins at 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 at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> 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/20210628/f8e3883d/attachment-0001.html>