Voice Degradation using FXO Cards

[mnlatif]

Hi,

We are facing Voice Degradation wil using FXO cards in 2610 Routers.

The link is through Frame-Relay Voice PVC (32K CIR) over 256K Access Pipe. The same serial interface carries another PVC for Data (96K CIR).

The Voice PVC doesn't carry any other traffic except voice. We have "not" implemented Frame-Relay Traffic-Shapping.

The Voice quality is really bad in ONE Direction (i.e from location1 to location2). However Voice from location 2 - location 1 is without any problems. And at the same time i do see some FECN (at location 2) and BECN (at location 1) indicating congestion.

1. Has any one experienced Bad Voice quality in only one direction ?

2. Would it help to implement Traffic-Shapping ?

3. What percentage of FECN and BECN is normal ?

4. Is 32K BW enough for 4 FXO ports (4 Voice calls) simulteneously ?

[slemaux]

What is the access rate of the head end?

Are you using a codec other than G711?

How many total sites are involved, what protocols are you running?

From the math, 32K is not enough CIR to ensure 4 calls proper Bandwidth. At what point is the voice degrading, is is choppy missing message, sound, jitter, echo or after 1, 2 or 3 calls.

Even if you are using G729a, voice packets could be dropped. Not to say that it is here, but look at the FRS stats to see ip packets are being dropped.

Traffic shaping is always recommended, rtp header compression will help, but the trade-off is around a 20% CPU hit.

If you implement traffic shapping , it needs to be done throughout the network as queueing delays related to data on other slow links and at the headend (specifically here) could be the cause of the distortion alone. I would at least try traffic shapping first, then if the problem doen't go away, increase CIR for Voice, if there are still issues, implement LLQ.

[mnlatif]

Access rate at both ends is 256K.

Codec being used is G729.

Only 2 Sites. Its a point-point link over FR with 2 PVC (1 for data, 1 for Voice)

The problem actually happens even with 1-2 calls, so i doubt BW is the problem. And as i said before problem is only in one direction.

I do have some dropped packet, but the dropped packets counter is only incremented(or shows some value) when i implement traffic shapping, why is that ?

Does these dropped packets (in "show frame-relay pvc") indicate the packets dropped by the router ? How can i stop\improve this ?

Do you think that "FRF.12 fragmentation" would help in improving the "serialization delay ? There is some heavy data traffic on the DATA PVC, which might be effecting this.

[dumartin]

You will need to use FRTS. If your voice and data PVC's share the same main interface, the data can clog the pipe. You can look at it lik a freeway with 2 lanes merging. The main pipe is the freeway and the PVC's are the lanes. To give the voice a chance you will need FRTS and FRF12 to improve the quality.

[mnlatif]

And the way to implement is

1. Enable Frame-Relay traffic shapping on main serial interface

2. define frame-relay map-class statements and apply on sub-interfaces.

3. When defining frame-relay fragmentation, should it be defined for both Data and Voice PVC OR only for Data ?

If for both should the size be the same?

I am planning to define it as 320 bytes (we have 256K access pipe. Data PVC(96KCIR) and Voice PVC (32K CIR))

Anything else i need to do ?

Should i enable "rtp header-compression" for Voice PVC ? (we are using IETF encapsulation)

[dumartin]

Your steps are correct for implementing this. The fragementation should be 80 per 64k. So with that rule you will have a map-class for data and voice and they will both be fragmented to 80. I would do 2 map-classes since your CIR is different for the PVC's. It will also allow you to expand voice or data seperately if you get more BW down the road. Since you have only 32k CIR for voice I would try the header-compression.

[mnlatif]

Thanx for ALL your help. One final question, is there a difference betwee these two

Config-

interface serial0/0.3

frame-relay class voice

frame-relay interface-dlci 103 IETF

OR

interface serial0/0.3

frame-relay interface-dlci 103 IETF

class voice

Only "1" DLCI exists for each sub-interface.