[Freeswitch-users] Parallel Outbound Dialing Failure Causes

[Colin Morelli]

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/2c8960ab/attachment.html