[Nanog] VoIP over Asymmetric routing


We are going to roll out a network to carry VoIP only, between the P
routers, there will be 3xOC3 links.

Each site has 2xPEs, PE1 is connected to the P router in the local premises
with 10GE and PE2 is connected with 2xOC3s to remote P sites for backup
incase local P fails.

VoIP is going to be generated by Ericsson Media Gateways and the network
designers are suggesting to take traffic in the outgoing direction through
the PE1 path and come back through the PE2 path (if that makes sense), so
traffic will take a different link for outgoing over incoming.

From your experiences, I am wondering what are future unforeseen pitfalls we

can get into?


If there are any firewalls in the path they tend to dislike asymmetric
routing(just standing the obvious)..

It tends to play hell on the VoIP ALG's and can cause them to eat
CPU/Hang/Crash depending on what vendor you have.

This assumes that you have a firewall in the network path. Other items that
would concern me is link utilization (What if one network link became
completely saturated?)

From a application stand point most VoIP systems will do ok with asymmetric

routing RTP doesn't *need* to be symmetric but I would have concerns of
designing it to be asymmetric out of the gates.

Just my 2 copper.

Tim Eberhard


In _Theory_ asymmetric routing _should_ be ok, but that's in theory.

I would be concerned as to why they are designing it this way. Have they
gave you a good technical reason it has to be this way? I would ask them to
justify it.

Also, if there are routing problems on one path but not the other, this
could cause a scenario where voice is heard but not received, or vice-versa.
This situation is much more frustrating to customers as they will try and
continue the conversation. Opposed to if it just doesn't work at all because
of a routing problem, customer will just use their cell phones.

Also, are they implementing any local PSTN access for local calls or

That's my experiences.

Having the 2 sessions take different paths is fine as long as they both
always work as well as each other. If one has more latency or jitter than
the other you are likely to run into noticeable echo or other quality
issues. What's more important, however, is that each RTP session
traverses only 1 path. If you have different packets (or groups of
packets) that are part of one session taking different paths, you will run
into issues with out of order packets that basically just get dropped.

  The other thing to think about it what are you actually gaining
here? Not redundancy because 1 direction of a call's media is not an
acceptable loss (i.e. "in" link goes down but "out" link stays up). Also
you aren't gaining much on capacity because modern backhaul links such as
10GE links or OC-X's are symmetrical, so if you only carry traffic in one
direction (RTP is UDP so has no ACKs or any reverse direction traffic
within the one session) you are actually wasting half of your circuits.