On Sun, 2009-01-04 at 22:04 -0500, Kristian Kielhofner wrote: > - Supporting IAX. No Tier 1 (more like the equipment they use) will > take IAX. If your "provider" is using IAX, your media is most likely > ultimately being proxied to SIP/RTP somewhere. Best of luck to you.
well iax is not a proper carrier grade protocol period. And I will even explain why I said that :) IAX has all traffic, media and signalling goto the same port. This means that even if you have 1000 cores in your system, the reception can only use at most 1 of them. This is just a function of how UDP works in a posix environment. There are some attempts to have it reinvite to a different point to bypass this, however that requires the customer/other end to be part of the plan for cpu management, if they for whatever reason will not move to the alternate port, it does not happen. As a result this forms a bottleneck that can diminish the capacity of the box. So sure its fine for the small time operators but anyone serious who has any knowledge of posix systems would understand this limitation and I can see the bigger guys refusing to support it for this reason. > - Asterisk based platforms. Asterisk doesn't (yet) properly support > direct RTP setup. Re-INVITEs are not appropriate for carrier trunks. > If your provider is using Asterisk, it is probably in the media path > for at least a little while (assuming the Re-INVITE goes well). > yeah that is why freeswitch.org has a bypass-media variable that can be set which specifically enables passing the rtp info between the a/b legs so it does not even need a reinvite to accomplish this. In this way the client is not responsible for this hand off, if they have reinvites disabled, it will still work. > Recqual was designed to test carriers. The carrier is the variable, > and the underlying machine, network, etc are the controls. If I'm > testing multiple carriers from my recqual machine (which I often do) I > can tell you, conclusively, which carriers provide for better actual > call quality. That's not definitively saying that one is *better* for > everyone, but from that machine, one IS better than the other. No > question. > and that was my point. The quality metric is only valid for the sum of all the components, and at that specific point in time on that specific call. So publishing those results for others to see can be misleading since from where the test is done it may be that A is good and B is bad, but where someone else is B may be good and A bad. > Carriers (you mention Broadvoice) throwing calls to random IP > addresses... Shame on them. I never said that. I said that one of their geographically diverse gateways (which you manually select per their instructions) can be working perfectly then a few minutes later wont accept any calls. And which one has this problem seems to float around. As a result you have to manually select a different one if the outage is at a time you want to place a call right then. So the problem is slightly different with them, but the reality is that a test could be done, and if it works it would probably appear quite good, but there are occasions which when last I used them, the outages could last for hours. This example was used to illustrate why, with as many specifics as possible, the test can come out good - but is only relevant to that call at that point in time. Now if you test enough you can see these outages and know to lower the score, but if you do not test that frequently you could miss most or all of the outages, and they would seem to be better than they actually are. > It is very, very difficult to LCR *properly* while still having an > ideal network architecture (direct RTP setup, for example) while > providing somewhat consistent call quality. One provider uses Sonus, > another Lucent, another Cisco. How do your customers all deal with > even the various intricacies in RTP implementations alone? Each of > the vendors I just listed has a myriad of known RTP issues, whether it > be timestamps, sequence numbers, or RFC2833 issues. I know you know > what I'm talking about here ;). Last I checked the various major SBC > manufacturers were sitting pretty. Business is booming. > yes even asterisk has rtp problems where it violates the rfc, not wanting to go into them again and have it ignored again I have just migrated rtp dealings elsewhere. > In a perfect world, yes but I still maintain some *base* numbers can > be obtained fairly easily from one point of measurement. > Ok then, lets look at this claim a bit. I live in Amsterdam right now. Are your base metrics of any value to me if they are all tested from the US? I would almost guarantee that they will not be that reliable from my perspective if you are testing a continent away. What about people in AU, ZA, IN or any of the other places around the world that are similarly far from me? Those base numbers become more and more meaningless when you start to look at it from a global perspective, and why I still maintain that you cannot reliably provide base metrics from only one origination point, nor can you do it if you are testing to only one destination number, because the same provider may use an entirely different path to route calls that are local to me, than calls local to you. It is this global nature, not just of this particular list, but also of the telephony industry at large that makes it a problem to insist that numbers generated from one geographic point on the planet can be applied to others on the other side of that planet. There are also other issues, such as my parents who live in a very rural part of california, their isp, and there is only one there, has 1 uplink. There is no choice in this unless you want to go satellite and add latency. As a result metrics from even a couple hundred miles away can be quite different from their experience. Certainly numbers from the other side of the country would lead to large enough divergences, and its all in the same country. Now this example is somewhat contrived to illustrate a point, and it would be a retail customer vs wholesale, but the *concept* of the point can be applied to indicate that a single origination source cannot compensate for all of these variables no matter how much you try to sell it as being able to. I think on this issue we are not going to agree, however I think that my points are valid, and do cover real world situations. -- Trixter http://www.0xdecafbad.com Bret McDanel pgp key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8AE5C721
signature.asc
Description: This is a digitally signed message part
_______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz
