VOIP over Frame Relay

I've got zero experience of this, in fact I've never even had a cisco job but I'll give you the book answer! So long as you use propering queuing techiniques I don't see why it would be a problem. Low latency queueing (LLQ) is the answer.

Just to add onto the above. LLQ is great on point-point connections as you will be delivering VOIP as a priority. But with a Frame-relay Hub your VOIP traffic also has to contend for it's delivery to the main site from the other spokes. Congestion over the HUB sites link is contended from many sites on other pvc's and could still degrade VOIP. I.e. In it's basic form once frames enter a pvc they are delivered as fast as possible over the cloud and in order but once they reach the destination outgoing port of the Frame-relay cloud there is no defrentiation between voice traffic and best effort data between other sites PVC's.

To get round this problem some SP's offer a 2 queue option on egress (exit) from the cloud. These 2 queues though still do not defrentiate between traffic type. Instead they direct traffic from certain PVC's into a particular queue. This means you would need 2 PVC's between the hub/spoke sites 1 for VOIP and 1 for other traffic. In this situation the frame relay cloud would service the high priority (VOIP) queue more often than the standard queue on a ratio basis set by the SP I have heard 10:1, 15:1 20:1 banded about but you would have to ask your SP for their figure if this was an option. Also other preferential treatment is given to the VOIP carrying PVC's such as priority re-routing in the event of a failure in the cloud and possibly other benifits I am not savy to.

If this method was on offer then LLQ would not be an option as you would have to use policy based routing to seperate VOIP traffic onto a seperate PVC to gain the advantage and ensure adequate bandwidth over this PVC both from your router's and in the frame-relay cloud with appropiate CIR settings.

As you may have worked out this is a major design re-jig (not for the light hearted) so I still go along with the testing of basic LLQ as long as you have no issue with bandwidth on the Hub site first and only consider this method if you have VOIP problems with LLQ.

Regards

Toby

I don't see a problem with using it over a frame-relay connection - provided you have sufficient bandwidth. Latency is low enough. I had that in place a few years ago with T1's and it worked fine. Now all my circuits are >

fiber based. Yes, use QOS and LLQ is the key to that. Serial lines on the routers support Auto QOS, so setup is pretty easy.

Jim

You may want to investigate Cisco's VoFR (Voice over Frame Relay) Technical Documentation:

Sincerely,

Brad Reese BradReese.Com=AE Cisco Resource Center United Kingdom: 44-20-70784294 U=2ES. Toll Free: 877-549-2680 International: 828-277-7272 Fax: 775-254-3558=20 Website:

You wouldn't need Call Manager if the plan was to connect up say 2 x PBX's over your WAN for inter-site calls.

Regards

Darren

it depends.

1st thing to do is ask your frame relay provider what they recommend - they may set their cloud up in a way that you can exploit.

some one else mentioned you need LLC to give priority to voice in the routers, but then you have to sort the frame relay issues.

if you cant get priority PVCs or priority handling on a single PVC within the Frame Relay switch for your VoIP traffic, then you need to make sure that the VoIP traffic isnt going to get hit by excessive delay.

the usual way to do this is to make sure your traffic on the affected access lines is not contended

1. you should shape the aggregate traffic so that the load on the PVC is controlled (you dont want a queue building up on the last frame relay switch as it exits the cloud)
2. you should stay within the contracted PVC bandwidth for PVCs carrying Voip, so that if packets do get discarded, then it is unlikely to be the Voip

Also you may need to make sure you dont over commit the frame relay bandwidth on any access lines used for Voip.

I'm not really sure what you are asking here.

First, my recommendations were under the assumption that you are using a private frame-relay network. If you are talking about internet based - all bets are off. Also, you don't need a PBX, per se, to run voip, but you do need a server. Something needs to direct traffic. A Call Manager, pbx, or some other type of voip server (SIP) is needed.

I guess this whole thing brings up the question... Why are you considering using voip? It almost sounds more like you are letting the cart drive the horse here. Don't implement a new technology just because that is becoming the industry standard. Consider it because the solution makes sense based on your current setup and needs.

Jim

Sorry, I did not ask the question in the right way. What I mean is, when the voice traffic comes from the remote sites to the hub, can it be routed to the PSTN through the internet connection or a separate line will be needed to the PSTN.

considering

infrastructure

Even if you have a method Callminder or other Bespoke method of supplying signalling i.e. destination PSTN/IP address/codec relationship, along with gateways over the Internet to recieve and convert this IP traffic to voice from your HUB site. The Internet remains a best effort transport so surely you attempts to prioritise have now gone out the window unless your traffic is local to a single Internet provider (source and destination) who can guarentee this transport and prioritise your VOIP.

Toby

Well, you really need a couple things in order to accomplish voip. First is a traffic cop. For the sake of Cisco, this is a Call Manager or Call Manager express. This helps devices to know where to send their calls. When phone A wants to call phone B or a PSTN number, the Call Manager will tell it how. The second would be a gateway to the PSTN. If you have no need to connect to public phones, then you don't need that. But, it will be a connection to a legacy pbx, or a router with appropriate ports (PRI, BRI or analog). This could be internet provided, or you could provide it yourself. But, somehow you need to convert your ip call to the pstn network.

And, what Toby said about the internet. That is what I meant when I said that all bets are off if you are talking about sending the calls over the internet. You can usually get pretty good sound over the internet, and as a Vonage customer I will testify to that. However, you have no control over it and may experience periods of poor quality.

Hope that helps,

Jim