> Okay, setting aside conspiracy theories, trolling, flaming, etc, let me > summarize some differences between SIP and IAX, and it might help you > make a decision about what is best for you.
brilliant piece. thanks! damned shame i cound not find it on google/wiki so i did not have to make so much confusion on the list. i suspect many will appreciate your posting it. being a big pipe backbone geek, i will spend bytes in exchange for ease of scalable deployment, security, simplicity, etc. but i do keep an eye on byte count, of only out of antique habits. and there definitely are applications, though not mine of the season, where byte count is darn near king, e.g., wireless, poor countries, ... as i was discussing in side email with a fellow user. [ but, as a backbone isp, i make money for delivering bytes, so maybe my black helicopter friend (who exceedingly mistakenly associated me with icann and other things) can think wasting bytes is a way for me to increase income:-). > 2) IAX is information-element encoded rather than ASCII encoded. i have always been of two minds on binary vs ascii. but, if efficiency is a major goal, binary does get a lot of weight. > 3) IAX has a very clear layer2 and layer3 separation oooooo! you know how to sell to an fsm and protocol freak. > 4) IAX's unified signalling and audio paths permit it to > transparently navigate NAT's and provide a firewal administrator > only a *single* port to have to open to permit its use. yes, if i was worried about nats i could not control, this would be a win. otoh, though not in my current game, i am one of those who worries about protocols being congestion friendly, especially as one approaches the customer edge. > 5) IAX's authenticated transfer system allows you to transfer > audio and call control off a server-in-the-middle in a robust > fashion such that if the two endpoints cannot see one another for > any reason, the call continues through the central server. s/off a server/through a server/ ? > 6) IAX clearly separates Caller*ID from the authentication > mechanism of the user. a win. but eventually the call gets to the damned edge, where all these kinky devices want fsk, dmtf, or tibetan prayer flags. end users and their bleedin' devices are the bane of the internet:-). > 7) SIP is an IETF standard. While there is some fledgling > documentation courtesy Frank Miller, IAX is not a published > standard at this time. in my current life, i am not all that impressed by something being a recent ivtf (sic) standard. but i have been there and done that. but i threw the plaque in the garbage. > 8) IAX allows an endpoint to check the validity of a phone number > to know whether the number is complete, may be complete, or is > complete but could be longer. There is no way to completely > support this in SIP. having had great fun with various dialplans and number sequence stuff on various kit, i can appreciate this. but it seemed as if most of the problems i ran into in this area were more device config design than protocol. > 9) IAX always sends DTMF out of band so there is never any > confusion about what method is used. cool. i did get caught by this recently. > 10) IAX support transmission of language and context, which are > useful in an Asterisk environment. not sure what you mean? end-user human language? hmmm. that may end up as useful in my current scenario. > That's pretty much all that comes to mind at the moment. not bad. and exceedingly helpful! owe you much sushi if we ever run into eachother. randy _______________________________________________ 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
