Jungle + Jurijs, Thank you, the combination of the YT video and your description is exactly what I was looking for. So, in summation here, what you'd have is SIP Client ----> Kamailio ----> FS (contains a dialplan to bridge user/1234) ----> Kamailio ----> Other SIP Client Am I understanding correctly? I assume Kamailio would remove itself from the media flow in this case, leaving just Client --> FS --> Client for media transfer, right? It sounds like this still wouldn't remove the need for shared state management across the FS cluster, though. So, you'd have a Kamailio cluster backed by a database processing SIP registrations and location information, backed by FS with a shared database storing call state. This should allow the failure of either a Kamailio instance and/or FS instance and still allow the call to be recovered. It'll also allow you to offload all SIP registration to Kamailio and it's database, while leaving FS freed up for media/call routing. Does this sound right? This has been incredibly helpful, thank you so much. Best, Colin On Sat, Apr 16, 2016 at 5:19 PM Jurijs Ivolga <jurijs.ivolga@gmail.com> wrote:
Hi,
If Kamailio is the registrar, what role does it play in call routing? For
example, if a call hits FS and I instruct FS to bridge to a user, how is that performed? Or does all call routing now need to be performed on Kamailio, since it's the one that's aware of where users are (and their associated presence)?
You can configure Kamailio and Freeswitch in anyway you need, Kamailio can be call router, freeswitch can be call router and both of them simultaneously can be call routers :)
But if we will take following manual as starting point:
http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc
Then users location DB will be in Kamilio and information regarding users will be stored in Kamailio, so Freeswitch will not know where user located and all calls between extensions will go through Freeswitch and then will be looped back to Kamailio and Kamailio will decide where to route call.
So in this case Kamailio is call router and it decides where to route calls, for example 44 prefix is routed to "vbox"(voicemail).
Nevertheless you can add some additional routing on Freeswitch too if necessary, for example if you need to send calls to PSTN and you need transcoding.
Nevertheless it is still possible to route PSTN calls directly from Kamailio too, without freeswitch.
With kind regards,
Jurijs
On Sat, Apr 16, 2016 at 10:23 PM, jungle Boogie <jungleboogie0@gmail.com> wrote:
On 16 April 2016 at 09:32, Colin Morelli <colin.morelli@gmail.com> wrote:
To clarify, I'm just looking for pointers/references here. Although if anyone has some personal experience I'd greatly appreciate specific examples and insight as well.
This won't answer all your questions but it will give you an idea of freeswitch + Kamailio:
https://www.youtube.com/watch?v=6VsuC7-jHc4
-- ------- inum: 883510009027723 sip: jungleboogie@sip2sip.info xmpp: jungle-boogie@jit.si
_________________________________________________________________________ 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