[Freeswitch-users] Parallel Outbound Dialing Failure Causes

[Colin Morelli]

After more digging it looks like this isn't possible (if someone knows how,
please do inform me!)

The problem appears to be on line 781 of switch_ivr_originate.c:

              if (oglobals->hups > 0 && oglobals->hups + pickups == len) {
rval = 0;
} else {
rval = 1;
}

        if (rval == 0 && pickups) {
for (i = 0; i < len; i++) {
if (originate_status[i].peer_channel &&
switch_channel_test_flag(originate_status[i].peer_channel, CF_PICKUP) &&
switch_channel_up(originate_status[i].peer_channel)) {
switch_channel_hangup(originate_status[i].peer_channel,
SWITCH_CAUSE_NO_PICKUP);
}
}
}

Essentially, if I'm reading this correctly, if there is *at least one* hangup
on one of the parallel forked channel, and the total number of hung up
channels + the number of pickup channels is equal to the total number of
forked legs (all that are left are pickup channels), then hangup any
remaining pickup channels.

In other words: this works in a serial fork scenario, because for the
pickup leg, there will be no hangups, so the oglobals->hups > 0 check will
fail, and rval = 1, which will continue until the time limit is reached.
However, in a parallel forked dial, if the SIP fork fails, then hups = 1,
that check passes, and the only remaining channel is the pickup channel so
it continues.

I could be wrong but this seems like a bug (having a pickup that only lasts
as long as the parallel forks it's sitting with practically defeats the
purpose of the pickup in many cases), so I'll report and see if we can come
up with a reasonable solution.

Best,
Colin

On Fri, Jul 8, 2016 at 9:23 PM Colin Morelli <colin.morelli at gmail.com>
wrote:

> Hey Joel,
>
> Thanks for the reply.
>
> My case is similar to yours, but instead of just bridging to a pickup
> group I have a forked dial to a SIP endpoint and pickup group. This is to
> support other clients that may be registered to the SIP endpoint.
>
> My issue here is that the bridge ends when the SIP registrar responds. I
> would expect it to sit in the pickup group until the timeout or an explicit
> decline is received.
>
> Hope that clarifies.
>
> Best,
> Colin
> On Fri, Jul 8, 2016 at 9:13 PM Joel Serrano <joel at gogii.net> wrote:
>
>> Hi Colin,
>>
>> I'm not sure I understand completely your scenario... In our case:
>>
>> 1- Caller dials ---> FS bridges him in pickup with a ringing tone and a
>> 25s timeout.
>> 2- PUSH is sent to callee app (mobile device)
>> 3- Callee dials in ---> FS uses headers sent in the INVITE to know which
>> pickup he should go to.
>> 4- Caller and callee talk.
>>
>> NOTE: If the 25s timeout is reached before the callee has dialed in, the
>> caller leg is sent to voicemail.
>>
>> This scenario is working perfectly.
>>
>> Can you describe a little more the difference with your approach? (I'd
>> like to help but I'm not 100% sure I can).
>>
>> Thanks!
>> Joel.
>>
>>
>>
>>
>> On Fri, Jul 8, 2016 at 3:15 PM, Colin Morelli <colin.morelli at gmail.com>
>> wrote:
>>
>>> Any thoughts here?
>>>
>>> I think I can probably solve this with an additional forked dial to a
>>> loopback leg that sleeps for the call_timeout and then completes, but I
>>> want to see if anyone else has a suggestion because I'm not a fan of that
>>> one.
>>>
>>> Best,
>>> Colin
>>>
>>> On Thu, Jul 7, 2016 at 1:18 PM Colin Morelli <colin.morelli at gmail.com>
>>> wrote:
>>>
>>>> Hey all,
>>>>
>>>> I'm trying to initiate a parallel outbound bridge to a SIP user and
>>>> pickup group combination. I have devices on mobile networks that don't
>>>> register (my experience has been that doing SIP registrations on mobile
>>>> devices makes little sense - better off to just send a push notification
>>>> and allow them to call into FS with a pickup group)
>>>>
>>>> Anyway, it seems like the call is immediately terminated when FS
>>>> receives a final response from my SIP endpoint, whether the call_timeout
>>>> value has been reached or not. I've tried setting
>>>> fail_on_single_reject=CALL_REJECTED, FS immediately closes the pickup group
>>>> channel and terminates the bridge, even when the response from the SIP
>>>> endpoint is UNALLOCATED_NUMBER (404).
>>>>
>>>> Am I missing something else here - is this a bug or is this how pickup
>>>> groups are supposed to work? If the latter, is there something else I can
>>>> do to ensure the channel bridge attempt stays active and ringing until the
>>>> timeout is reached, unless one of the legs responds with an explicit
>>>> decline?
>>>>
>>>> Best,
>>>> Colin
>>>>
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://confluence.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://confluence.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160709/d910d923/attachment-0001.html