Re: [reSIProcate-users] reflow MediaStream never indicating RTP/RTCP data available on select socket

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

I believe you just need to create an instance of the FlowManager object - it's constructor will run the asio ioService in a dedicated thread (as you have found).  I wonder if you have a local firewall that could be causing your issue.

The recon application is a user of the FlowManager code, you could use it as a reference as well.

Scott

On Tue, Apr 14, 2015 at 3:50 AM, Jon Spyve <jon.spyve@xxxxxxxxxxx> wrote:

Hi,

 

Are there any special considerations for an application using the reflow FlowManager to ensure that RTP data is delivered via the RTP/RTCP flow objects ?

 

I’m evaluating the use of Resiprocate on an embedded ARM linux platform, and have reworked the BasicCall test from DUM to act as a very simple UAS, negotiating codecs with incoming INVITEs and have added a FlowManager and the appropriate createMediaStream call to setup a new media stream.

 

However, polling either the RTP / RTCP Flows via their select sockets (or, indeed, just attempting Flow::receive()) permanently indicates there is no data, despite RTP packets being sent from the calling UAC. This is an SSL build of the stack, but neither SSL nor NAT traversal are being used for the connection, and the UAC and UAS are on the same LAN subnet.

 

Looking through the code, I note the use of asio for async handling, but I also note the presence of a flowmanager::IOServiceThread that appears to take care of the asio::io_service object used internally.

 

If one were to use FlowManager, in the context of a simple application such as BasicCall, is there anything else necessary to expect data to arrive in the 2 Flow objects ?

 

Thanks and best regards,

 

Jon

 

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/