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@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@gmail.com> wrote:
my idea in line.
On Tue, Jul 28, 2015 at 5:41 PM, Carlos Ruiz Díaz < carlos.ruizdiaz@gmail.com> wrote:
On Tue, Jul 28, 2015 at 4:30 PM, SamyGo <govoiper@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@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@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@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@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@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@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@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@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@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@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