Perfect, thanks! On Jan 18, 2016, at 6:05 AM, Steven Ayre <steveayre@gmail.com> wrote: If you need to do it within FreeSWITCH (eg from a script), execute the uuid_set_media_stats api. This will set a number of variables that you can then read which'll reflect a number of RTP statistics. This will include the number of RTP frames/packets/bytes going in and out of the server for that call. That'll let you spot if a channel isn't receiving any RTP packets. To see what variables are set see the add_stat lines in src/switch_core_media.c:1470 set_stats(), the names will be prefixed between what appears in the code and the variable set for example "in_raw_bytes" => ${rtp_audio_in_raw_bytes}. On 18 January 2016 at 00:58, Dave Horton <dave@dchorton.com <mailto:dave@dchorton.com>> wrote: Well, my issue is that ‘complete silence’ could mean no RTP packets at all, or it could mean RTP packets arriving with all zeros, and I need to distinguish between the two scenarios. I read the recent issue regarding detecting speaker events in a conference to determine silence, so I suppose I instead of bridging I could put the two legs into conference and look for the lack of a ‘start talking’ event within some number of seconds. But I would prefer to sick with bridging the legs if possible. I am unclear about how the recording is going to look in the case where there is no RTP coming in, and whether I could really inspect the recording to know for sure whether or not I am receiving packets…. Dave On Jan 17, 2016, at 5:29 PM, Stanislav Sinyagin <ssinyagin@gmail.com <mailto:ssinyagin@gmail.com>> wrote: you can, for example, start a recording within a running session, run it for 10 seconds, and then build a histogram using SOX. You would then easily distinguish a complete silence from speech. Also at the end of a call, you can get the RTP statistics in channel variables before it gets destroyed, so you can extract the number of RTP packets received. On Sun, Jan 17, 2016 at 11:17 PM, Dave Horton <dave@dchorton.com <mailto:dave@dchorton.com>> wrote: I have a need to bridge two channels together and then somehow verify that I am getting RTP packets from both directions. The need stems from a desire to detect a one-way audio situation in rare nat’ed scenarios where signaling gets established but one party may have restrictive firewall rules preventing his/her RTP stream from reaching the FS endpoint. Any ideas? _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org <mailto:consulting@freeswitch.org> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/> Official FreeSWITCH Sites http://www.freeswitch.org <http://www.freeswitch.org/> http://confluence.freeswitch.org <http://confluence.freeswitch.org/> http://www.cluecon.com <http://www.cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org <mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users> http://www.freeswitch.org <http://www.freeswitch.org/> _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com 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