[Freeswitch-users] Unpark call

[Carlos Ruiz Díaz]

Alright, this is the solution I ended up building.

1. Kamailio receives the call, detects everyone is busy, parks the call and
updates a Redis queue

2. FS polls for updates using a Lua script querying the Redis queue from
time to time

3. As soon as an agent gets available, the script transfers the call back
to Kamailio

There's some non-ordinary Redis manipulation in the middle, making this
solution not easy and probably, not ideal. Nevertheless, it works quite
well and helped me keep my main logic inside Kamailio.

Thank you Sammy for your help!
Carlos



On Tue, Jul 28, 2015 at 5:54 PM, Carlos Ruiz Díaz <carlos.ruizdiaz at gmail.com
> wrote:

> Thank you very much Sammy.
>
> Some of the alternatives you suggested crossed my mind already, but I lack
> the required FS experience to implement them so I'm getting it now :).
>
> I will let you know what solution I ended up using so that everyone could
> benefit from it.
>
> Have a nice day.
> Carlos
>
>
> On Tue, Jul 28, 2015 at 5:46 PM, SamyGo <govoiper at gmail.com> wrote:
>
>> *Stage-1 Kamailio*
>> You'll have three things at Kamailio
>> 1-  Call-ID and
>> 2-  FS Server IP hosting this parking lot
>> 3-  Destination Number which was busy.
>>
>> store 1,and 2 in redis hash with Call-ID as Key. Store 3 at a redis hash
>> "TriggerUnPark"
>>
>> *Stage-2: FreeSwitch*
>>
>> At FS the first thing you do is get the sip header Call-ID, and update
>> the redis Call-ID Hash with the FS uuid of this call.
>>
>> *Stage-3: Kamailio if(is_method("BYE")) {*
>> check the redis hash "TriggerUnPark" if the $tU is found in there,
>> if yes delete it from the hash and execute a small lua script
>> "unpark.lua" with Call-ID as its argument
>> *}*
>>
>>
>> *Stage-4:*
>> the unpark.lua will retrieve the Call-ID, find the relevant FS Server IP,
>> connect to its ESL layer, and originate a call towards the Kamailio Server
>> for the destination number.
>>
>> If destination number is available call gets bridged in the lua script
>> else it drops back to the parking lot and Stage-1 repeats.
>>
>>
>> I just wrote this as I could possibly think of how this would work, so I
>> imagine there must be easier and efficient ways to do this all.
>>
>> Regards,
>> Sammy
>>
>>
>> On Tue, Jul 28, 2015 at 6:34 PM, SamyGo <govoiper at gmail.com> wrote:
>>
>>> my idea in line.
>>>
>>> On Tue, Jul 28, 2015 at 5:41 PM, Carlos Ruiz Díaz <
>>> carlos.ruizdiaz at gmail.com> wrote:
>>>
>>>> On Tue, Jul 28, 2015 at 4:30 PM, SamyGo <govoiper at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Can you tell if FS is involved in all calls or Kamailio dials A and B
>>>>> party and only sends calls to a parking lot in failure route ?
>>>>>
>>>>
>>>> Yes. I maintain state of which calls went to FS, and which ones didn't.
>>>>
>>>> I was thinking of using something like a notifier that should be fired
>>>> from Kamailio (using http maybe?) and be received by FS somewhere. This
>>>> would tell which parking queue to process and later "deflect" or "bridge"
>>>> the call again to Kamailio which will forward it to the right agent.
>>>>
>>>> Is this achievable?
>>>>
>>> Yes. I beleive if you've the uuid of the call stored in a redis hash
>>> corresponding to the SIP Call-ID header , and you tell you maintain state
>>> of which calls sent ..so as soon as B party gets diconnected you can
>>> trigger an ESL/API command to FS to "bridge" that uuid with a particular
>>> destination_number.
>>>
>>>
>>>>
>>>>>
>>>>> We did this long time ago with OpenSIPS where A party goes into fake
>>>>> ringing at a FS server and keeps dialing B party number at OpenSIPS gw
>>>>> every after 45 or so seconds, if B party is available FS bridges the call,
>>>>> if not then again stay at the parking lot. You need to set some
>>>>> valet_parking_ variables for timeout and orbit extension.
>>>>>
>>>>
>>>> This looks like a polling procedure, right? I will have to study valet
>>>> parking first to see what I can do with it.
>>>>
>>>
>>> Yes exactly what it is, that how valet_parking_timeout works. Its upto
>>> you whichever way you like to go with.
>>>
>>>>
>>>> Thank you Sammy!
>>>>
>>>>
>>>>>
>>>>> Given some more details I think I can help you out here.
>>>>>
>>>>> BR,
>>>>> Sammy
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 28, 2015 at 4:22 PM, Carlos Ruiz Díaz <
>>>>> carlos.ruizdiaz at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm looking for a way to unpark a call remotely.
>>>>>>
>>>>>> I have this scenario that involves Kamailio as registrar and proxy,
>>>>>> and I'm sending calls to FS whenever an user is busy and can't pick up a
>>>>>> call. This call is parked by FS.
>>>>>>
>>>>>> When Kamailio detects the user in question got available, I want to
>>>>>> unpark the previous call and connect it to the original destination.
>>>>>>
>>>>>> Any ideas on how to do this in a clean way?
>>>>>>
>>>>>> Regards,
>>>>>> --
>>>>>> Carlos
>>>>>> http://caruizdiaz.com
>>>>>>
>>>>>>
>>>>>> _________________________________________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Carlos
>>>> http://caruizdiaz.com
>>>>
>>>>
>>>> _________________________________________________________________________
>>>> 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
>>
>
>
>
> --
> Carlos
> http://caruizdiaz.com
>



-- 
Carlos
http://caruizdiaz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150731/f5dcb6c8/attachment.html