[asterisk-biz] Experimental/new VoIP rate search engine.

[Trixter aka Bret McDanel]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/asterisk-biz/attachments/20090105/646e539b/attachment-0001.pgp