[Asterisk-Users] Re: Re: iax or sip

[Randy Bush]

> 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