Z popisu vyplývá, že konfigurace funkce u novějších WiFi AP pro úsporu energie/baterie klientů mají vliv na VoIP provoz.
Doufám, že to někomu pomůže, protože dosud jsem tak dobrý souhrn nečetl.
Pokud máte někdo s konfigurací WiFi podobné a podrobnější zkušenosti, prosím, podělte se.
A pokud víte, jak na WiFi a Androidu (CSipSimple) vyladit nastavení tak, aby fungovaly příchozí hovory a neztrojnásobila se spotřeba energie (jako při "Best Wi-Fi Performance"=on), což pravděpodobně s těmito funkcemi souvisí, budu rád za další informace.
Klíčová slova: Beacon Interval, DTIM Interval, U-APSD, WMM-Powersave, WMM (Wi-Fi Multimedia), WMM No Acknowledgement, WMM APSD, RIFS Advertisement, WiFi, Wi-Fi, VoIP
Zdroj: http://www.developer.nokia.com/Communit ... post609798
Sorry for the long response but hopefully some of the suggestions mentioned here help you to improve the VoIP audio quality in your situation or in case someone else runs into similar issues or wonders something similar related to WLAN power save aspects considering VoIP.
In case phone operates the VoIP call in U-APSD mode i.e. WLAN access point supports U-APSD (alias WMM-Powersave), phone has power save enabled from the advanced WLAN settings (=enabled by default) and outgoing RTP frames are getting correctly getting mapped to Voice WMM category (based on DSCP bits = RTP MEDIAQOS set to value 46 decimal = default) then packetizing interval of the VoIP codec and especially presence of the the VAD without CN (silence suppression) may potentially cause issues or have an effect regarding the downlink VoIP audio quality.
The way U-APSD power save mechanism operates is that WLAN client's (=phone) WLAN tranceiver is basically sleeping in low power mode between transmission of the uplink VoIP RTP audio frames and during this "sleep" time WLAN AP is buffering any downlink RTP frames that are destined to the particular client. With U-APSD practically each uplink RTP transmission of the client will act as an "trigger" for the buffered downlink RTP frames to be delivered from WLAN AP to the client, meaning that in case there is steady bi-directional flow of RTP frames (e.g. every 20 ms) then uplink and downlink RTP frames will be transmitted and received over the WLAN link in pairs and client is able to sleep and concerve power between the RTP frames without causing any significant burstiness (jitter) to downlink RTP stream.
In addition to utilizing uplink RTP frames for triggering the buffered downlink RTP client's are propably also waking up to listen so called beacon frames from the AP (sent by the AP every 100 milliseconds) or instead of waking up to every beacon client might decide to wake up only for every DTIM beacon (defined by DTIM interval setting on the AP) Typical out-of-box DTIM setting of the WLAN AP is 2 or 3, meaning that every other or every third beacon is so called DTIM beacon where clients that are sleeping in power save mode should wake up to receive any buffered multicast/broadcast frames and also check from beacon whether there is any buffered unicast downlink traffic destined for them to be fetched. This is basically similar to how so called legacy WLAN power save delivery mechanism operates and it is the very reason why sticking in to fixed legacy power save mode is not well suitable to VoIP type of applications (or any other real time application with low tolerance for jitter) requiring relatively steady stream of incoming frames. U-APSD power save scheme was basically developed for improving this aspect of the WLAN power save.
Effectively all this means that in case client's VoIP application (RTP stack / codec) is not transmitting any uplink RTP audio frames for extended periods of time (e.g. VAD is in use without comfort noise or call has being
muted = no uplink RTP at all) then delivery of downlink RTP frames is likely to occur in "bursts". The downlink RTP bursts will happen after client has woken up to listen a beacon frame (i.e. every 100 ms => five 20ms downlink RTP packets have become buffered and will be delivered as a single burst, should not cause major issues for the downlink audio quality). If WLAN AP has a DTIM interval of 3 and client wakes up to receive only DTIM beacons then there will 300ms worth of buffered downlink RTP frames to be delivered in a single burst (15 frames) and that is very likely to degrade downlink audio quality significantly.
In case access point does not support U-APSD (e.g. when you tried with Thomson AP that had WMM disabled) and phone still has WLAN power save setting enabled (=legacy power save in use) then phone is able save power during idle periods of the WLAN connection (no data to be transmitted or received over the WLAN connection) by sleeping between beacons and/or DTIM beacons. In case of legacy powersave phone will autonomously switch between active mode and power save mode based on the amount of data flowing over the WLAN connection. E.g. ongoing VoIP call is typically causing enough traffic to be generated so that phone practically stays in active mode (not sleeping at all) during the call which will cause higher on-call power consumption compared to U-APSD enabled VoIP call but still allows idling situations (no ongoing call or data to transfer) to consume significantly less power power compared to situation where power save has been completely disabled from the phone settings. Note that VoIP call with legacy WLAN powersave should have no problems with downlink audio quality (caused by burstiness of the downlink RTP delivery) since phone typically remains in active mode (not sleeping) during the call and thus AP does not have to buffer any downlink RTP frames but instead both uplink and downlink RTP packets will flow over the WLAN link in real time (independently) at the given frame rate that codec is packetizing the audio stream.
As you already mentioned, disabling the power save completely on the phone should be the very last resort especially since it disables also the legacy power save functionality, meaning that WLAN will consume "full" amount of power constanly whenever WLAN connection exists, even if there isn't any actual data be transferred over the connection e.g. when VoIP client remains registered but no ongoing call, during web browsing session, always-on email, etc).
There are few configuration related changes you might want to try out in order to improve the downlink audio quality.
Assuming that your WLAN access point supports U-APSD (WMM-Powersave) probably the simplest option is to look in to your WLAN access point
configuration and set DTIM period (or DTIM interval) to 1 which should effectively cause clients not transmitting RTP frames (due to VAD / Muted call) but staying in power save mode to wake up for every beacon (leave beacon interval to 100). This type of AP configuration (beacon interval=100 and DTIM=1) would mean that in worst case there should only be 100 ms worth of buffered downlink RTP frames to be delivered in burts and it most likely
won't cause audible glitches for the downlink audio quality.
Changing the AP's DTIM interval from e.g. 3 to 1 may cause minor WLAN power consumption increase for the idling WLAN clients (WLAN connection exists without active data/audio transfer) but amount of increase should be very low (few milliamperes) compared to the situation where WLAN power save has been completely disabled from the phone settings.
Other option related to AP configuration is to disable U-APSD (WMM-powersave) from the acccess point. On some U-APSD enabled AP's there might be a separate option to enable/disable U-APSD/WMM-powersave but on some AP's it might be necessary to disable WMM completely, in which case also QoS aspects of the WMM will be lost. Note that disabling U-APSD support from the AP will decrease your phone's VoIP call talk time since phone won't be conserving any power during a VoIP call.
Third option would allow you to leave WLAN AP configuration as is (e.g. beacon interval=100 and DTIM=3) but instead it involves setting up your VoIP profile so that VAD (silence suppression) get's disabled or in case VAD remains enabled call should be created so that Comfort Noise RTP frames are getting generated by the phone during the call. Here CN frames would act as a trigger for downlink RTP and prevent downlink RTP bursts from getting too large in case there is silence in uplink direction.
However it should be noted that muting the VoIP call may still cause your phone to completely stop transmitting any uplink RTP (also CN) thus you may still end up with poor downlink audio quality during a Mute assuming that DTIM interval has been set to higher value than 1.
In case you are comfortable to attempt changing your VoIP profile codec settings it can be done with Advanced VoIP Settings application. For N79 and other VoIP release 3.x phones correct version of the tool should be
"SIP_VoIP_3_x_Settings_v2_0_en.sis" which is available for download via forum.nokia.com web site.
If you are familiar with the VoIP codecs, VAD, etc. aspects and in addition capable of observing the RTP packets during the call (e.g. by capturing the packets from LAN/ethernet with Ethereal or Wireshark) then you may be able to find a proper set of codecs and their settings that causes a steady uplink RTP stream from the phone regardless whether you are talking or not (disables VAD). You could e.g. try leaving only PCMU and PCMA codecs enabled and disable VAD setting for both. Or leave VAD enabled for the PCMU and PCMA and then add CN codec. Note that it might also depend on codec VAD and CN capabilities of the receiving call endpoint whether your N79 phone actually starts to utilizate Comfort Noise frames during a VoIP call thus it might be safer option to try and disable VAD completely instead of attempting utilize VAD with CN.
In case idea of changing your VoIP codecs, VAD settings etc. sounds too complicated then I would suggest that you first simply try if changing the DTIM interval to 1 on your U-APSD enabled WLAN access point improves the downlink audio quality.
