<div dir="ltr">After more digging it looks like this isn't possible (if someone knows how, please do inform me!)<div><br></div><div>The problem appears to be on line 781 of switch_ivr_originate.c:</div><div><br></div><div><div> <font face="monospace">if (oglobals->hups > 0 && oglobals->hups + pickups == len) {</font></div><div><font face="monospace"><span class="Apple-tab-span" style="white-space:pre"> </span>rval = 0;</font></div><div><font face="monospace"><span class="Apple-tab-span" style="white-space:pre"> </span>} else {</font></div><div><font face="monospace"><span class="Apple-tab-span" style="white-space:pre"> </span>rval = 1;</font></div><div><font face="monospace"><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div></div><div><font face="monospace"><br></font></div><div><font face="monospace"> <span style="font-size:10.5625px;line-height:15.8438px">if (rval == 0 && pickups) {</span></font></div><div><font face="monospace"><span style="font-size:10.5625px;line-height:15.8438px"><span class="Apple-tab-span" style="white-space:pre"> </span>for (i = 0; i < len; i++) {</span></font></div><div><font face="monospace"><span style="font-size:10.5625px;line-height:15.8438px"><span class="Apple-tab-span" style="white-space:pre"> </span>if (originate_status[i].peer_channel && switch_channel_test_flag(originate_status[i].peer_channel, CF_PICKUP) && </span></font></div><div><font face="monospace"><span style="font-size:10.5625px;line-height:15.8438px"><span class="Apple-tab-span" style="white-space:pre"> </span>switch_channel_up(originate_status[i].peer_channel)) {</span></font></div><div><font face="monospace"><span style="font-size:10.5625px;line-height:15.8438px"><span class="Apple-tab-span" style="white-space:pre"> </span>switch_channel_hangup(originate_status[i].peer_channel, SWITCH_CAUSE_NO_PICKUP);</span></font></div><div><font face="monospace"><span style="font-size:10.5625px;line-height:15.8438px"><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></font></div><div><font face="monospace"><span style="font-size:10.5625px;line-height:15.8438px"><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></font></div><div><font face="monospace"><span style="font-size:10.5625px;line-height:15.8438px"><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></font></div><div><font face="monospace"><span style="font-size:10.5625px;line-height:15.8438px"><br></span></font></div><div><span style="line-height:15.8438px"><font size="2">Essentially, if I'm reading this correctly, if there is <i>at least one</i> 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.</font></span></div><div><span style="line-height:15.8438px"><font size="2"><br></font></span></div><div><font size="2"><span style="line-height:15.8438px">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.</span></font></div><div><font size="2"><span style="line-height:15.8438px"><br></span></font></div><div><font size="2"><span style="line-height:15.8438px">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.</span></font></div><div><font size="2"><span style="line-height:15.8438px"><br></span></font></div><div><font size="2"><span style="line-height:15.8438px">Best,</span></font></div><div><font size="2"><span style="line-height:15.8438px">Colin</span></font></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 8, 2016 at 9:23 PM Colin Morelli <<a href="mailto:colin.morelli@gmail.com">colin.morelli@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Joel,<br><br>Thanks for the reply.<br><br>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.<br><br>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.<br><br>Hope that clarifies.<br><br>Best,<br>Colin<br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 8, 2016 at 9:13 PM Joel Serrano <<a href="mailto:joel@gogii.net" target="_blank">joel@gogii.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Colin, <div><br></div><div>I'm not sure I understand completely your scenario... In our case:</div><div><br></div><div>1- Caller dials ---> FS bridges him in pickup with a ringing tone and a 25s timeout.</div><div>2- PUSH is sent to callee app (mobile device)</div><div>3- Callee dials in ---> FS uses headers sent in the INVITE to know which pickup he should go to.</div><div>4- Caller and callee talk.</div><div><br></div><div>NOTE: If the 25s timeout is reached before the callee has dialed in, the caller leg is sent to voicemail.</div><div><br></div><div>This scenario is working perfectly.</div><div><br></div><div>Can you describe a little more the difference with your approach? (I'd like to help but I'm not 100% sure I can).</div><div><br></div><div>Thanks!</div><div>Joel.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 8, 2016 at 3:15 PM, Colin Morelli <span dir="ltr"><<a href="mailto:colin.morelli@gmail.com" target="_blank">colin.morelli@gmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Any thoughts here?<div><br></div><div>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.</div><div><br></div><div>Best,</div><div>Colin</div></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 7, 2016 at 1:18 PM Colin Morelli <<a href="mailto:colin.morelli@gmail.com" target="_blank">colin.morelli@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey all,<div><br></div><div>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)</div><div><br></div><div>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).</div><div><br></div><div>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?</div><div><br></div><div>Best,</div><div>Colin</div></div></blockquote></div>
</div></div><br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br></blockquote></div><br></div>
_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.org</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a></blockquote></div></blockquote></div>