Distortion on approx first 200ms of G722 prompts on DECT based CPE
Hi All, I am testing a range of G722 capable DECT based CPE. With one range, I have noticed that the first 200ms or so of each separate prompt file being played back is played out distorted from the DECT handset. When having a normal conversation, the quality is excellent, but when accessing your vmail, all the individual audio files making up the menu choices exhibit the distortion, which is pretty annoying. The same unit using G729, alaw or ulaw works 100%. I wonder if anybody else has uncounted this issue? My guess at this point - There may be a short break in the RTP between the separate files being played out by FS that makes up any menu. During this time the DECT handset's AGC probably goes to MAX amplification (as its not receiving any input during the short break in RTP). Then, when the RTP returns at the start of the next file, the AGC boosts the audio into clipping zone and takes 200ms to dampen down back to normal good levels. Looks like in these devices the G722 encode/decode is actually done in the DECT handset and not the voip-base unit. Is there any parameter that can be set in FS to ensure that the RTP keeps flowing, sending 'silence' between prompts ? Would be interesting to validate the above 'guess'. Best Regards Keith
you can set the global var send_silence_when_idle=true in vars.xml On Mon, Jul 27, 2009 at 4:23 PM, Keith Laaks <keithl@voxtelecom.co.za>wrote:
Hi All,
I am testing a range of G722 capable DECT based CPE.
With one range, I have noticed that the first 200ms or so of each separate prompt file being played back is played out distorted from the DECT handset.
When having a normal conversation, the quality is excellent, but when accessing your vmail, all the individual audio files making up the menu choices exhibit the distortion, which is pretty annoying.
The same unit using G729, alaw or ulaw works 100%.
I wonder if anybody else has uncounted this issue?
My guess at this point –
There may be a short break in the RTP between the separate files being played out by FS that makes up any menu.
During this time the DECT handset’s AGC probably goes to MAX amplification (as its not receiving any input during the short break in RTP).
Then, when the RTP returns at the start of the next file, the AGC boosts the audio into clipping zone and takes 200ms to dampen down back to normal good levels.
Looks like in these devices the G722 encode/decode is actually done in the DECT handset and not the voip-base unit.
Is there any parameter that can be set in FS to ensure that the RTP keeps flowing, sending ‘silence’ between prompts ? Would be interesting to validate the above ‘guess’.
Best Regards
Keith
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Hi, [Thanks for the advice Anthony] I tried "send_silence_when_idle=true " and restarted, but did not notice any change/improvement. But I had limited time to test, so will need to test more thoroughly with this CPE. An additional test was to configure the following media path scenarios: A: Policom<->FS<->DECT CPE B: Policom<->DECT CPE (media not via FS) [The only change was to add <param name="inbound-bypass-media" value="true" in sip profile for B/>) In scenario A, whenever the Policom's VAD kicked in, it resulted in the first 200ms of the restarting audio being distorted in the DECT CPE. In scenario B, no problems when the Policom's VAD kicked in. I also addressed the issue to the CPE vendor yesterday, who responded today : "We have observed the RTP-stream and found the following : - the RTP-stream is completely interrupted in the pause between the announcements - no RTP-packets are send at all during these pauses - jitter buffer runs empty and our device will automatically mute the connection when no packets comes in - last RTP-packets before pauses don't contain the info about comfort-noise We would like to ask you the following : - please check if it's possible to send dummy-packets during pause instead of sending no packets at all " In scanning the wiki on the topic of CNG, I found at http://wiki.freeswitch.org/wiki/VAD_and_CNG : "In FreeSWITCH the CNG options select whether or not FreeSWITCH will generate CN RTP packets. suppress-cng sofia profile option and suppress_cng channel variable used to set of this setting. When both sides are supporting RFC3389 (they agree in SDP message exchange, rtpmap:13), FreeSWITCH will send CN packets. Note: Allowing CNG in FreeSWITCH does not mean it will generate any comfort noise into the media channel. In case one of the parties in bridge do not handle VAD and asynchronous RTP media, there should be an issue as the one might think hearing perfect silence and might think the connection has been dropped. Another example is when on one side is Asterisk or CallWeaver. For handling these endpoints, there has been added (r9543) a new channel variable: bridge_generate_comfort_noise which will generate fake audio" So the options here seem to be : a) Get FS to send CNG packet(s) before going into 'pauses'. From the vendor's analysis they are not seeing this when testing (FYI, these observations were made calling into vmail). Could this be because the CPE is perhaps not supporting RFC3389 - FS did not see the rtpmap:13 in the SDP ? b) Make sure FS keeps sending packets during pauses and silence. I am not clear on the difference between the 'send_silence_when_idle=true' and 'bridge_generate_comfort_noise=true' options. Ideally I would still want to leverage VAD, but then need the CNG messages to be forwarded in scenarios where I have media passing through FS on a call between two customers and when a customer is interacting with vmail (or other IVR type application). Any advise appreciated. Best Regards Keith From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: 28 July 2009 02:06 To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Distortion on approx first 200ms of G722prompts on DECT based CPE you can set the global var send_silence_when_idle=true in vars.xml On Mon, Jul 27, 2009 at 4:23 PM, Keith Laaks wrote: Hi All, I am testing a range of G722 capable DECT based CPE. With one range, I have noticed that the first 200ms or so of each separate prompt file being played back is played out distorted from the DECT handset. When having a normal conversation, the quality is excellent, but when accessing your vmail, all the individual audio files making up the menu choices exhibit the distortion, which is pretty annoying. The same unit using G729, alaw or ulaw works 100%. I wonder if anybody else has uncounted this issue? My guess at this point - There may be a short break in the RTP between the separate files being played out by FS that makes up any menu. During this time the DECT handset's AGC probably goes to MAX amplification (as its not receiving any input during the short break in RTP). Then, when the RTP returns at the start of the next file, the AGC boosts the audio into clipping zone and takes 200ms to dampen down back to normal good levels. Looks like in these devices the G722 encode/decode is actually done in the DECT handset and not the voip-base unit. Is there any parameter that can be set in FS to ensure that the RTP keeps flowing, sending 'silence' between prompts ? Would be interesting to validate the above 'guess'. Best Regards Keith _______________________________________________ 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 -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Have a look at the sip traffic. I believe in the default configuration that FreeSWITCH will use negotiated CNG (payload 13) if the other end supplies it. The description you got from your vendor is entirely accurate but they are supposed to handle this situation. When we stop sending RTP for a duration longer than the RTP period we send the marker bit in the next packet which tells the remote end that we have resumed after a pause so it can clear its jitter buffer. If the SDP contains negotiation for CNG we will send it per the RFC. Some devices assume everyone just automatically does CNG w/o negotiating it if your vendor is such a device you may need a special param custom coded into FS to force the CNG even when it's not negotiated. On Tue, Jul 28, 2009 at 3:54 PM, Keith Laaks <keithl@voxtelecom.co.za>wrote:
Hi, [Thanks for the advice Anthony]
I tried “send_silence_when_idle=true “ and restarted, but did not notice any change/improvement.
But I had limited time to test, so will need to test more thoroughly with this CPE.
An additional test was to configure the following media path scenarios:
A: Policom<->FS<->DECT CPE
B: Policom<->DECT CPE (media not via FS)
[The only change was to add <param name="inbound-bypass-media" value="true" in sip profile for B/>)
In scenario A, whenever the Policom’s VAD kicked in, it resulted in the first 200ms of the restarting audio being distorted in the DECT CPE.
In scenario B, no problems when the Policom’s VAD kicked in.
I also addressed the issue to the CPE vendor yesterday, who responded today :
“We have observed the RTP-stream and found the following :
- the RTP-stream is completely interrupted in the pause between the announcements
- no RTP-packets are send at all during these pauses
- jitter buffer runs empty and our device will automatically mute the connection when no packets comes in
- last RTP-packets before pauses *don't contain the info about comfort-noise*
We would like to ask you the following :
- please check if it's possible to send dummy-packets during pause instead of sending no packets at all
“
In scanning the wiki on the topic of CNG, I found at http://wiki.freeswitch.org/wiki/VAD_and_CNG :
“In FreeSWITCH the CNG options select whether or not FreeSWITCH will generate CN RTP packets. suppress-cng sofia profile option and suppress_cng channel variable used to set of this setting. When both sides are supporting RFC3389 (they agree in SDP message exchange, rtpmap:13), FreeSWITCH will send CN packets. Note: Allowing CNG in FreeSWITCH does not mean it will generate any comfort noise into the media channel.
In case one of the parties in bridge do not handle VAD and asynchronous RTP media, there should be an issue as the one might think hearing perfect silence and might think the connection has been dropped. Another example is when on one side is Asterisk or CallWeaver.
For handling these endpoints, there has been added (r9543) a new channel variable: bridge_generate_comfort_noise which will generate fake audio”
So the options here seem to be :
a) Get FS to send CNG packet(s) before going into ‘pauses’. >From the vendor’s analysis they are not seeing this when testing (FYI, these observations were made calling into vmail). Could this be because the CPE is perhaps not supporting RFC3389 – FS did not see the rtpmap:13 in the SDP ?
b) Make sure FS keeps sending packets during pauses and silence. I am not clear on the difference between the ‘send_silence_when_idle=true’ and ‘bridge_generate_comfort_noise=true’ options.
Ideally I would still want to leverage VAD, but then need the CNG messages to be forwarded in scenarios where I have media passing through FS on a call between two customers and when a customer is interacting with vmail (or other IVR type application).
Any advise appreciated.
Best Regards
Keith
*From:* freeswitch-users-bounces@lists.freeswitch.org [mailto: freeswitch-users-bounces@lists.freeswitch.org] *On Behalf Of *Anthony Minessale *Sent:* 28 July 2009 02:06 *To:* freeswitch-users@lists.freeswitch.org *Subject:* Re: [Freeswitch-users] Distortion on approx first 200ms of G722prompts on DECT based CPE
you can set the global var send_silence_when_idle=true in vars.xml
On Mon, Jul 27, 2009 at 4:23 PM, Keith Laaks wrote:
Hi All,
I am testing a range of G722 capable DECT based CPE.
With one range, I have noticed that the first 200ms or so of each separate prompt file being played back is played out distorted from the DECT handset.
When having a normal conversation, the quality is excellent, but when accessing your vmail, all the individual audio files making up the menu choices exhibit the distortion, which is pretty annoying.
The same unit using G729, alaw or ulaw works 100%.
I wonder if anybody else has uncounted this issue?
My guess at this point –
There may be a short break in the RTP between the separate files being played out by FS that makes up any menu.
During this time the DECT handset’s AGC probably goes to MAX amplification (as its not receiving any input during the short break in RTP).
Then, when the RTP returns at the start of the next file, the AGC boosts the audio into clipping zone and takes 200ms to dampen down back to normal good levels.
Looks like in these devices the G722 encode/decode is actually done in the DECT handset and not the voip-base unit.
Is there any parameter that can be set in FS to ensure that the RTP keeps flowing, sending ‘silence’ between prompts ? Would be interesting to validate the above ‘guess’.
Best Regards
Keith
_______________________________________________ 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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
participants (2)
-
Anthony Minessale
-
Keith Laaks