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@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@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@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@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@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@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@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@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org