On Mon, 5 Jul 2004 13:11:10 -0700, Randy Bush wrote:>i am looking at iax to see if it is applicable to my needs. i >would appreciate any corrections of what i think i have understood >but probably have not. > >iax uses udp and traverses nats. neither of these seems useful to >me. i loathe nats, and udp is not well-behaved in the sense of >congestion avoidance.>trunking will save some bytes in flight iff one has four or more >streams moving between two pbxes. but who would want to have the >pbxes in the data stream anyway? reinvite rules, especially in a >geographically distributed use scenario.If you are using an IP/AIX based termination provider then trunking makes great sense. Even in my situation with only a handlful of desktops I see enough activity to know that I'm saving bandwidth with trunking to my termination provider. Michael>now, i could see a network of iaxen if there was some way to >negotiate call routing with costs etc. but trip looks a bit ugly >and kinda far away. and it certainly is not part of current play. > >what am i missing here? > >randy > >_______________________________________________ >Asterisk-Users mailing list >Asterisk-Users@lists.digium.com >http://lists.digium.com/mailman/listinfo/asterisk-users >To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >-- Michael Graves mgraves@pixelpower.com Sr. Product Specialist www.pixelpower.com Pixel Power Inc. mgraves@mstvp.com o713-861-4005 o800-905-6412 c713-201-1262 "It's the end of the world as we know it. I feel Fine." - R.E.M. ** Tag(s) inserted by Bandit Tagger98 - http://www.gbar.dtu.dk/~c918704
i am looking at iax to see if it is applicable to my needs. i would appreciate any corrections of what i think i have understood but probably have not. iax uses udp and traverses nats. neither of these seems useful to me. i loathe nats, and udp is not well-behaved in the sense of congestion avoidance. trunking will save some bytes in flight iff one has four or more streams moving between two pbxes. but who would want to have the pbxes in the data stream anyway? reinvite rules, especially in a geographically distributed use scenario. now, i could see a network of iaxen if there was some way to negotiate call routing with costs etc. but trip looks a bit ugly and kinda far away. and it certainly is not part of current play. what am i missing here? randy
Randy Bush wrote:> > iax uses udp and traverses nats. neither of these seems useful to > me. i loathe nats, and udp is not well-behaved in the sense of > congestion avoidance. >You may indeed loathe NATted networks, but in general they're very hard to avoid. Why would you criticize a protocol for dealing with such a thing efficiently--which, quite famously, SIP does not? Also I suspect if you spent about 2.5453 nanoseconds on a call done using *only* TCP, you would quickly have your answer wrt the use of UDP for VoIP. Do you know of a successful VoIP protocol that is entirely TCP-based?> trunking will save some bytes in flight iff one has four or more > streams moving between two pbxes. but who would want to have the > pbxes in the data stream anyway? reinvite rules, especially in a > geographically distributed use scenario. >I would want the PBX in the datastream in cases where multiple endpoint connections would pass through multiple IAX boxen, and in that case the trunking would save the decidedly-costly IP overhead that would be required if the endpoints were simply communicating directly--if bandwidth efficiency is a desideratum. Perhaps in your case your networks are all public-IP, running on DS3s or OC48s. In that case I don't reckon efficiency would matter much. . . .> > what am i missing here? >?? My guess would be experience, but that might be presumptous of me. I'll let others weigh in. Maybe I'm completely misreading this. B.
On Mon, 5 Jul 2004, Randy Bush waxed:> i am looking at iax to see if it is applicable to my needs. i > would appreciate any corrections of what i think i have understood > but probably have not.Are we all supposed to guess what your needs are ?> iax uses udp and traverses nats. neither of these seems useful to > me. i loathe nats, and udp is not well-behaved in the sense of > congestion avoidance.I think you could argue that IAX loathes NATs, too. That's why it traverses them. That's a loathing way about it, eh ?> trunking will save some bytes in flight iff one has four or more > streams moving between two pbxes. but who would want to have the > pbxes in the data stream anyway? reinvite rules, especially in a > geographically distributed use scenario.You *can* set up IAX to by-pass intermediate PBXes for direct, end-to-end communication. I think the default conf files actually ship that way.> now, i could see a network of iaxen if there was some way to > negotiate call routing with costs etc. but trip looks a bit ugly > and kinda far away. and it certainly is not part of current play.So future expansion with the protocol is not your concern ?> what am i missing here?The answer to the question: what kind of VoIP do you want ? --Chris -- Chris Maj, Rochester cmaj_at_freedomcorpse_dot_com Pronunciation Guide: Maj == May
Randy, On 01:11 PM 7/5/2004, Randy Bush wrote: >iax uses udp and traverses nats. neither of these seems useful to >me. i loathe nats, and udp is not well-behaved in the sense of >congestion avoidance. SIP and H323 use in NAT'd environments is problematic. IAX provides another solution to the issue for Asterisk administrators. If you don't use a NAT, then you can ignore this feature of IAX. > >trunking will save some bytes in flight iff one has four or more >streams moving between two pbxes. but who would want to have the >pbxes in the data stream anyway? reinvite rules, especially in a >geographically distributed use scenario. There are many reasons to have an Asterisk box in a stream: 1. Control a call, (maybe you want to do some ACL type filtering, maybe you want to keep track of usage, maybe you just to be in control...) 2. Provide features (access to PSTN, conference capability, music on hold, call parking, agents and queues..... the list goes on and on) 3. Endpoints (User Agents) MAY not be able to send data streams to each other directly (firewalls or nats in the middle) And depending upon your view of things (your view might be different than the view of the IT/communications administrator of a large company), using IAX in a geographically distributed use scenario might very well be exactly what you want (use over an encrypted vpn link, etc.) > >now, i could see a network of iaxen if there was some way to >negotiate call routing with costs etc. but trip looks a bit ugly >and kinda far away. and it certainly is not part of current play. > >what am i missing here? Nothing, really. If you don't need IAX, and don't particularly like any of the features of it, then don't use it. At this time, if you don't have NAT's to deal with (or you've already convinced your signalling and media protocols to deal with them), and you don't have a need to force the streams and signalling through your asterisk systems, then 'noload => chan_iax.so' to your hearts content! -Chris
hi <snip> trunking will save some bytes in flight iff one has four or more> streams moving between two pbxes.you call -30% (more or less, depending on the codec) in bandwidth only "some bytes" ?> reinvite rules, especially in a > geographically distributed use scenario.that could be done with iax. see the notransfer flag in iax.conf you can move the entire call away, not only the rtp stream.> now, i could see a network of iaxen if there was some way to > negotiate call routing with costs etc. but trip looks a bit ugly > and kinda far away. and it certainly is not part of current play.but is easy to add info to iax to carry what you need.> what am i missing here?experience. btw, SIP is certainly needed 'cause of the clients... much more available than iax ones. but for server to server pov, iax is sure a better choice. Matteo. -- Brancaleoni Matteo <mbrancaleoni@espia.it> Espia Srl
Randy Bush wrote:> what am i missing here?Use SIP in the LAN and IAX in the WAN. Jeremy McNamara
>hide one end from the other. I have a customer and acarrier. I>don't want one to know who the other is lest they gettogether>and cut me out of the equation.This is certainly a valid point *right now* at a time when the industry is converting from PSTN to VoIP based transport. However, let's look a bit further down the road. For other services that have gone internet, changing the underlying technology has always come with a change in usage patterns and business models following suit. There is no reason to believe that telephony will be any different. Most of what defines SIP is clearly intended for a PSTN alike world. It is a reflection of the incumbents' wish that they can keep the status quo by piggy packing PSTN structures on top of TCP/IP. But is this how things are likely going to turn out? I tend to think not. Some of us have already got Asterisk running on sub $500 hardware running embedded Linux. It is only a matter of "when" not "if" that such devices will become commodity items that you will be able to pick up at Walmart or Radio Shack for about the same as a cordless phone base unit today. At that point, virtually every business and every household will have such a box. Couple that with some universal directory facility, ie ENUM and you have got a ubiquitous peer-to-peer telephone network where telcos will have no role to play other than providing the data pipes. I think everybody will agree that IAX is already perfectly suited for this kind of environment. So where does this leave SIP then? Most of the eeg-laying-wool-milk-sau features in SIP won't mean anything in this kind of environment since they are made for telco centric networks not for all peer-to-peer networks. As far as NAT and firewall traversal goes, SIP proponents are all too easy with offering workarounds that often introduce unwanted side-effects and they justify this by stating that NAT will go away with the advent of IPv6. I find that rather surprising. Let's face it, by the time that IPv6 is so widespread that NAT is not an issue anymore, there will be no telcos left to use all those SIP telco features because telephony will be an all peer-to-peer affair. And what space is left for value added services through third party providers can easily be accommodated by IAX. My conclusion is that IAX is far more future proof than any other VoIP protocol we know about today. Future proof in the sense of what the future is more likely to be, not in the sense of what the incumbents would like the future to be. just my 2 cents benjk __________________________________________________ Do You Yahoo!? http://bb.yahoo.co.jp/
I get a little confused about IAX and SIP, are those 2 diff. protocols? For example, I know IAX2 works behind NAT or firewalls right? So that users with IAX softphones or phones can register into asterisk boxes behind firewall or them been behind a firewall? Is this true? Then what is SIP, another protocol and can it go behind firewalls or do you need to configure or open certain ports? __________________________________________________________________ Anton Krall
I recently signed up with TelIAX for voip service. I'm currently using IAX to connect to them. Would connecting to them via SIP provide less latency or be better in any way? Thanks for everyone's 2 cents!! I just to be sure I'm using the best/fastest trunk methods. -Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20051206/80e564ce/attachment.htm