A very basic config for steering VoIP traffic onto "private1" (MPLS)
Step 1 - Configure an SLA. This SLA is configured such that if packet loss is greater than 4% *or* latency is greater than 150ms *or* jitter is greater than 20ms the app route policy will move traffic based on how the app route policy is configured. These values are round-trip measurements on each tunnel interface on the vEdge.
policy
sla-class Voice_SLA
loss 4
latency 150
jitter 20
*******************************************
Step 2 - Configure a list to match against. In this case, let's say I'm matching against a list of specific call manager IP addresses. You can match against a network if you need (say a /24 instead of the /32 I'm using in this example) or you can also match against various VoIP protocols.
data-prefix-list Voice_Resources
ip-prefix 10.11.12.13/32
ip-prefix 1.2.3.4/32
*******************************************
Step 3 - Create app route policy (This was created on a Viptela O/S device)
app-route-policy VoIP_app_route_policy
vpn-list Corp-VPN
sequence 1
match
destination-data-prefix-list Voice_Resources
!
action
count Voice_Resources
backup-sla-preferred-color private1
sla-class Voice_SLA preferred-color private1
*******************************************
Now let's put it all together and explain:
Using the parameters in the sla-class "Voice_SLA" measure each of those path characteristics for each tunnel on the vEdge. Then using the app-route policy called "VoIP_app_route_policy"; for sequence 1 match the destination-data-prefix-list called "Voice_Resources"; if there is a match AND the SLA characteristics are within spec (in this example under 4% loss; under 150ms RT latency; under 20ms RT jitter) then execute this line: "sla-class Voice_SLA preferred-color private1" which will put VoIP traffic on the preferred color of "private1" ("private1" being MPLS in my example).
If any of the SLA characteristics are higher than the specification, then put the VoIP traffic onto ANY available transport that IS within SLA spec; if none of the available transports are within SLA spec then execute the backup line "backup-sla-preferred-color private1" which states that the "backup-sla" preferred color is also "private1", which will put the VoIP traffic back onto MPLS.
So, in the end what you have is VoIP traffic being "steered" onto the MPLS circuit (private1); if any of the SLA characteristics are high; put the VoIP traffic onto any other available transport that is within spec; if none are in spec, then just put it back onto MPLS (private1). My thinking for this is the transports available are MPLS; broadband and LTE; LTE is not really a good choice for VoIP traffic so forget that one; so for my SLA I have two viable choices; MPLS and Broadband, if MPLS falls out of spec, put the VoIP traffic on broadband and if both of those transports suck then just put it back on MPLS because that will most likely get fixed first (in my world).
Keep in mind that you will most likely have to do this on both ends using two different app-route policies. So, in this case, I'm steering VoIP traffic onto MPLS at the remote, and the call managers are in my data center so I have to steer the return traffic (from the data center) onto MPLS as well BUT the "Voice_Resources" list would be a "source-data-prefix-list" from the data center back to the remote. So you may need to write two app route policies; one applied to the remotes (using the list “Voice_Resources” as a destination-data-prefix-list) and another applied to the vEdges at the destination but using the same “Voice_resources” list as a "source-data-prefix-list". In my case, the remotes are trying to get to the call managers in the data center so the “Voice_Resources” networks are destinations, but once that traffic lands in the data center, the return traffic from the call manager becomes the source on it's way back to the remote. So now you have to match on a "source-data-prefix-list" from the data center back to the remote.
I know this was really long but I hope I explained it in a manner that was understandable.
