wireless can cause delay. VOIP requires low latency.
Is your wireless device a router or bridge ? Huge difference in the answer to that question, as far as VOIP is concerned. How many users, what compression ? Any PC / what kind of traffic besides voice is there ? tom@rickenbackercommunications.com
also don't forget that you have to allow for almost 200 kbps in each direction for voice traffic per call not to mention the overhead associated with the wlan standard in the first place. you will also need to have gear that can guarantee some quality of service on the phone lines to make the calls sound reasonable. ie pcf capable hardware
200kb per RTP stream? you can due video for that? What codec are you running lui? Uncompressed PCM does not even run that high.
Bernie get the wirless link up and running and moving data with low latency/delay. Then start running your VOIP over it. You can do COS mapping on the port connected to your wireless bridge to give your VOIP traffic higher priority than all your data. 11mb/s is more than enough BW. I doubt that you will actually achieve a speed that high but half of that is sufficient for small office/ med office.
Ahhh ok...But he is going to use a PTP wireless bridge. not shared BW AP.. most of the Doc seems to discuss shared Bw AP at 60 percent threshhold for voice. great doc for AP design but I don't think it is relevent to PTP wireless technologies.
we suuport a site with over 100 users over a cisco airo with the directional ant...
We allow 40 calls at one time to go through at G711 then another 20 at g729. We have never had a problem with quality. What do you expect the issues to be lui3?
how many ip phones accross wireless link have you run?
how can you say his wireless solution will not work?
Oh, i don't think his solution will not work. I was just curious to what results you have had.
The problem with VOIP and data together is that even with CAC you can have weird things happen. Especially in shared environs. I like to play it safe with the lower bandwidth ranges especially with bridges. plus, ,ore often than not people end up running linksys instead of cisco or some other brand and then end up putting more data on the line than expected. eventually results in overcrowding or screwy configurations. more often than not they don't use COS marking on the ports or TOS/DSCP marking or LLQ nor do they have a universal switch architecture in place with proper configuration to make things work properly. QOS is QOS people say but i disagree. People have gotten used to ciscos way of things working however thats not the case with all software. Different software platforms (ie cisco, linksys, cabletron, whoever) treat QOS differently. In a mixed environment its better to play it safe or at least be aware of the possible pitfalls of what you are trying to accomplish. I agree in a vendor homogenous environ, ie cisco, you can pretty much push everything to the limit however, i have not seen any mention of a vendor for the call manager (he did say he was using 3com for the bridges) and to assume that this user will using cisco everywhere else could be a mistake. i would want to know more about the underlying hardware before making an assumption that cisco gear or whatever is in place to handle all of this.
i have never used 11 mbps for voice outside of aps. i have only used 1400s on bridged links and never in production. all cisco and no problems. no more than 10 users simultaneously.
are you using full cisco gear all over for your solution?
I Guess the confusion is this: I don't agree with the WEIRD things happen analogy. Predictable things happen, the only variable is if the solution is in our tech vocabulary or not. An appropriate service policy with proper queueing mechanisms will work fine on any 11mbs connection. The speed is the only thing that can be attributed to serialization delay wich in a PTP link is the real factor that will degrade you VOIP performance. 11 meg as a very acceptable serialazion delay. The underlying L2 technology used is not relevant.
I would do a few things on my access switches. Not allow oversized frames for one. and implemented proper COS marking(prob not needed, we tend to skimp on LAN qos most of the time and as long as you seperate your Voice and data traffic vlan wise no issue most of time, (barring virus issues). The most important issue is using a proper service policy that reserves enough BW for your VOIP traffic, and also using some sort of CAC to not exceed the reserved BW or SP.
IF these basic concepts are met the L2 technology used is not really relevant..
are you saying that you can guarantee the predictability of an environment that you have seen posted herein just based on the fact that the user is saying they are using 3com switching and voip. how do you know that they even have the gear to support proper marking/classify/queueing? you don't. that is my point. i agree with everything you are saying including the weird part. problem is in most situations, people don't know all the facts about the system. if they own it they have a better chance. i am not argueing over what strategies to take regarding voice quality i am just saying that i like to play it safe when dealing with the unknown parts of someone elses network. i have gotten burned when dealing out advice without knowing all the facts.
i also disagree with the underlying L2 tech in place not being a factor in success of the connection. i have networks in place that do not understand vlanning or do not mark packets to the extent that other gear does. that is not an issue of configuration or technology. that is an issue of hardware/software not supporting the necessary features. compatibility can be a real problem in the guarantee of proper QOS. cisco products do a great job of handling industry standards and then some other companies do not and it makes things difficult.
Lui..
What does L2 technology have to do with capability of his gear. First off.. This is a wan connection and needs to be treated as such.. NO matter what L2 technology he chooses he is going to need a prioritization and marking mechanism in place. I am assuming if price was not an issue he would just purchase a 10 meg ATM pipe. Would you argue that Voice would not work fine over this connection?
Assuming his gear can do 11mb he has more bandwidth and less delay in the wireless solution by over 30 percent!!!
Just cause L2 changes you still need to manage your voice network properly. All the arguments you are making apply to any WAN solution he implements. Wich I think is great advice. But bottom line the WIRELESS link can handle this fine.
"are you saying that you can guarantee the predictability of an environment that you have seen posted herein just based on the fact that the user is saying they are using 3com switching and voip. how do you know that they even have the gear to support proper marking/classify/queueing? you don't. that is my point."
DOES THIS CHANGE IF HE USES ATM OR FRAME?
"i also disagree with the underlying L2 tech in place not being a factor in success of the connection. i have networks in place that do not understand vlanning or do not mark packets to the extent that other gear does"
This has nothing to do with the WAN framing method he chooses. It is a problem with any solution he decides to implement!!! Are you saying don't run VOIP over the WAN?
When i say layer 2 technology, i am not speaking of ATM or frame but of the capabilities of the equipment implementing that technology. That is my point. I am sorry that this has become so confusing and off topic.
It looks like your experience with wireless and VOIP far exceeds my own. Thanks for your input.
Well, we're not going 9 miles, but we are going 3.8 miles. Across lake superior. With boats crossing the path. And our VOIP and network are running FANTASTIC; we're using a 5Ghz link, and pushing about 30MB across. We're using NEC DTerm series I VOIP phones, and so far nobody has had a single lag/poor quality complaint.
I'm on that link as I type this.
Just my $0.02
"In order to start solving a problem, one must first identify its owner." --Me
--Greg
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.