Fortigate SIP ALG vs dedicated SBC

[James_G]

Our company wants to migrate our Shoretel phone system from ISDN to SIP trunks, our supplier is pushing us to implement an ingate siparator, of course it does because it adds £10,000 to the project cost!

From what I can see, our Fortigate 300D appliances will be perfectly capable to cover this requirement, the SIP ALG componant will manage all the NAT traversal issues and traffic inspection / IPS on the Fortigate coveres known security issues, added to the fact that in the policy I will only allow traffic to SIP providers datacentre (this is not to be used for our remote clients), I do not see where the possible risk could be. Seeing as both sides of the trunk will be using IP based registration, is there any real risk of hijacking?

From a performance point of view I have zero concerns, I have 300D units (mentioned above) that average 5% cpu and 50% memory usage, I also eliminate a SPOF with the single siparator as the Fortigate units are all active / passive HA.

Is there any real benifit to for me to spend the extra £10,000 on the ingate siparator?

[emnoc]

Depends so many things to over look

  How much SIP traffic

  Do you need encryption

  How many sip endpoints 

  Do you have concerns over  SIP registration

  Are you a call center of any shape or  fashion ( does your  business rely and function via call in/outbound )

  Do you have and dependability in the FGT300D and whatever FortiOS version

If you have a small footprint and SIP truck sizes under 30-50 simultaneous  callers, used the fortigate. If your a enterprise org with 2+ SIP providers 1000s of callers, get a dedicate SBc like Sonus or others.

In fact you might get two of them ;)

Ken

[James_G]

We have a small call centre, about 10 staff answering calls, and average(ish) 20 calls concurrent across business, although we will be going 60 channel sip trunk for flexibility. The sip trunk will be between 2 vm appliances and the sip gateway provider only, so guess you could say we are smaller, but on the other hand media encryption and service availability are critically important to us. I have been told our phone system and sip provider support srst for encryption, need to check that the fortigate can still handle.

[emnoc]

Now sure what "support srst" I guess you meant  SRTP? Either way, have you consulted with a SBC vendor to discuss your needs?

A firewall is not a SBC , just want to make that clear. The SBC offers numerous things in regards to call capacity and  function and other unified communications. I would consult with a vendor to have them analyze your needs. The  SBC can get pricey and a lot of max limits forcing a "forklift" once you out grow it's license limits.

You can a also do a opensource SBC if your talented and wanted to experiment. SBC was my  last usages they are good, but support does NOT want to help you in configurations so keep in that mine.

I would also  review your call needs for NOW and for later, maybe fortinet will come out with a fortisbc product but a domain name already exist for it ;)

I would also look at edgemarc if they are still doing  smaller  voip solutions. They are easy to manage, cheap, have a great name,  various solutions to fit the bill and then some. Just my 2cts and no I do work for them but have use them many years ago.

Ken

[cwillard]

I have a client who implemented a new phone system that uses an SBC. I am having trouble getting the FortiGate configured properly to work with this traffic.

Do you have an example configuration for use with a SBC?

I have tried disabling the SIP ALG and SIP Session Helper, but seem to have call quality issues. As is stands right now,

incoming and outgoing calls are working, but with extension to extension dialing the phone rings but neither party is able to hear each other.

[James_G]

In the end for me, all I did was create firewall rule with ALG and everything worked seamlessly, our phone system runs a vm inside the network that runs as a sip media proxy, so in the end traffic is only ever between sip supplier and the vm, I think this made the job much easier, but this is a feature of the phone system not anything I could configure. Handset to handset calls run past the media proxy vm and nowhere near the firewall.