isen.blog

What do you mean by single hardware platform?

Is it the fact that it says "Linux PBX" on the Asterisk website which bothers you? If so, don't worry, because Asterisk runs on just about any Unix based system and Linux itself runs on a variety of hardware.

Or is it perhaps that Digium, the sponsors of Asterisk also sell their own telephony interface cards? Mind you, they made Asterisk to support competing telephony hardware, such as Dialogic, Voicetronix and Quicknet. Since it's GPLed open source, they can't really take that hardware support away from us, can they?!

So, I wonder what bothers you when you say single hardware platform.
 

It is the Digium connection that bothers me. But botheration is as botheration does. If the hardware support remains truly level-field, my discomfort about this disappears.
 

Is SIP fracturing to some extent? Apparently so.

Is this a big deal? Perhaps not.

The big point about SIP, to me, is that it (unlike H.323) was a standard that was finally compatible enough with PSTN to begin offering reasonable telephony services and allow a migration from PSTN to VOIP.

It's not surprising to me that SIP is fracturing; there will be demands to differentiate services based on SIP. That's no big deal to me as long as 1) There is the opportunity to "do it yourself" and not HAVE to use one of those "proprietized" versions of SIP, and 2) Can use Asterisk or other solutions to bridge between implementations of SIP. You already need to do this to some extent to bridge between incompatible codecs in simple, dedicated devices that you want to be able to communicate with each other.

Remember that SMTP, LDAP, and other wildly popular Internet standards were "backlash" reactions to overly complex implementations. Likely we'll see the same thing with SIP; my vote for nomenclature is LSIP - Lightweight Session Initiation Protocol. We'll need that for the coming generations of devices such as embedding voice handling in 802.11 and 802.16 wireless devices that will be forming up neighborhood-area mesh networks by the end of the decade.
 

David:

Any extensible protocol is over time likely to appear to become too complex.

The Internet family of protocols (thank god) is built to be extensible, it is very complex if you consider all the protocols implemented on the IP family, but it can be very simple if you use only the protocols that you need for a particular application.

Likewise, SIP extensions can be created for a multitude of special cases, as long as the basic call functionality is standarized, most SIP end devices will not need to support all SIP extensions, just enough for their intended functionality.

As long as all work is kept under standard bodies, and no 800 pound gorilla defines de facto standars with proprietary extensions protected by patents or copyrights, I do not mind the complexity.

Jorge
 

SIP doesn't *seem* so very complicated to me. Needing to have multiple codecs seems complicated. Anyway, if a $65 telephone sitting on my desktop, without a fan, and running off a little wall wart, can run SIP, then it can't be so very complicated.

No, David, more importantly than that, is the balkanization of SIP addressing. SIP seems designed around telephone *numbers*, and yet everybody seems to have to reinvent gatewaying into other telephone numbering systems. I'm like DUH, we already invented different numbering systems. You dial an international prefix, and you're into a different numbering system.

So, what I think VOIP needs is an independent party (cough Isen cough) with no axe to grind (cough Isen cough) and much respect in the post-Bellco community (cough Isen cough) to establish a numbering scheme so that anybody with a VOIP phone running SIP can call anybody else with a VOIP phone running SIP. Interoperability between every SIP phone seems essential if we're ever to give up our landlines. Don't worry if SIP isn't perfect. No standard will be perfect, because no standard will be the state of the art because every standard requires compromises.
 

Freshtel's Firefly Softphone www.freshtel.net
is built upon Asterisk/IAX.
 

The trouble with SIP is that it is not actually a complete VoIP protocol.

It only handles signalling, not voice. Voice is handled by another protocol, RTP. This odd design choice smells suspiciously of circuit switched networks, not anything we should expect from a protocol that is faithful to IP. This is what creates most of the problems with SIP, such as NAT traversal and firewall issues.

Unfortunately, this cannot be addressed by creating a lightweight version of SIP, not without breaking backwards compatibility anyway.

IAX on the other hand is a complete VoIP protocol, it handles both signalling and voice. And it does so in a manner that is truly faithful to IP. Signalling and voice are separated in the application layer, the way it should be.
 

In response to Russell and his comment about numbering schemes ...

There is already an internet standard that does exactly what you are asking for. It's called ENUM. It works by adding ordinary telephone numbers to your DNS zone file, in effect giving your DNS server the ability to translate your phone number into your IP address and vice versa.

A VoIP server, IP-PBX or IP phone that supports ENUM will then first try to find your IP address when somebody initiates a phone call to your phone number. If the ENUM lookup doesn't return anything, it will go ahead placing the call as usual via the PSTN. Otherwise it will place a peer-to-peer VoIP call.

BTW, Asterisk supports ENUM.
 

David,

the Digium connection need not bother you.

First, yes, there is a level playing field for hardware. And if there is any third party hardware support missing, then it is not because of Digium, but because the vendor doesn't want their hardware to be supported on anything other than their own product.

But this kind of attitude is changing already. Take Siemens for example. Two weeks ago they released a Linux and SIP based PBX ...

http://www.technewsworld.com/story/33710.html

"The box is based on a Linux operating system, a change for Siemens, which until now has used [] proprietary [] systems."

There you go.

Japan's NEC did the same last year and they were a closed shop before then, too.

Nobody can stop these vendors from using SIP because it is an IETF standard. But likewise, nobody can stop these or other vendors from using IAX or even Asterisk, because they are GPLed, not even Digium could stop them.

So, what else could Digium possibly do to abuse it's sponsorship status of IAX and Asterisk? Let's see ...

They could stop making any updates to drivers for third party hardware ... but because Asterisk is GPLed and there is a very active community, somebody else would then do it, no real harm done.

They could abandon Asterisk and make a new proprietary softswitch, but again the Asterisk community would simply carry on with Asterisk. It is not at all uncommon for an open source project to survive its original sponsor.

The only thing where Digium has a bit of a monopoly status in the Asterisk market is Asterisk's reliance on a clock sync signal on Digium's telephony cards because the hardware clocks found on PC hardware are not adequate enough for certain VoIP applications such as conferencing. Digium have provided a dummy driver for that which uses the clock the PC's USB controller, but again, the USB clock is not as good as the one found on Digium's cards. As a result, many of us who use Asterisk prefer to buy Digium's cheapest card for 99 USD for each Asterisk server we deploy, not necessarily we would need the FXO port on that card, but we want the proper clock reference the card provides to Asterisk.

I suppose Digium could raise their prices to the point where you could say that their are abusing their sponsor status. But Digium would be ill advised to do that because due to the fact that Asterisk is open sourced and GPLed somebody out there will then come up with an alternative cheaper solution.

In any event, this issue will eventually disappear with the Linux kernel v.2.6 which allows the use of the CPU clock signal (or more precisely, a fraction thereof) to be used as a clock reference for Asterisk.

As you can see for yourself, the best warrant for a level playing field is open source and an active community. That is precisely why so many IT vendors are embracing open source. It is also the reason why Microsoft doesn't like open source - they don't want a level playing field.

In any event, I don't think we have anything to worry about from Digium in this respect. If anything, Digium is IAX's biggest asset. I would be worried if Microsoft came along and make an incompatible version of IAX and Asterisk to swamp the market with before any other vendors have picked it up.
 

I fail to see the problem. SIP is getting a lot of traction. There is no reason to throw a cog in that wheel now. In its much shorter existence, SIP interoperability has already far exceeded anything we ever achieved with ITU H-dot specs. We have good choices in vendors with more coming on board every day. The SIP we enjoy today already is effectively SIP-lite in that nobody really implements the full spec (all the parts of the spec) but we still have pretty good interoperability. Thus we already have an 80/20 situation.

The separating of session signalling from media is a *GOOD* thing and I couldn't diasgree more with the poster that wants those tied that back together again. SIP is a way for end points to find each other and then establish whatever type of session they wish to establish. That is elegant and very useful, and powerful, far beyond voice.

The NAT problem has received a great deal of attention and effective solutions exist for many cases. The home/consumer case is essentially solved. Don't let vendors that don't know how to do it tell you otherwise.

David Beckemeyer http://www.toyz.org/cgi-bin/sipwiki.cgi
 

David - you are missing what is really important here. The bigger issue is not SIP vs IAX, it is open-source vs closed-source. Asterisk supports IAX (which was created for Asterisk), but it also supports skinny and SIP. Like the Cyrus IMAP server which supports both the POP and IMAP protocols, Asterisk will support whatever protocols people want to use and the best protocol will rise to the top in the long run. Thats what happens in open-source ecosystems.

As such, Asterisk represents a sort of 'meta-protocol', and the choices that people make in meta-protocols matter much more than the choices they make in protocols. The fact that Asterisk is GPL-ed is key. (My company is currently moving from Cisco's IP-PBX software to Asterisk. We love Asterisk.)
 

In response to Davind Beckemayer ...

The concept of separation of signalling and voice itself is not being questioned but the way in which this concept is implemented. Like it or not, but the way in which SIP implements this concept breaks the most important internet paradigm.

TCP/IP (and by extension the internet) is based on the concept that traffic can be routed between any two end points without knowing anything about content nor structure of the data that is being passed. David has paraphrased this paradigm prominently as "the stupid network" since the intelligence is at the edge of the network, not within the network. The way in which SIP separates signalling and voice breaks this paradigm and that is the issue.

NAT traversal is only one of a number of problem areas that come out of this. Indeed, there are quite a number of approaches to deal with SIP's NAT traversal problems but they are all dirty hacks and workarounds, not what you could reasonably call a solution. Since the problem goes back to a design choice that is not faithful to the intelligence at the edge paradigm, it is highly unlikely that there will ever be a real solution. It is one of those things where you have to accept that they are fundamentally broken and cannot be fixed.

Make no mistake, IAX separates signalling and voice, too. However, the implementation is faithful to the intelligence at the edge paradigm.

This is a very important advantage to have and for this reason, we can expect to either see IAX become more widespread or other yet unknown VoIP protocols to emerge which also separate signalling and voice in a manner that is consistent with the intelligence at the edge paradigm.

You may argue that it doesn't matter whether a fix is a dirty hack or workaround or a proper solution. However, this is not a matter of beauty. The way in which SIP's NAT traversal issues are dealt with are not only ugly but they are expensive and most of the time they introduce other problems, which then need dirty hacks and workarounds again.

Why is it that SIP providers with large user bases run mindboggingly expensive Jasomi gear just to fix what's broken with SIP? If SIP was such a good idea, this wouldn't be necessary.

For a provider offering VoIP as a universally available ubiquitous consumer service it is very important to be able to make certain that no matter which environment any given customer may have, they can use the service without neither provider nor user having to make an effort.

After all, what we are going for here is to replace the exiting circuit switched network completely with an end-to-end packet switched one. Certainty, predictability and cost effective customer premises deployment is key to that.

With SIP, that certainty and predictability is not there. A lot of it has to do with SIP breaking the stupid network paradigm. There are different types of NAT, various implementations of those different kinds of NAT and depending on which customer premises equipment you have some of the known workarounds may work, others won't work. You can never tell until you have actually tried it out. This is support intensive and a clear obstacly to universal service. SIP doesn't cut it.

You may think I am exaggerating this, but I was myself surprised to learn how significant it is. My brother in law works as a salesman for one of the major telecom manufacturers and they build and support SIP networks for carriers and internet telephone service providers. He told me that for each piece of end user gear (ie SIP phone or ATA) they have deployed to various customers there is a percentage of cases where the gear simply cannot be made to work and will have to be returned. They also have a hopeless case ratio where no SIP service can be provided at all, and currently this is well above 10%.

I don't know how this will translate into support cost in terms of dollars or percentage of revenue, but it is rather obvious that the cost will be significant, thus creating pressure in the market of solutions which do not have the problem. It's only a question of when, not if. Besides, since VoIP aims for universal service it is quite obvious that this isn't good enough as it is.

You may argue that NAT will sooner or later disappear as everybody will migrate to IPv6. But if history is anything to go by, TCP/IP in its current form will be with us for a long long time while VoIP protocols are rather shortlived, especially ones with design flaws. So, if I have to make a bet, I'd put my money on IPv4, not on SIP.

Then again, NAT traversal isn't the problem itself, it is a symptom of the problem. SIP has the very same trouble with ordinary firewalls and intrusion detection systems. It is not a solution to punch holes into firewalls, especially not in a world where cyberspace security is becoming more and more challenging. And firewalls which have to learn protocols and interpret them in real-time mean increased cost again, not only in hardware terms but also in terms of development, maintenance and support. That's one of the main reasons why we have been doing so well with the stupid network paradigm.

Then, this is also a pandorra's box. Imagine how many new network applications there are and how many more to come. If this protocol-aware firewall and router approach is to become a trend, how many protocols do you want your firewalls and routers to have to learn and keep up to date about. Sooner or later you are going to hit the wall and another truly stupid network which can do without such nonsense will be cheaper and replace all which has been built upon the current semi-stupid network we call the internet.

If we let SIP get away with it, there will be more and more protocol designers who don't want to do their homework properly and disregard good design guidelines. If we don't put a stop to that voluntarily, then the IETF or the market will eventually enforce it.

In this respect, I think David's analysis is correct. In order for VoIP to go mainstream as in universal service for everybody, it will have to be truly plug and play without any uncertainty whether it will work or not no matter what end user gear the customer has chosen. This is how the analog telephone works, this is what John Doe and Jane Smith will expect. True, SIP has given us a taste of how this would feel since it has made headway in inter-operability, but it won't be able to go all the distance for the reasons outlined above (and others).
 

Where are you getting this idea that SIP violates the end to end paradigm.

Folks, I like Asterisk a lot, and it is very cool, but it is not a replacement for a public SIP infrastructure. It is a PBX. It is an answer to a different question. Asterisk frames all problems in a certain context so people that mostly use Asterisk believe all problems can be framed in an Asterisk view and therefore Asterisk solves all problems.

This discussion is scary and a big threat to the progress of VoIP. We don't have the time or resources to fragment the industry (again).

SIP is moving forward. It's operational characteristics are improving. It's still early in SIP's deployment cycle and it is only getting better in practice. Let's let the vendors continue to improve it rather than pulling them in five different directions.
 

Digium deserves to get weathly on Asterisk and IAX about hundredfolds more than Redhat deserved to get rich off of Linux. Digium has done more for IPTel than Cisco at this point, IMO.

I suggest you purchase their top-of-the-line equipment and donate heavily. Purchase some Asterisk t-shirts and stickers. This negative tone about Digium has made me cry, I hope you are happy! :>

I'm thinking of buying massive quantities of IAXy's when they ship and just give them out to family and friends. I bought Digium's new FXO module just to support Digium and the technology. I could have bought an FXO port (i.e. Digium replica) from DigitNetworks.Com for $14.50 instead.

Did you know that the IAX/IAX2 specification is a non-standard, but open protocol spec with an open sourcecode base?

I also heard that Virbiage/FreshTel's Firefly software (the only currently available Windows-based IAX softphone) no longer interoperates with other systems. Shame on them, if that's the case. If they are going to release the first hardphone with IAX support, I sure hope that it will work with any Asterisk PBX or VoIP provider. And what's taking them so long?

Websites like IAXTel.Com and IAXProvider.Net show that IAX is not just a passing phase in the cycle of VoIP. The VoIP-Info.Org website lays out the strengths Asterisk and IAX. E164.Org was built primarily to support Asterisk, and they have done a greater service by promoting non-Asterisk applications with Like2Fone.Com.

People are already integrating applications like Asterisk and RT or Asterisk and Nagios. SIP may be more HTTP-friendly, but Asterisk/IAX are more IPTel-friendly.
 

>Where are you getting this idea that SIP violates the end to end paradigm.

It's very obvious. The paradigm says that you need no intelligence within the network other than looking at the wrappers of the packets sent into the network in order to route them accurately to any end point.

With SIP, you need more intelligence than just looking at the wrappers/TCP hearders in order to route everything that belongs to the data stream to *any* end point. You need SIP aware routers to accomplish that. This protocol aware router trend is clearly running counter to the paradigm.

Of course we could start splitting hairs and you would claim that SIP packets mostly get where they are supposed to and that only the RTP packets don't, so its an RTP problem, not a SIP problem, but since the result for the end user is that the application is broken when this happens, it doesn't really matter, does it. But hey, let's just rephrase the statement which was made. The formula SIP+RTP as a solution for VoIP does indeed break the paradigm, even though SIP alone (without payload) doesn't, but what good does it do without the payload in the first place?
 

Nobody said Asterisk was a replacement for or an alternative to SIP.

What was said is that IAX was a potential candidate for a future mainstream VoIP protocol that could speed past SIP in the universal service space. But that's IAX, not Asterisk. Don't confuse the two. One is a protocol, the other a VoIP solution which uses the former (amongst others).
 

>If they are going to release the first hardphone with IAX support, I sure hope
>that it will work with any Asterisk PBX or VoIP provider. And what's taking
>them so long?

Hahaha. They are in Melbourne, Australia, mate. Folks in OZ are a bit more relaxed about work and timing than in many other places.

But, seriously, they are building an entirely new phone and this is bound to take more time than you are likely going to anticipate. Take those FarFone folks and their effort to make an IAX hardphone. They are very enthusiastic about it and I am sure they know their trade, but still they haven't been able to get to production stage as fast as they hoped they would.

The fastest approach to getting an IAX hardphone out to market is to convince a company which makes IP phones (for example SIP phones) to make their firmware support IAX. This is not as difficult as it would seem because IAX is really very lightweight compared to any other VoIP protocols out there.

My company has been lobbying some IP phone manufacturers for some time with the idea to make IAX firmware for their phones and we have actually managed to get one manufacturer to write IAX into their current firmware. We were surprised how fast they could do it, but of course this will need some testing and likely some finishing before it can be released.

I can't reveal much more right now, but I believe that those guys have the best chance to be the first to market with an IAX hardphone. And the phone is quite nice, too. And even if they're not first, there'll be choice. So if the Ozzie phone won't be quite so IAX compatible, the one I am talking about certainly will be.

If you want to do make a contribution yourself, do what we do. Always bother your phone suppliers about IAX firmware. Always tell them how much better it is and how easy it would be for them to sell to the Asterisk using community and how the community is growing.

The more people bother phone manufacturers about IAX, the more likely that some of them will eventually look into IAX firmware for their phones.
 

Threat? Fragmenting the industry? by pointing out flaws in SIP?

Most carriers who run VoIP backbones use H.323, not SIP.

The world's largest peer-to-peer VoIP subsriber network, Skype, is using its own proprietary protocol, loosely based on SIP, but not SIP.

The world's largest commercial VoIP subscriber network, YahooBB in Japan, is using MGCP, not SIP.

The biggest and most visible VoIP vendor, Cisco, is touting its own SCCP, not SIP.

The industry is already fragmented and while SIP has made some headway, this is by no means the last round in the tournament.

At the end of the day, the market will decide what works. And quite often the market has decided against large scale committee negotiated standards no matter how much effort went in to them and no matter how much touting there was for them.

Remember OSI? Another one of those much anticipated, much touted but failed egg-laying-wool-milk-sau projects put together by large committees. SIP may yet share it's fate, only time will tell.
 

Wow. I am just totally flabbergasted by Anonymous's comments about NAT traversal. Dude, you have no clue. NAT and UDP do not work well together because there is no such thing as a UDP session. In order to have incoming UDP packets directed to the correct machine -- regardless of the protocol -- you need some kind of NAT traversal algorithm. SIP is not unique in any way in this regard. Now, you can use TCP -- and Skype does, if nothing else works -- but TCP sessions are reliable, not real-time. Packet loss is interpreted as congestion, and the packet transmission rate is slowed. You can only use a TCP session for voice if you have a connection with zero packet loss.

So, I really don't know where you get off saying that SIP has a problem with NAT traversal. It's UDP (and hence RTP) that has the problem.
-russ
 

re: Russell

The question of how significant it is whether SIP or RTP is having the NAT problem has been addressed in the post you commented on.

The OP said it didn't matter which protocol you blame it on, that the only thing that mattered was the end result. This was also the tenor of David's blog and I'd have to agree with that.

You can't deny that SIP/RTP based VOIP has a NAT and firewall traversal issue.

Ever tried to run a SIP service behind a firewall, or behind NAT? What about establishing a call from one NATed SIP phone to another NATed SIP phone? What about a SIP client behind multiple levels of NAT?

When we are talking about replacing the PSTN with VOIP everywhere, as opposed to VOIP being a niche product alongside the PSTN, then those issues will indeed weigh heavy.

All that was said was that STUN servers, border gateway controllers and SIP aware firewalls are not ideal solutions and that they can be rather expensive. Again, I'd have to agree with that.

If there is indeed another VOIP protocol out there that offers a clean and cost effective solution to those issues, we should welcome it and not try to engage in the very same home turf protection the anti-VOIP league is currently displaying.

Pointing out weaknesses in current standards and practises is never a bad thing for it will lead to the changes needed to solve issues, one way or the other.

Whatever it is that's challenging SIP, if it is really good, it will be to the benefit of VOIP, and if it isn't good enough it will fail anyway. So, what's the trouble?
 

Re: Anonymous's comments:

Replacing SIP/RTP with another protocol that uses UDP does not solve a single one of the problems. The general tenor of the comments seems to be "SIP is bad! Throw it out! Replace it with something else!" That's a complete waste of time, though, since none of the actual problems can be solved by any other protocol. It's like the old story about the drunk who's searching for his car keys underneath the streetlight "because the light is better here."

Pointing out that SIP has problems getting through firewalls and NAT routers is pointLESS. Anything *else* would also have the same problems. So why criticize SIP? I just don't get it.
 

Hi Russell

In a nutshell, your statement "none of the actual problems can be solved by any other protocol" is simply incorrect, but I will get to that later.

First, let me introduce myself and give you a little background info. I am the guy who indirectly started this discussion by introducing David to IAX and Asterisk some months ago, my name is Benjamin. You can still find a related entry on his blog in the archive.

Since then, I have introduced David to Mark Spencer, the original author of IAX and Asterisk. Further I told David about our own experience implementing VOIP solutions in Japan where NAT is the norm and in developing markets where government imposed firewall rules are very strictly enforced and latency is often a big problem. In other words, challenging environments.

At the same time David has been talking to people who I would at this point simply describe as "SIP celebrities".

Mark has given David an outline of quite a number of problems with SIP that are design inherent. Most of these were pretty technical. Perhaps a little too technical for both myself and David to comprehend. But take into account that Mark is a guy who has actually implemented SIP in addition to his own VoIP protocol IAX. He is involved with SIP implementation, debugging and code maintenance on a daily basis. In any event, Mark knows what he is talking about. He is a well respected figure in the VOIP community.

The outcome of all this is that David's view of the situation has come to be that SIP's major problem is its complexity and any issues can be traced back to that. Apparently, the afore mentioned "SIP celebrities" have pointed in this direction.

Mark and I had taken the view that complexity, while significant, is not SIP's biggest problem. We gave examples of real world scenarios which SIP simply cannot cope with due to design issues. IAX handles any of those situations.

I think Mark won't mind if I quote one of his examples here ...

"the lack of any sort of layer-2 concept with SIP. If you, for example, setup a call, place it on hold, then remove the phone or power cycle it, effectively there is no way to know that call has terminated."

Then there is of course the famous NAT and firewall traversal issue. SIP's reliance on RTP is a major handicap here and replacing SIP with another protocol that doesn't rely on RTP can indeed avoid the problem in the first place. IAX is proof for that. If you don't believe it, download an IAX softphone or Asterisk and see for yourself.

I would like to emphasise that this issue is not limited to NAT. I have customers who are ISPs in countries with restrictive government imposed security policies. There is no NAT involved but firewall rules which all too often make the use of a SIP based VOIP solution beyond the boundaries of a single ISP impossible. From a security point of view many of those policies are good policies. Again, IAX has been the universal answer in every single case where we have encountered such an environment.

We are engaged in a pilot project in such a market, where the customer has sent Cisco packing because they were unable to establish any voice connectivity whatsoever. We walked in there with our IAX setup and everything worked out of the box, much to the amazement of the customer's engineering staff.

There are also reliability issues. We have customers in developing countries who are struggling with the substandard quality of the local infrastructure. Connectivity so bad that even email and web browsing is a challenge. Latency jumping up and down rapidly but over a wide range, massive packet loss, routes jumping all over the place etc. They may not be able to send email from where they are when their ADSL link goes down and the router switches over to dialup on a pathetic analog telephone line, but using IAX and ILBC, they will always be able to make a PSTN quality phone call.

IAX has never failed to amaze both us and our customers in such environments. Today I am as confident as to reassure any customer in a third world country ... "Don't worry about the quality of your internet connection - If nothing else works, IAX will." and I can back this up with real world installations.

Is this only because we wouldn't know how to make SIP work? Not so. Before we get those jobs, our customers had already challenged major VOIP players who ought to have the talent and the expertise to make it work for them - still those big guns couldn't make it work. IAX always could.

When I first stumbled into Asterisk and IAX, I was as skeptical as you are now when I read Mark Spencer making such statements as "We want Asterisk and IAX to become the Apache of the telephone world". I thought, hey, typical case of setting your goals way beyond what you could possibly achieve, he's a bit crazy. Today, I know I was wrong and Mark really does have a contender for setting the "Apache standard" of telephony.

And it is not just small companies like us who have discovered Asterisk and IAX as a competitive advantage. There are more and more telcos and VOIP service providers choosing Asterisk and IAX. Try it out for yourself. Chance is you'll become one of its advocates ;-)

regards
benjamin

PS: I am happy to engage in a discussion by email if you wish. My address is in David's blog archive.
 

Let me give you guys another example ...

How many times have you had a VoIP call disappear on you and you were not quite sure whether to hang on there for a while or hang up?! Then when you check your billing statement, you see that the call was still being charged even after you hung up already.

Funny thing is that this always happens with the SIP providers out there but I have never seen this happening with any IAX provider and I have tried many. This is another of those signalling still intact, voice long gone, no way to tell if the call has terminated stories, like the one mentioned, but more severe because you are paying for a call that is no more.
 

I know I'm the wrong David for the offer, but I'd very much like to see Mark's SIP points as well. My email is david at bdt.com and you can find out more about me at http://www.bdt.com/david. I spoke at Spring VON 2004 if you caught me then.

That's a good point you make about IAX being separate from Asterisk. It is easy to blur them.

I have wrestled with SIP for at least 4 years now at a very deep level, and I have many times cursed the inventors over its (often inane, IMHO) complexity. At the end of the day however, it is a standard unlike any of the others mentioned (MGCP, H.323, Skinny, etc.), designed for a much grander scope

I'm sure one could come up with a set of cases that SIP supports and IAX does not, but that's not really the point.

Speaking of Asterisk, again, one cannot give Digium enough kudos for it, and it is an amazing tool, but unfortunately Asterisk's SIP implementation is not very protocol compliant so it is no wonder that a lot of people that only know SIP through Asterisk presume SIP is horribly broken. But again, Asterisk is a different question (I mention it mostly now just to vent as Asterisk's SIP implementation is torturing me to an intense degree at the moment).
 

You may well be right that many Asterisk users judge SIP through Asterisk's rather problematic SIP implementation.

Then again, how many SIP implementations have you come across that are not broken? It is yet another indicator of SIP's poor state of affairs that so many implementors struggle to get it right.

But even if we disregard this, you will have noticed that I made it clear that my being critical of SIP is not based on my own efforts with SIP but on the inability of major vendors to compete against IAX with their SIP based solutions in what I called challenging environments.

Those are vendors who have the resources and the know how to make it work. If they can't make it work and we can using IAX, that is a significant blow to SIP indeed.

On the one hand this means that IAX is an equalizer like the web. Even small companies can get a chance at doing bigger business.

On the other hand it also means that those vendors are unlikely to continue taking a hit by using the wrong tool. They are not stupid. Once they figure out that there is a significant competitive advantage in using something else, they will drop SIP like a hot potato.

I was told about an effort under way towards a draft RFC for IAX presumably with the aim of eventually submitting it to the IETF. If IAX was to become an official IETF standard, I could well imagine it becoming as popular and widespread as SIP is today.

Of course, we don't know what else is out there. Just like those SIP folks who are taken by surprise now when told what IAX does, we may see some yet unknown protocol to emerge as the future champion.

regards
benjamin
 

PC Magazine just did a great article on Asterisk.
http://www.pcmag.com/article2/0,1759,1607896,00.asp

craig d
 

Benjamin -

I'm reading the comments you wrote years after you posted them and you're full of yourself. SIP and quality SIP implementations are on the rise and IAX2 still has no real penetration beyond PBX installations.

-J