[Freeswitch-users] Silence suppression again

Wed Feb 27 20:44:07 MSK 2013

A quick update on this - I have verified that suppresion of silence 
suppression(!) on Grandstreams doesn't work when it is the B-Party of a 
call. I'm not sure if silence-suppression is part of the SIP handshake, 
but I know that other VOIP technologies seem to be able to prevent it.
I'm calling in a handset specialist to advise..

One of the things that intrigues me is this extract from the log 
(particularly the reference to silenceSupp):

2013-02-27 17:28:05.151624 [DEBUG] switch_core_codec.c:244 
sofia/internal/0253302 at 004-0253.sb12.dmclub.org Restore previous codec 
PCMA:8.
2013-02-27 17:28:05.151624 [DEBUG] mod_sofia.c:754 Local SDP 
sofia/internal/0253302 at 004-0253.sb12.dmclub.org:
v=0
o=FreeSWITCH 1361975871 1361975873 IN IP4 176.58.88.201
s=FreeSWITCH
c=IN IP4 176.58.88.201
t=0 0
m=audio 10212 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:30
a=sendrecv

What does all this mean?

 From the "A" leg of the call (which is placed by a LinkSys SPA922) I have:

<sip_local_sdp_str>v%3D0%0Ao%3DFreeSWITCH%201361974765%201361974767%20IN%20IP4%20176.58.88.201%0As%3DFreeSWITCH%0Ac%3DIN%20IP4%20176.58.88.201%0At%3D0%200%0Am%3Daudio%2011468%20RTP/AVP%208%20101%0Aa%3Drtpmap%3A8%20PCMA/8000%0Aa%3Drtpmap%3A101%20telephone-event/8000%0Aa%3Dfmtp%3A101%200-16%0Aa%3DsilenceSupp%3Aoff%20-%20-%20-%20-%0Aa%3Dptime%3A30%0Aa%3Dsendrecv%0A</sip_local_sdp_str>

 From the troublesome "B" leg of the call (placed by FreeSwitch to my 
GXP2000) I have:

sip_local_sdp_str>v%3D0%0Ao%3DFreeSWITCH%201361974745%201361974746%20IN%20IP4%20176.58.88.201%0As%3DFreeSWITCH%0Ac%3DIN%20IP4%20176.58.88.201%0At%3D0%200%0Am%3Daudio%2011488%20RTP/AVP%208%20101%2013%0Aa%3Drtpmap%3A101%20telephone-event/8000%0Aa%3Dfmtp%3A101%200-16%0Aa%3Dptime%3A30%0Aa%3Dsendrecv%0Am%3Daudio%2011488%20RTP/AVP%208%203%20101%2013%0Aa%3Drtpmap%3A101%20telephone-event/8000%0Aa%3Dfmtp%3A101%200-16%0Aa%3Dptime%3A20%0Aa%3Dsendrecv%0A</sip_local_sdp_str>

I was wondering if there's a way I can modify this to include 
a="silenceSupp:off - - - -" and whether that would make the slightest 
bit of difference to the handset's behaviour!

Alex
> Thanks.
> I've been looking at the channel variables of the call. And this is 
> part of it:
>
> <rtp_audio_in_raw_bytes>1089091</rtp_audio_in_raw_bytes><rtp_audio_in_media_bytes>957212</rtp_audio_in_media_bytes><rtp_audio_in_packet_count>10344</rtp_audio_in_packet_count><rtp_audio_in_media_packet_count>5581</rtp_audio_in_media_packet_count><rtp_audio_in_skip_packet_count>5480</rtp_audio_in_skip_packet_count><rtp_audio_in_jb_packet_count>0</rtp_audio_in_jb_packet_count><rtp_audio_in_dtmf_packet_count>0</rtp_audio_in_dtmf_packet_count><rtp_audio_in_cng_packet_count>4323</rtp_audio_in_cng_packet_count><rtp_audio_in_flush_packet_count>440</rtp_audio_in_flush_packet_count><rtp_audio_in_largest_jb_size>0</rtp_audio_in_largest_jb_size><rtp_audio_out_raw_bytes>1829908</rtp_audio_out_raw_bytes><rtp_audio_out_media_bytes>1829908</rtp_audio_out_media_bytes><rtp_audio_out_packet_count>10639</rtp_audio_out_packet_count><rtp_audio_out 
> _media_packet_count>10639</rtp_audio_out_media_packet_count><rtp_audio_out_skip_packet_count>0</rtp_audio_out_skip_packet_count><rtp_audio_out_dtmf_packet_count>0</rtp_audio_out_dtmf_packet_count><rtp_audio_out_cng_packet_count>0</rtp_audio_out_cng_packet_count><rtp_audio_rtcp_packet_count>0</rtp_audio_rtcp_packet_count><rtp_audio_rtcp_octet_count>0</rtp_audio_rtcp_octet_count>
>
> The thing that slightly concerns me here is 
> <rtp_audio_in_cng_packet_count>4323</rtp_audio_in_cng_packet_count>
>
> That sounds as though the inbound audio path contains some comfort 
> noise, suggesting that the handset the other end has some kind of 
> silence suppression enabled.
>
> I'm afraid it's a dreaded Grandstream GXP2000 - which I know are not 
> the handset of the cognoscenti! - but the customer tells me that he 
> has silence suppression disabled. Do we think this is correct?!
>
> Rgds,
> Alex
>> It does not send any by default.  Also, yes it only generates silence 
>> when the call is not getting any RTP.
>>
>>
>>
>> On Tue, Feb 26, 2013 at 12:00 PM, Alex Lake <alex at digitalmail.com 
>> <mailto:alex at digitalmail.com>> wrote:
>>
>>     Does Freeswitch enable any kind of silence suppression by
>>     default? If I
>>     have bridge_generate_comfort_noise=true, does that only have an
>>     effect
>>     when the audio-generating end decides to stop sending RTP?
>>
>>     Any other tips for diagnosing silence (it's kind of like a slow noise
>>     gate effect)?
>>
>>     _________________________________________________________________________
>>     Professional FreeSWITCH Consulting Services:
>>     consulting at freeswitch.org <mailto:consulting at freeswitch.org>
>>     http://www.freeswitchsolutions.com
>>
>>     
>>     
>>
>>     Official FreeSWITCH Sites
>>     http://www.freeswitch.org
>>     http://wiki.freeswitch.org
>>     http://www.cluecon.com
>>
>>     FreeSWITCH-users mailing list
>>     FreeSWITCH-users at lists.freeswitch.org
>>     <mailto: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 <http://irc.freenode.net> #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org 
>> <mailto:sip%3A888 at conference.freeswitch.org>
>> googletalk:conf+888 at conference.freeswitch.org 
>> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:+19193869900
>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> 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
>>
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 2012.0.2238 / Virus Database: 2641/5634 - Release Date: 02/26/13
>>
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> 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
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2012.0.2238 / Virus Database: 2641/5635 - Release Date: 02/26/13
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130227/7d02936d/attachment-0001.html 