<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&#39;m not a fan of that one.</div><div><br></div><div>Best,</div><div>Colin</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 7, 2016 at 1:18 PM Colin Morelli &lt;<a href="mailto:colin.morelli@gmail.com">colin.morelli@gmail.com</a>&gt; 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&#39;m trying to initiate a parallel outbound bridge to a SIP user and pickup group combination. I have devices on mobile networks that don&#39;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&#39;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>