Cisco Support Community
Community Member

Voice QoS on ATM/Frame Relay Interworking

I have a scenario where I'm implementing a centralized Call Manager solution for multiple sites. At my Central site, I have a call manager and a PSTN Gateway. The connectivity to my remote sites are ATM/FR interworking where I have an ATM DS3 at the central site and Frame Relay T1s at the remote sites. My Frame/ATM provider is doing the ATM/Frame Relay interworking piece for me. On the ATM side, the VCs are provisioned as UBR. Now here is my concern:

-I am having voice quality issues (only 1 direction - from the central site to the remote site). I have IP RTP Priority configured on the ATM side, and Frame Relay IP RTP Priority configured on the remote side. I am currently not doing any fragmentation because of the complexities involved with ATM/FR interworking. It is my understanding that I would need to to MLP Interleaving on both sides since I can't utilize FRF.12.

Is anyone out there doing something similar with some pointers? Can anyone tell me if this configuration is good, bad, and what do I need to change? By the way, when I was using G.711, I didn't have quality issues. When I changed to G.729, the quality dimenished.




Re: Voice QoS on ATM/Frame Relay Interworking

Since there has been no response to your post, it appears to be either too complex or too rare an issue for other forum members to assist you. If you don't get a suitable response to your post, you may wish to review our resources at the online Technical Assistance Center ( or speak with a TAC engineer. You can open a TAC case online at

If anyone else in the forum has some advice, please reply to this thread.

Thank you for posting.

Community Member

Re: Voice QoS on ATM/Frame Relay Interworking

You could try two pvcs per site. That would at least remove your need for fragmentation if you are unwilling to implement MLP w/interleaving. Can you implement a strict priority queue with the equipment you have? If so I think that 2 pvcs with voice on one and data on the other, and with a strict priority queue allowing voice data out first you may fix your central-to-remote problem.

You've probably already seen this document. You've done everything except the MLP..

CreatePlease to create content