Freeswitch and Kamailio roles in Kazoo
Ab Nazari
Darren Schreiber
Hi there,
So today, Kamailio sits in front of FreeSWITCH but is also connected to AMQP directly. FreeSWITCH is always ultimately in the signaling path, but that is actually about to change.
When you say “FreeSWITCH is in fact our full SIP stack which generates SIP messages and terminates them” that’s not technically accurate. We moved presence/BLF to Kamailio, and we moved registrations to our own stack and handle auth/challenge for registrations in Kamailio. In 4.0 we also handle the lookups of how to reach a particular endpoint in Kamailio, not FreeSWITCH. Finally, we don’t use the FreeSWITCH XML dialplan functions.
So, to be clear, you asked:
“In this topology, Kamailio is presented as the SBC. Does it mean it only passes the SIP messages to the Freeswitch and it doesn't directly connect to the AMQP or the eCallmgr?”
Kamailio does connect to AMQP.
Kamailio handles registrations in conjunction with ecallmgr (via AMQP) and the registrar app
Kamailio handles presence in conjunction with AMQP and the omnipresence app
Kamailio handles some call routing functions (like tracking when calls are on hold, park, etc. and maintaining associations with FreeSWITCH servers)
Kamailio handles endpoint lookups when bridging calls
And soon, calls which don’t require media will be handled with Kamailio entirely and bypass FreeSWITCH, so that FreeSWITCH is only used when a call may require media. This allows for a sort-of hybrid proxy + media gateway.
Hopefully I got that all right. James/Luis can correct any pieces I misspoke on.
Does that help?
- Darren
--
You received this message because you are subscribed to the Google Groups "2600hz-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
James Aimonetti
Hash: SHA256
In the beginning, yes, Kamailio was a lonely SBC, forwarding all SIP
traffic to FreeSWITCH/Kazoo for processing.
But that was a few years ago. Today, Kamailio handles much more itself by
connecting to AMQP (and by extension, Kazoo) for REGISTER, SUBSCRIBE,
NOTIFY, MESSAGE, and probably more that I'm not remembering at the
moment. These SIP messages don't hit FreeSWITCH at all anymore.
FreeSWITCH manages the INVITE dialogs (and RTP streams) for calls,
though even that will be muddied a bit when we finally rewrite the
trunkstore app into Kamailio.
Hope that helps clarify a bit.
James Aimonetti
Lead Systems Architect
"If Dialyzer don't care, I don't care"
2600HzPDX | http://2600hz.com
sip:ja...@2600hz.com
tel:415.886.7905
irc:mc_ @ freenode
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJYHLB1AAoJENTKa+JPXCVgFYgH/2vw89YoC4PpHT/sPqV3ClN+
zWcYY5X7ipnlocns4KlbU6O5iBzRyr0Dv/WofbMROukHWJag9flGNnFnrOJysOXd
jmB1yVpNi+WA/M1qXtAf7mJ/dqeS0OOA5C+BN04FznfuDs9M0v+bZ4mmY6fgIpKt
eHpcqQKot+FMzir+mP6fshIlNQfVdxnpc+aMAE6dnVz/SdGhz7c7bdmaHzgw9PJI
4p0XvgEFm2NcGmEhQBl27hVbya5zT3zrvpfCZGr1u+TbnpLEW0+k4xrGFDof1+j/
jD82FMlzzNClFAY2Wb5Nt/M8PraQmuVc+XjlPQ5KZsEN2DHe4Q4d6PcE3aAhyR8=
=oxvG
-----END PGP SIGNATURE-----
Ab Nazari
Darren Schreiber
Hi Ab,
See answers below...
From:
<2600h...@googlegroups.com> on behalf of Ab Nazari <aln...@gmail.com>
Reply-To: "2600h...@googlegroups.com" <2600h...@googlegroups.com>
Date: Saturday, November 5, 2016 at 6:48 AM
To: 2600hz-dev <2600h...@googlegroups.com>
Subject: Re: Freeswitch and Kamailio roles in Kazoo
Thanks Darren and James,
It's really great that you guys monitor this group and answer questions in details.
> We try! It gets very busy.
Now I do understand the current setup of the platform: Everything goes through Kamailio. It handles most of the messages by interacting with Kazoo through AMQP. INVITE in an exception and goes through Freeswitch because it's the basis of the route request/reply mechanism.
> That’s basically correct!
It seems Kazoo architectural evolution evolution is separating signaling from media and letting Kamailio to handle or SIP signaling and Freeswitch to handle media only. This will greatly improve security and reliability.
> Correct. In addition, it actually allows you to route calls without FreeSWITCH if the calls require no media, and minimal state tracking is done, so your CPS and max channels go up dramatically on minimal hardware
but I see two major issues. I haven't been able to find information how we can address these issues and I would appreciate it if you could point me to the right direction.
> OK
First since Kamailio will be involved in handling calls and tracking them and will have access to AMQP, it can no longer be considered an SBC. By that I mean it's not the best practice to expose such a vital entity. Do we need to have a separate SBC to protect the platform? I understand that it's not a shortcoming as many platforms rely on third party SBCs.
> I have to be honest, I think this is more of an opinion than fact or even best practice anymore. Once upon a time this was true, but I think it’s old school thinking at this point. We have over a half million phones now under management and I sleep pretty well with Kamailio at the healm. The extra layer of security in front of Kamailio seems unnecessary. We’ve already enhanced Kamailio to have DoS protection, flood protection, extra logging, and it’s more intelligent than a dumb SBC just sitting in front of the stack. One of the things I like most about having it in front actually is that it does excellent NAT correction, and the debugging is directly tied into the stack now – you can actually see recent BLF and other packets sent to phones and equipment as it leaves the network. It’s awesome. It reduces our support time dramatically.
> But by all means, if an SBC in front makes you feel better, you can
> Another route you could also consider if you’re really concerned here. The design is such that, in theory, you can put Kamailio in front of Kamailio. Our original design was that Kamailio would receive a packet and determine dumbly (and solely) if it was a NOTIFY/SUBSCRiBE/REGISTER/INVITE and route accordingly to ANOTHER set of Kamailio servers. We never got around to finishing that, so it might work, but I think it’s untested. But in that way, you could use the “front”/border Kamailio as an SBC and perhaps enhance it with some security, while still using everything else we have “behind the scenes”
Second, we do have high availability (HA) after Freeswitch and Kamailio because of the AMQP messaging. But as processing is moved to Kamailio (of course under the control of Kazoo), Kamailio HA becomes highly important as well. Do we rely only on SRV records to give us Kamailio HA? I ask this because SRV isn't good for real time HA and if one Kamailio goes down, usually associated active calls will go down (given the way many end points handle SRV records). Please correct me if I am wrong.
> SRV is an option, yes. To be clear, Kamailio is just signaling, not RTP proxy – RTP comes direct from FreeSWITCH. While this increases the edge exposure of your public IPs, it prevents calls from just flat-out dying if Kamailio goes down or restarts. If you fire Kamailio back up fast enough or fix the issue, nobody will notice and there will be no dropped audio. This was done intentionally. However, if you must guarantee that no SIP packets are lost and that nothing at all is disrupted, and SRV is not good enough for you, then you have an issue in fundamental networking not related to our product, which is that most customers sit behind NAT which tracks which port/IP SIP communication is happening on. The “replacement” Kamailio server you spin up or have “failover” must come from the same public IP. Thus, you MUST have some sort of network gear that can move the public IP over to a new source. And honestly that is an entirely different problem outside the scope of this project as it’s really SDN or fundamental networking (virtual Cisco IPs for example can be used here). If you want to get that detailed, this is where contacting us for consulting or any of those gear manufacturers makes sense.
> But out of the box, with the default architecture, calls will NOT fail that are already up, but new SIP signaling will fail until Kamailio is restored.
> Note that in our testing, SRV records have some delay but for handsets it does work. So combined with the fact that active calls don’t die, this actually isn’t as bad a solution as you’re making it out to be, but it depends on your risk tolerance level and SLA / Quality of Service requirements I guess.
With the new architecture, the combination of Kamailio+Kazoo is in fact an Application Server or Call Manager. It's acceptable for SBC to not have real time HA and usually they are reliable as they don't carry out complex processing. But I think for AS we need a good HA and I haven't been able to find out how to achieve that with Kamailio/Kazoo.
> I still think that’s overrated at this point based on our replies above, but I have 0 idea what your actual volumes, use case, etc is. So I can’t comment further than what I’ve listed above.
Thanks
On Saturday, 5 November 2016 01:50:07 UTC+11, Ab Nazari wrote:
Hi everyone,
I'd like to understand the platform topology before bringing up my first cluster.
From the documentation and Youtube videos of James and Luis, my understanding is that Kamailio is at the front end and receives the REGISTER messages. Also, Freeswtich is being used as the media server and eCallmgr is the call control entity.
Coming from Broadsoft and Cisco platforms, it's confusing that Freeswitch is being presented as the media server. From a call flow that was explained by Luis, it seems that every INVITE reaches Freeswitch which sends a route request to AMQP and waits for eCallmgr nodes to reply with a route response. Then it means Freeswitch is always in the signaling path. Am I right? Then it means Freeswitch is in fact our full SIP stack which generates SIP messages and terminates them.
In this topology, Kamailio is presented as the SBC. Does it mean it only passes the SIP messages to the Freeswitch and it doesn't directly connect to the AMQP or the eCallmgr?
I really I appreciate it if someone can explain these as I have spent few days going through the materials and I am out of resources to get a definitive answer.
Thanks
--
Ab Nazari
Darren Schreiber
Hi Ab,
“You mentioned that media wouldn't be lost as it doesn't go through Kamailio. I assume the media termination point in the platform is Freeswitch. Is that right? If yes, can we set the secondary IP address on the Freeswitch to be the media IP address? I would feel much better if I can separate signaling from media as much as possible (and also public facing interfaces from private facing ones).”
The term “secondary IP address” is foreign to me in this description. I think what you mean is RTP IP?
You can:
* Set Kamailio to be the only public IP open for SIP. Kamailio can then pass the SIP packets to FreeSWITCH over a private LAN
* Set FreeSWITCH to listen for SIP only on a private LAN
* Set FreeSWITCH to use a public IP only for RTP (I think this is your question?)
Additionally, you can:
* Have split networks. Some providers have private DSL VLANs hardwired to their customers and an interface on the Kamailio and FreeSWITCH box for that
* Specify different SIP/RTP combinations to use for outbound carrier traffic
* Specify different SIP/RTP combinations to use for outbound traffic to customers
Here is a picture of an EXAMPLE standard (not to be confused with required! This is just one scenario) deployment strategy:
To keep the project alive we are happy to provide paid consulting time to custom design the above for your needs to guide you, if you are willing. Reach out to me off-list if you are interested in assistance with that.
Ab Nazari
Darren Schreiber
Yes sir, that is possible. Sounds like we’re on the same page J
It is the great FreeSWITCH project which actually makes that possible natively though, we can take no credit!