|reply to VoIPShaper |
Re: Cisco router advice
said by VoIPShaper :Can you give some examples of other options?
Not sure what the other options are in your area, but based on a past experience of mine with a hosted VoIP solution, I'd stay away from using the Internet as your WAN connectivity to them.
If you want to know more let me know, I'd be happy to share more information. To sum it up though this could turn out to be a difficult project.
Definitely, I want to know more! And what fun would it be if it were a cakewalk?
|reply to Merry |
As stated by aryoba above, getting a private T1 connection would be a favorable option (depending on your bandwidth needs). Another could be a point to point switched fiber connection. Using the point to point connection just for VoIP related connectivity only will most likely make WAN related QoS easier to deal with.
Not sure how many physical phones you're looking to install, so I'll use my situation at work as an example. In my environment we have a total of ten IP phones. We use the g.711 codec which takes up roughly 96 Kbps each way per call. We have a 2 Mbps x 2 Mbps point to point ethernet switched fiber connection to our hosting provider. Actual voice traffic only traverses this link for outside calls and retrieving voice mail. Other than that, IP phone heartbeats and call control signaling to the remote end are the only thing that uses this link. When a person makes extension to extension calls, the actual voice stream is switched locally. The call control signaling for setting up and tearing down said calls still goes over the WAN link. If the link to the the provider goes down, we can't make any calls internally or externally. Our transport provider preserves our DSCP tagging end to end. I'm not sure if they honor it but it probably doesn't matter since it's a point to point circuit. As far as I know we will never have quality issues unless that circuit is saturated in either direction. Going back to the 96Kbps each way per call, we could have around 21 outside calls over the WAN. As long as the total throughput of all VoIP calls traversing the WAN doesn't exceed the rate we're paying for, we shouldn't ever see quality issues.
There's two ways you could decide on your bandwidth. One is to figure out how many outside calls you expect to have simultaneously. The other way is to assume the potential of all phones making outside calls at the same time. The former being most cost effective while the later giving you more room. Also keep in mind, one call higher than you can fit will send all present calls into the gutter. Every call over that link will suffer!
Now as far QoS is concerned, don't forget that it only kicks into gear when it needs to. From my understanding, it's only necessary where data and voice mix together. In the case of a 100 Mbps switchport with an IP phone with a PC behind it, the port will only start queuing if the port becomes saturated. In the case where it's just an IP phone, this congestion will most likely never happen. I can't think of any VoIP call that would require 100 Mbps of bandwidth. You should make sure your switch is set to trust whatever QoS markings you do use. I believe there's some switches that will rewrite the CoS or DSCP values if you don't trust them. Typically your trusting your values through the entire end to end path. Also if you're going with the PC behind IP phone route, don't forget the 802.1p tags will get stripped off at the router. Typically you use only one of the two tagging methods. In the case of traversing routers between endpoints, it's generally easier to use DSCP marking and call it a day. You can use DSCP marking whether you trunk to the phone or not.
I apologize if this post comes off excessive but I want to share what I learned. I don't want to see you make the same mistakes I did.
If you have any further questions let me know. If you're interested check out this four part blog I found on QoS: »znetworkconsulting.wordpress.com···n-links/ I found it a while ago and it may give you a good insight into QoS and typical configuration.