At 01:26 AM 11/02/2006, you wrote:
Hi Roman,
> I have not influence on all possible providers, but I can modify
> GnuGK for better compatibility.
> I don't know which endpoint require this autodetection. If technical
> support starts to look into each case of "no voice" (it may be firewall
problem
> or codec incompatibility), we will loose too much time. So, each
endpoint may
> register on GnuGK from internet cafee or hotspot. How may GnuGK admin
> foresee these providers/endpoints?
> May be make liberal IP/port autodetection as option (on own risk)?
I agree that it is not feasible for support to analyze every case.
However, IMO you should understand what is happening in a few failing
cases before running off and writing new code. If Simon was correct
(and I was wrong) about the cause in your example, then a simple
configuration change at the softphone should solve the problem.
>
> SN> If your network includes Asterisk, an IAX softphone would avoid this
> SN> trouble.
> Ghmm. Is "openh323gk" dead project?
Of course not. H.323 will be around for a long time, and is a must if
you are dealing with the big telecom carriers.
However, most ITSPs dealing with residential and small business accounts
offer SIP as their primary or only protocol, because there is a huge
variety of ATAs and IP phones that use SIP and work well in diverse
network environments.
So who do the ITSP connect up to? The big telco carriers of course, so they
have to translate into H.323 anyway :) . You are absolutely right for
basic ITSP (termination not carrier) SIP is more widely adopted and I admit
better suited for basic simple internet phone operation.
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 Signalling)
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.
Also, more and more small and medium businesses are using Asterisk; the
IAX protocol avoids the problem you are currently facing, as well as
offering other technical advantages.
The reason for adoption by businesses? As I explained above, SIP just is
not up to it. But Asterix has 1 major flaw it is not standard but for
business it should be sufficient. I will point out that some of the none
core modules are not fully stable yet but I guess they will fix that. It
also is still not as scalable as H.323.
I don't know the nature of your business; perhaps offering the option of
connecting with other protocols will give you a competitive advantage,
as well as solving some technical problems. Of course, it takes a
lot of work.
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 Asterix. My bet is that in another 5
years H.323 will still be around and the Asterix people will be moving onto
something else. Open Source SKYPE clone perhaps :)
Some light reading on SIP
http://corporaterat.blogspot.com/2005/12/developer-perspective-painful.html
http://www.dailypayload.com/2006/0130.html
Simon
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________________
Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/
