On Wed, 08 Sep 2004 08:06:18 +0800, Leo Ann Boon <[EMAIL PROTECTED]> 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. _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users