recommendations for Wifi SIP phones?
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. -- Nathan ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
"actual handsets built for the task." these are called SIP DECT phones :) Wifi works OK... but its pretty lossy and not something I like to do On 20 September 2013 09:15, Nathan Neulinger <nneul@mst.edu> 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.
-- Nathan
------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect
_________________________________________________________________________ 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
-- Sincerely Jay
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 --------------------------------------------------------------------------------
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.
The side affect of not using your mobile phone + sip app is that the supported codecs on DECT/Wifi phones are so limited and not expanded in the future. On Siemens Gigaset DECT phones the max is G7221 (HD 16000Hz). Also, I experienced trouble calling with my baresip client to Siemens Gigaset handsets using the G7221 codecs. I'm not sure which end is causing the trouble (baresip or Siemens Gigaset DECT handset). The weird thing is that I'm hearing the voice from the Siemens side really good, but the Siemens side complains they are hearing my voice in slower motion. This appeared to happen in two different cases... Someone has an idea what could cause this issue or is having the same experience? Thanks for the interesting EE digression insight.
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.
Do you have a source for this statement? I would like to read upon it. (I suppose the latency introduced with cell phones is why everyone started hating each other.) That made me laugh... :) -- EL
On Sep 21, 2013 5:23 PM, "EL" <fs.user@fordior.net> wrote:
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.
The side affect of not using your mobile phone + sip app is that the supported codecs on DECT/Wifi phones are so limited and not expanded in the future. On Siemens Gigaset DECT phones the max is G7221 (HD 16000Hz). Also, I experienced trouble calling with my baresip client to Siemens Gigaset handsets using the G7221 codecs. I'm not sure which end is causing the trouble (baresip or Siemens Gigaset DECT handset). The weird thing is that I'm hearing the voice from the Siemens side really good, but the Siemens side complains they are hearing my voice in slower motion. This appeared to happen in two different cases...
Someone has an idea what could cause this issue or is having the same experience? Most prolly ptime mismatch on the codec side. Transcode it or hardset it.
Thanks for the interesting EE digression insight.
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.
Do you have a source for this statement? I would like to read upon it.
(I suppose the latency introduced with cell phones is why everyone started hating each other.)
That made me laugh... :) Wicked guys these nazis, right :)
-- EL
_________________________________________________________________________ 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
On Siemens Gigaset DECT phones the max is G7221 (HD 16000Hz). Also, I experienced trouble calling with my baresip client to Siemens Gigaset handsets using the G7221 codecs. I'm not sure which end is causing the trouble (baresip or Siemens Gigaset DECT handset). The weird thing is that I'm hearing the voice from the Siemens side really good, but the Siemens side complains they are hearing my voice in slower motion. This appeared to happen in two different cases...
First of all, I have to correct one typo: Siemens supports G722 not G7221.
Someone has an idea what could cause this issue or is having the same experience?
Most prolly ptime mismatch on the codec side. Transcode it or hardset it.
I have looked at: http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg21052.h... And: http://wiki.freeswitch.org/wiki/Variable_sip_codec_negotiation <action application="set" data="sip_codec_negotiation=scrooge"/> Is that what you meant with setting the ptime or should I use another setting? Thanks for your input. -- EL
I have linphone working quite well with a WIFI connection - the detail is you have to limit other computers accessing the same AP at the same time. The interesting development is 802.11ac with MU-MIMO - I don't have hardware to test with, but MU-MIMO apparently fixes the VoIP wifi problem. http://en.wikipedia.org/wiki/Multi-user_MIMO Also - 802.11ac should do good beam-forming with devices that support it. http://chimera.labs.oreilly.com/books/1234000001739/ch04.html There is also work on UWB and wavelet radio that if allowed at enough power could do some amazing things. There is a link to a working server that would show the details - but the administration wants to jerk the public around for political purposes and has it redirected to a nag page. http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-02-48A1.pdf ... but you can see it here: http://web.archive.org/web/20111016141207/http://hraunfoss.fcc.gov/edocs_pub... I first learned of wavelet radio in 1984 from a Russian engineer - our government did everything it could to prevent it's use and development. (It is difficult to intercept or jam such signals ) - if we lived in a sane world wifi would be based on this and be much more advanced than it is now. The current regulation limit the power and usefulness to limit competition to protect particular companies. In spite of these roadblocks wifi and UWB has slowly developed.. -------------------------------------------------------------------------------- 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 There's many a bestseller that could have been prevented by a good teacher. --Flannery O'Connor --------------------------------------------------------------------------------
A few more details - It turns out that enterprise wifi uses CTS RTS in order to handle a large number of devices - if they block you for half a second during a phone call, you won't like it. On the other hand - I'm seeing some stuff from CISCO about VOIP WIFI - (most likely based on a new standard?). The bottom line is that a softphone over regular wifi is not likely bring joy. -------------------------------------------------------------------------------- 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 Don't cheat people; the government doesn't want the competition. --------------------------------------------------------------------------------
A few more notes: It appears that Skype and Google voice work well enough over wifi - but not SIP. So I'm starting to think that the SIP protocol stack is the problem? There are other standards - Most are proprietary, but it looks like jingle is on a BSD licenses. I can't seem to find anything that mentions the license of IAX2 ?? There are some softphones that support IAX2. Mod Opal lets freeswitch talk via IAX2 - I don't know if it is working? If anyone has tested a IAX2/freeswitch/wifi combination - I would be quite interested in the results. Squinting into the future - the question is if the new wifi standard 802.11ac or a move beyond SIP will be the solution to VoIP/wifi It does look like 802.11ac has addressed some latency issues with MU-MIMO, but I've been unable to find any real-world numbers. This is a complex new standard that will take a while to get debugged and bench marked. Could be that any wifi that has more than one connection will glitch audio - and MU-MIMO could fix that. Right now it still looks like a SIP world that we live in.. -------------------------------------------------------------------------------- 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 Prosperity is the best protector of principle. -- Mark Twain --------------------------------------------------------------------------------
Audio issues on wifi have nothing to do with the signaling protocol, they have everything to do with the codecs and other media features. My biggest issue with wifi based sip phones is the battery life sucks. Don't bother w/ IAX2 its a solution looking for a problem. Mike On Oct 10, 2013, at 10:19 PM, Karl Schmidt <karl@xtronics.com> wrote:
A few more notes:
It appears that Skype and Google voice work well enough over wifi - but not SIP. So I'm starting to think that the SIP protocol stack is the problem?
There are other standards - Most are proprietary, but it looks like jingle is on a BSD licenses.
I can't seem to find anything that mentions the license of IAX2 ?? There are some softphones that support IAX2. Mod Opal lets freeswitch talk via IAX2 - I don't know if it is working? If anyone has tested a IAX2/freeswitch/wifi combination - I would be quite interested in the results.
Squinting into the future - the question is if the new wifi standard 802.11ac or a move beyond SIP will be the solution to VoIP/wifi
It does look like 802.11ac has addressed some latency issues with MU-MIMO, but I've been unable to find any real-world numbers. This is a complex new standard that will take a while to get debugged and bench marked. Could be that any wifi that has more than one connection will glitch audio - and MU-MIMO could fix that.
Right now it still looks like a SIP world that we live in..
On 10/11/2013 09:02 AM, Michael Jerris wrote:
Audio issues on wifi have nothing to do with the signaling protocol, they have everything to do with the codecs and other media features.
Not sure what you mean - it appears to mostly have to do with the nature of wifi - today's wifi only serves one client at a time - thus there are gaps that best case could be covered with large buffers and delay. I did more tests just today with a Debian desk top and linphone as the client - works fine if the host is the only one connected. If you have a second host moving a data stream, it gets bad pretty fast. The closer the AP and host the better it works as there is more bandwidth - but I could make things fail even at close range. What I'm looking at is the ability for skype and Google voice to work where SIP does not. I have a lot more tests to run. I've bumped into this claim several times. ( I did find confounding problems if zrtp was turned on with a client without support - this is even on 1000BaseT not wifi related ) I'm also reading that CISCO has APs that make SIP work better - might just be marketing hype - but could be careful sharing of bandwidth and QOS.
My biggest issue with wifi based sip phones is the battery life sucks.
Even when the phone is used as a phone it is a problem - wifi tends to burn even more power. I've wanted to make it work with something in the 7" format that would have more battery. Newer chipsets can use a lot less power if the drivers are right. Don't bother w/ IAX2 its a solution looking for a problem. That is what I've heard - but I do see some products supporting it - makes me think there is a reason. ( my searches did not find happy freeswitch users using IAX2 ) -------------------------------------------------------------------------------- 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 In a business deal, both parties enter for their own gain. It is only when dealing with the government, because of the threat of physical force, that we enter in deals that are not in our interest. kps --------------------------------------------------------------------------------
Karl, I think what Michael means is that SIP is a signaling protocol and would having nothing to do with audio issues. If google voice or skype work on a wifi link and SIP does not then it is most likely due to the choice of audio codec. Google voice is probably using something like g.729 or speex/opus whereas if you haven't made changes to a default SIP install you may be using G.711 or G.722, etc. My experience has been that wifi on good APs with the appropriate codec is just barely ok for business users. I think most people that are serious about it in a business environment are using DECT. Kevin On 10/11/2013 05:39 PM, Karl Schmidt wrote:
On 10/11/2013 09:02 AM, Michael Jerris wrote:
Audio issues on wifi have nothing to do with the signaling protocol, they have everything to do with the codecs and other media features.
Not sure what you mean - it appears to mostly have to do with the nature of wifi - today's wifi only serves one client at a time - thus there are gaps that best case could be covered with large buffers and delay. I did more tests just today with a Debian desk top and linphone as the client - works fine if the host is the only one connected. If you have a second host moving a data stream, it gets bad pretty fast. The closer the AP and host the better it works as there is more bandwidth - but I could make things fail even at close range.
What I'm looking at is the ability for skype and Google voice to work where SIP does not. I have a lot more tests to run. I've bumped into this claim several times.
( I did find confounding problems if zrtp was turned on with a client without support - this is even on 1000BaseT not wifi related )
I'm also reading that CISCO has APs that make SIP work better - might just be marketing hype - but could be careful sharing of bandwidth and QOS.
My biggest issue with wifi based sip phones is the battery life sucks.
Even when the phone is used as a phone it is a problem - wifi tends to burn even more power. I've wanted to make it work with something in the 7" format that would have more battery. Newer chipsets can use a lot less power if the drivers are right.
Don't bother w/ IAX2 its a solution looking for a problem.
That is what I've heard - but I do see some products supporting it - makes me think there is a reason. ( my searches did not find happy freeswitch users using IAX2 )
-------------------------------------------------------------------------------- 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
In a business deal, both parties enter for their own gain. It is only when dealing with the government, because of the threat of physical force, that we enter in deals that are not in our interest. kps --------------------------------------------------------------------------------
_________________________________________________________________________ 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
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
participants (8)
-
Daniel Ivanov
-
EL
-
jay binks
-
Karl Schmidt
-
Kevin Wormington
-
Michael Jerris
-
Nathan Neulinger
-
Tim St. Pierre