I have reviewed the thread you posted, however, on the DS3 facing link, how would it help to create classes for each marking? We have QoS applied on all CE devices for traffic inbound from customers and outside callers hear customer just fine.

Since customers are hearing the bad call quality, it must be because of traffic destined to the customer. Traffic comes in through a Gigabit interface and exits through a 45Mb DS3 but it first gets routed through the appropriate VRF/loopback interface. I need a way to apply QoS on the loopback interfaces so that voice traffic going back to the customers gets prioritized. If I try to apply an outbound QoS policy on the interface, it gives me an error as well:

lax_router7206_2(config-if)#service-policy output qos-policy768

Class Based Weighted Fair Queueing not supported on interface Loopback3

Let me know if I am leaving anything out. Thank you for your help.

Hello Johnny,

you cannot apply QoS to a loopback interface it is a logical interface and I don't think traffic is really forwarded via the loopback interface.

You have a loopback interface for each VRF but its usage should be for routing purposes.

>> Since customers are hearing the bad call quality, it must be because of traffic destined to the customer.

I agree

Now, the question becomes who manages the other side of the DS3 link?

Queueing schedulers can only be applied outbound.

I see a description on DS3 interface that makes me think you are in a Carrier Supporting Carrier Scenario with mpls enabled towards an upstream provider.

First of all, you need to be sure that traffic marking and conditioning (policing) is correctly performed in each of customer remote sites at the MPLS edge boundary (VRF access links).

You need to implement CBWFQ also on remote PE nodes core facing links.

Then, If it is a CSC scenario you need to make an agreement with the upstream provider so that they will implement a scheduler on the DS3 link towards your router.

Also it is important to coordinate QoS configuration with voip call control servers configuration:

given a codec type it means a certain BW to be used including all overheads.

Each customer Voip implementation has to use Call admission control to stay within the QoS BW limits for the LLQ.

That is no more then M calls at the same time for customer X.

the M+1 call have impact on all calls so CAC blocks it.

Hope to help

Giuseppe

Guiseppe,

Sprint is the one who manages the other side of the DS3 link and I they will not be of any help to resolve the bad call quality.

I do have QoS applied on the CE routers at customer locations and outside callers can hear customers fine.

Is there any way at all to apply a QoS policy on the Serial interface and match traffic from my SIP server or MPLS bits after mapping DSCP? I think I need to focus on this part sice this is the only place to apply a policy for my voice. If you have any ideas, I would greatly appreciate it. Thank you.

Hello Johnny,

unfortunately once that voip traffic is not well served by the other side of the DS3 connection there is little you can do to repair to this.

The problem can be on the outgoing direction of the outside callers if they don't implement QoS or CAC correctly.

Are the remote callers managed by your company or they are managed by others?

Check also the SLA you have with Sprint you may have oversubscribed the llq class/voip gold class on their side.

To be noted:

voip communications are symmetrical you can get a better quality in the case of oversubscribing Sprint side by reducing the number of concurrent calls customers can do.

This is Call admission control.

Hope to help

Giuseppe