[Freeswitch-users] Distortion on approx first 200ms of G722prompts on DECT based CPE

Tue Jul 28 13:54:42 PDT 2009

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 at lists.freeswitch.org
[mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of
Anthony Minessale
Sent: 28 July 2009 02:06
To: freeswitch-users at 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 at 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 at hotmail.com
<mailto:MSN%3Aanthony_minessale at hotmail.com> 
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
<mailto:PAYPAL%3Aanthony.minessale at gmail.com> 
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
<mailto:sip%3A888 at conference.freeswitch.org> 
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org
<mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org> 
pstn:213-799-1400

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090728/6dae1f96/attachment-0002.html 