|
|
GNU Gatekeeper and SIPCan I use a SIP Phone with with GnuGk ?Since H.323 and SIP are incompatible Voice-over-IP protocols, you can't use SIP phones directly. However there are gateways that bridge between SIP and H.323.H.323 / SIP GatewaysAsterisk (OpenSource Linux PBX that supports both SIP and H.323), also see the notes on using Asterisk as H.323 / SIP gatewayYate (includes SIP to H.323 translation) FreeSWITCH (OpenSource soft-switch including H.323 to SIP conversion) Will SIP take over and will H.323 die out ?Probably not. While SIP is very strong in the consumer market, H.323 has a very strong position in the telco market. Both for good reasons.Here is a quote from Simon Horn on the GnuGk mailinglist in February 2006: [...] Why haven't the major telcos switched to SIP? 2 reasons 1. LRQ There is no equivalent in SIP. You cannot deploy a large SIP server farm network anywhere as efficiently as huge H.323 GK hierarchy 2. ISDN (Traditional Phone network). ISDN is H.320 and is designed for and is far more compatible with H.323 However I will point out that H.323 does have better NAT traversal capabilities (actually it does) and GNUGK NAT traversal method is far better than anything capable in SIP and even within the ITU standard H.460.18/19. There is also the ability to just simply port forward the required ports in the router, this is more problematic is SIP.. The reason, basically the design of the protocol, In SIP the receiving and sending ports for RTP must be the same which means that port translation in symmetric NATs (more than 50% of the market) is a major problem so STUN becomes basically useless, you have to revert to ICE which requires up to 10 extra messages to traverse the NAT which does take some time to negotiate and for business needs it becomes unusable. This is why your ITSP insists you buy an expensive box to connect your phone to :). The GNUGK method uses 0 extra messages and instant.. Though I will point out that some SIP servers such as SER do support a method similar to GNUGK but not as efficient Another major problem is securing SIP. I have spent quite a bit of time looking at porting our security ideas to SIP and have come to one conclusion, it can't be done without upgrading an entire Network to support it. The basic problem is. 1. Lack of a dedicated End-to-End Calling channel (H.225.0 Signaling) which makes it Impossible for 2 parties in a call to authenticate each other directly. You need to rely on the servers and things like SIP Identity (which requires 6 extra messages and can take up to 2 sec just to identify the callers). In H.323 you just add a cryptoToken in the H.225 Setup message and your done. No extra messages, almost no extra delays) 2. Lack of a equivalent H.225 Call Proceeding Message which means its impossible to do the encryption setup before the remote party rings. Which means that you have up to 3 sec of 'Dead Air" when you pick the phone up. For business this is unacceptable. They also cannot agree on which SRTP method to use MiKey or sdesc so a lot of these secure phones/networks can not interperate. In H.323 you can setup an encrypted call in under 400 ms and it will be 100% interoperable with almost every piece of legacy H.323 equipment. In SIP you have to upgrade everything. If you pick the wrong method MiKey or sdesc you may have to do it twice. :) My point is from a programmers/implementation point of view H.323 is still the only complete solution. Yes SIP is very good in it's box but outside it it's not as good and for large scale business needs its not quite up to it. [...] SIP is 10 years old, 5 years ago they were saying H.323 is finished SIP will rule, well its 5 years later and H.323 is still here and the people who were saying that are moving onto Asterisk. My bet is that in another 5 years H.323 will still be around and the Astrix people will be moving onto something else. Open Source SKYPE clone perhaps :) Some light reading on SIP http://www.dailypayload.com/2006/0130.html Simon LinksSIPfoundryH.323 / SIP / Skype marketshare Directory of SIP software (German)
|
|
Last updated: 15. Mai 2011 Page maintained by Jan Willamowius |