[Freeswitch-users] Unpark call

[SamyGo]

*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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150728/87cd46f8/attachment-0001.html