[Freeswitch-users] is there a way to validate RTP is flowing after bridging two channels?

[Steven Ayre]

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 at 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 at 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 at 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 at 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 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
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 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
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160118/78752df4/attachment.html