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

Tue Jul 28 14:26:27 PDT 2009

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 at 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 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 <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> _______________________________________________
> 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 <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<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/717d7e46/attachment-0002.html 