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

Sun Jan 4 22:43:51 CST 2009

On 1/4/09, Trixter aka Bret McDanel <trixter at 0xdecafbad.com> wrote:
> 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.

  I'm not with you on understanding UDP in a Posix environment (I'll
take your word on this) but I generally agree.

> 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.

  I'm perfectly aware of that option (along with others to rewrite
timestamps, etc).  I've been hinting in that direction for quite some
time... ;)

> 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.

  Possibly, but that result would be rare.  Anyone could run these
tests from anywhere, posting different results.  Again, I'm merely
looking for a "base".

> 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.

  I am sorry, I don't know anything about Broadvoice's architecture.
I was assuming you were describing something like Level(3) Viper
(which works exactly like this).  If the problems seem to float around
they are most likely doing something else with the media on the other
side of the IP you are seeing.  Even more of a reason to run
recqual... ;)

>  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.

  Actual "outages" are a completely different story.  I'm not looking
to challenge the uptime institute here.

> 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.

  Word.

> 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?

  In the very beginning of my argument I qualified the various IP
endpoints should be limited to the United States only (ideally the
48).  I'm sorry for being so US-centric but things get so much more
difficult to test once you leave.  I can imagine, though, that if the
OP had the bulk of carrier routing decisions in the US come from data
on his website he would be extremely happy. :)

  To answer your question, maybe.  If the carrier's endpoint IP
address is in the US and they have a poor rating when tested from the
US, you most likely don't stand a chance in Amsterdam.  If the
endpoint is based in the US and they have an excellent rating, that
would increase your chances for success.

  My tests with recqual were very interesting.  Often times IP is
blamed for call quality problems.  Many times that just isn't the case
and there are other issues.  Issues with the media gateway, PSTN
trunks, RTP stacks, etc.

  One carrier (who will remain nameless) had unbelievably bad call
quality regardless of endpoint.  Long term pings, traceroutes, RTCP
reports, everything that could be gleamed from IP looked perfect.  Yet
the calls were horrible.  I tried sending calls to their various SBCs
all over the country.  Again, everything always looked good yet long
term call tests showed wide ranges in audio quality.  They were not
willing to work with me on this.  I never figured out what the problem
was (specifically) but I knew not to waste my time with them.

>  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.

  Again, I should have gone into greater detail.  This was never
intended to be global.  However, if the carrier has IP endpoints in
Amsterdam, why not test it from various points in Europe?  I don't
know enough about IP connectivity on a global scale but surely there
must be some way to have equally valid data with a minimal number of
monitoring stations.

>  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.

  This would be a poor choice to run any quality tests from.  However,
my example from Amsterdam applies here equally.  To be more specific,
the issue here would most likely be that ISPs single upstream (which
probably has all sorts of issues).  Very few carriers (if any) would
perform well over such a connection.

>  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.

  I'm not sure we are even in disagreement, I think the more we define
this the more we would agree.

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com