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
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:213-799-1400