[Asterisk-Users] iaxy vs sipura

Tue Sep 7 22:34:32 MST 2004

On Wed, 08 Sep 2004 08:06:18 +0800, Leo Ann Boon <leo at innovax.com.sg> wrote:
> 
> Benjamin on Asterisk Mailing Lists wrote:
> 
> >I have been travelling a lot on all inhabited continents, using hotel
> >provided internet connections, internet cafes, client's office LANs,
> >hotspots in public places, cafes, airports etc etc.
> >
> >The most common experience is "SIP doesn't work at all" and the second
> >most common experience is "SIP only works after messing around a lot".
> >Even if you get SIP to work, you are likely to spend so much time on
> >fiddling with settings that it has a negative impact on your schedule.
> >
> >
> >
> Not so true. If you can use a SIP ALG (or far end NAT traversal device
> like Jasomi), it will pretty much make the config problems 'disappear'.

If I had the money to afford Jasomi gear, I wouldn't care about the
phone bill I clock up in some hotel. In fact, I could spend hours
talking on the outrageously overpriced GSM roaming service and it
would still be cheaper than buying Jasomi.

Besides, NAT is not the only trouble you will have with SIP when you
travel to non-OECD places. Jasomi does nothing to get you past those
other hurdles.

> I've had very good results using SER with nathelper module. My setup-
> SER handles the NAT traversal and external extensions while * handles
> the office extensions, voicemail and PSTN gw. So far, I have yet to
> encounter a scenario that doesn't work with this setup. Most of the
> time, my colleagues can walk into a customer's premise, turn on the
> Cisco ATA and viola - they can call the office or make PSTN calls.

All depends on where they are going. I could send them on a month long
trip where they never stay in the same place twice and they wouldn't
get it working once.

I have spent hundreds of hours in third world environments trying to
get VoIP connections going from ad hoc offices, public places and
customer premises. I am not talking from the convenience of my first
world infrastructure home or office theorising about why things should
work overseas in less fortunate places. I have actually been to those
places and the experience is precisely like I said, no buts and ifs
whatsoever.

Let me give you some examples ...

I have been to hotels which had broadband in the room and I paid so
much extra for that broadband room that it really didn't make sense
because I wouldn't have been able to make up for the extra cost by
saving on phone calls. However, I paid for it because I wanted to try
it out.

In many of those places, you will find yourself behind two levels of
NAT. It is also not uncommon to find that they block ports you need or
they reset their routers periodically every 60 seconds.

For example, many hotels in Hong Kong use a provider specialising in
serving hotels and they reset their routers every 60 seconds probably
to prevent customers from watching video streams or making VoIP calls
because the hotels want to make money on their inhouse services.

As you would expect, any services orther than HTTP will be severely
impeded. SSH sessions will freeze, tunneling is out of the question
and ftp downloads are problematic.

Yet IAX connections survived this ordeal usually 15-20 times before
the connection terminated. SIP connections never did. In other words,
your SIP call will last exactly 1 minute while you can talk about 15
to 20 minutes on an IAX call.

And you ain't seen nothing yet if you haven't been to the Middle East
and Africa.

I was in Saudi Arabia for one of the main ISPs evaluating their
options for running a domestic-only VoIP service, so I am not talking
about sitting in some hotel trying to make things work on a badly run
dialup service.

All ISPs in the KSA go through the national internet backbone which is
run by the government and like all things there it is heavily
restricted. Traditional VoIP won't work unless you get the government
backbone to co-operate. For that to happen, you'd probably have to get
an invitation to install a system for the royal family. Yet, there is
a rather simple trick how you can get a connection going using IAX. I
won't reveal this here though for obvious reasons. All I can say is
the same trick will not work for SIP. Oh, BTW, tunneling is a no-go
there, too.

Another interesting environment is Egypt. Things are not restricted
there as they are in the KSA, but the infrastructure is mostly
unsuitable to do VoIP. ISPs in Egypt are very inventive to overcome
the lack of resources they face. You will find this kind of
inventiveness in many third world environments. Unfortunately, the
things they do will pose challenges that SIP simply cannot cope with
in a reliable fashion.

The observations you make on Egyptian internet connections are so
weird, so plenty and so random that it is impossible to present even
only an outline within the scope of a posting like this. So, I will
keep this short and just give you a minor non-representative but easy
to describe example:

I was doing some troubleshooting of an IP connection between Cairo and
Alexandria, the two major cities in Egypt, only about 200 km apart.
The first surprise was that traceroute showed the connection was going
first to the US via the UK only to come back to the UK and then back
to Egypt via Turkey. The next surprise was that no consecutive
traceroute would show the same route. Every time the route was
different, often jumping in and out of third countries. The latency
was going up and down like a rollercoaster. Depening on the route, RTP
would pass through or not and what have you not.

In other words, when you see those things happending in front of your
eyes you are just about to give up and say "There is NO WAY I am going
to get any VoIP connection going over THIS". And, indeed, the
connection barely delivers anything other than ping and traceroute.

I am always as surprised as anybody else to see that IAX can cope with
such challenges. IAX never fails to amaze me. Everytime I run into
another outrageous situation, I think "This is it. This time it won't
work. No chance." and everytime IAX proves me wrong.

These are just a few examples out of many places I have been to in
this region and other regions. They are representative in the sense
that the real world out there is far more diverse and throws problems
at you that no theorising from the comfort of an OECD country with
excellent infrastructure could possibly foresee. You have to acutally
go out there and visit these places to see for yourself that SIP is
not a universally suitable instrument.

You may say this is all just because I don't know how to make SIP work
and I will give you this: I have come to not bothering with SIP
anymore if I can use IAX and that means I spend much less time on
troubleshooting SIP these days. But even if we assume that I don't
know anything about SIP, then it is still going to be a testament for
IAX' reliability, robustness and user friendliness because I didn't
know anything about IAX at the time I ran into these problems either.
Yet I was able to get IAX working where SIP didn't work and I spent an
order of magnitude more time on troubleshooting SIP than I did on
setting up IAX in its place after giving up.

Keep in mind though that I have been working with engineers on the
ground who know a lot more about SIP than I do and quite a few of them
know at least as much as the resident SIP gurus on this list. Often
they are trained by the big names in the VoIP industry or they are
ex-Cisco engineers etc. If they can't make it work with SIP and I can
with IAX, again it is a testament to IAX' reliability, robustness and
user friendliness.

Besides, we were talking about "configure and forget". All I said was
that if you venture outside of the US, SIP will not be "configure and
forget" where IAX will be.

rgds
benjk
-- 
Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya,
Tokyo, Japan.

NB: Spam filters in place. Messages unrelated to the * mailing lists
may get trashed.