GStreamer RTP Audio Pipe line issue

[Sebastian Dröge]

On Fr, 2016-01-15 at 01:09 +0000, Venkatesh Adiga wrote:

> Hi,
> 
> I am working on a Gstreamer based(for Audio Streaming in RTP Session) Media Gateway Development project. 
> This is my first project that I got involved in Gstreamer based project, and have less knowledge on this domain.
> Below is the scenario of a Q.SIG to SIP call.
> Using the deskphone, the Caller A calls callee B's mobile. As per call signalling is concerned, 
> the call is established between both the parties and RTP ports are activated at Media Gateway. 
> RTP ports are opened and verified by using netstat command on a Linux box. The issue  that I am observing is that 
> oneway audio was seen from callee to caller.
> As per wireshark trace, I am observing that Media Gateway performs the RTP packet transfer to individual call owner, but not forwarding from Caller or Callee or visa versa.
> 
> User A  <---> MG <----> User B - Treating User B and User A as seperate user in a call.
> 
> when user A speaks, Media Gateway should have done like the below.
>   User A ----->MG
>                             ------> User B
> 
> Could anyone throw some light on how to analyze the RTP issue in the above scenario of Gstreamer?
> What debug tools are available to verify Gstreamer pipeline in live call scenario?

Wireshark to check if data is actually flowing (which you already did
and it's apparently not), and using the GStreamer debug log system.

E.g. with GST_DEBUG=2,rtp*:6 you can enable all RTP related debug
output, and then together with the log and the source code you should
be able to trace the packets inside the pipeline and see where things
are going wrong and why.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160116/5b7ae547/attachment.sig>