I get reasonably good results with Android/Media5Fone and g.722, but this is more to do with our wifi setup than anything else. Spectralink has really nice WiFi handsets, but it's cheaper to buy an android phone and a soft phone. They are much more rugged however. We have 12+ Unifi APs covering about 3 blocks. As long as your signal is good, you get a high enough modulation that the AP can service about 75Mb/s of bandwidth. The controller limits each client to 4Mb/s. The net result is that there are plenty of time slots left for voice (although I wouldn't want to try that on a major holiday). The radios also translate DSCP to WMM, so there is a measure of QoS. Roaming doesn't work - you can't here for a good 20-30s when you walk between access points. You can fix this with high end gear, but we didn't have the $40k to spend on it. If you can use DECT, give it a try. The gigasets sounded great, until all of them broke. Panasonic has some coming out now that sound good. Snom's work well and can do IPv6, but they don't sound quite as nice. -Tim On 13-09-19 08:12 PM, Karl Schmidt wrote:
On 09/19/2013 06:15 PM, Nathan Neulinger wrote:
Anyone got any recommendations for decent quality wifi sip phones? Obviously the 'android+soft client' model will work, but what about actual handsets built for the task.
I dug into this issue a bit - sounds like wifi and sip don't exactly like each other. The problem people get is stuttering. It is the old bit where it is easy to confuse the difference between speed and latency. If you look at the through-put - wifi appears like it should work, but there are cases where packets can be delayed - and if part of an audio stream, either you get excessive latency from buffering or it misses a time slot and stutters.
Now if you were watching a video - no problem ( it is if you need to mix video inputs) - just delay the playback via a big buffer - but phone conversations are sort-of realtime.
So this is why there is a market for a substitute and what I've heard is that Siemens- Gigaset ( DECT ) phones are a good substitute for wifi.
This is looking like it would block using a softphone via wifi. I've wondered if some of the low data rate codex would make it sort of work? Once I get the rest of freeswitch working I will be building a updated linphone ( the stable version in Debian has problems) to test with. My hunch is that the low data rate won't fix the problem with maximum delay of packets. (Could be a function of the wifi access-point - and how many are sharing it).
See myth 16 here http://www.cisco.com/en/US/prod/collateral/wireless/ps9391/ps9393/ps9394/pro...
<warning boring EE digression follows>
A bit more about latency. Landlines use data paths like in T1 bits where every call channel has a place waiting for the next bit of data - ( 8 bit words where they steal a bit for signaling - thus 56kbits instead of 64kbit.) Every frame of the T1 data has a place reserved for your phone conversation - no sharing (at least at this level).
Land-line latency was so short no one noticed or even talked about it. Enter cell phones. Bad nasty latency - I measured up to 500ms (anything over 50ms bugs me)( plug a mike into a storage oscilloscope and have the cell phone call your land-line on speaker phone - clap - measure the time between the clap and the clap coming out of the speakerphone.).
This is bad. In WWII the Nazi's used wire recorders to insert latency and found that if the latency was bad enough - people would get mad at each other for interrupting. ( I suppose the latency introduced with cell phones is why everyone started hating each other.)..
Now introduce wifi. The lovely folks in government did not want it to work. It potentially competed with services that people paid for and those providers provided bribes^h^h^h^h^h^h investment opportunities (The type the little guy never sees) to the ruling elite to be sure it would die. So after stalling they came up with a plan - put wifi on top of the frequency u-wave ovens use - lots of interference and they are tuned for water absorption so the range should be limited - and specify a very low amount of power - limit the spectrum.
BUT! - EEs are a stubborn bunch - they took what the FCC gave them and made it work anyway.
But, it sort of sucks. The kluges that resend missed packets and the like induce latency all over the place.
Part of the problem is the SIP protocol overhead - could be IAX would make it work a bit better?, but right now we live in a SIP world. I've not been able to find any numbers on IAX vs SIP over wifi - I bet it still has problems.
-------------------------------------------------------------------------------- Karl Schmidt EMail Karl@xtronics.com Transtronics, Inc. WEB http://secure.transtronics.com 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434
Never put off till to-morrow what you can do the day after to-morrow just as well. -- Mark Twain --------------------------------------------------------------------------------
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org