VoIP Mailing List Archives

[keithl at voxtelecom.c...]

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 :
<![if !supportLists]>a) <![endif]>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 ?
<![if !supportLists]>b) <![endif]>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 (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 ([email]MSN%3Aanthony_minessale@hotmail.com[/email])
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com ([email]PAYPAL%3Aanthony.minessale@gmail.com[/email])
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org ([email]sip%3A888@conference.freeswitch.org[/email])
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org ([email]googletalk%3Aconf%2B888@conference.freeswitch.org[/email])
pstn:213-799-1400

[anthony.minessale at g...]

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 (keithl@voxtelecom.co.za)> wrote: