| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
Hi Scott, Thanks, it does sound like I’m doing it right, then ! I think I ruled out local firewall issues – I knocked up a standalone sockets-based console app which bound to the same ports that I was using for the Flows,
and ran it in the background before launching my reciprocate app. The reciprocate app silently failed to bind to the sockets (lack of reporting this failure might be a bug ?) and my sockets app picked up all the incoming RTP and RTCP packets during call reception,
instead. I will definitely check out the recon use of FlowManager – I might have missed that when I was looking for examples. It’s possible I screwed up whilst grabbing and building the additional dependencies required to compile the reflow project for my embedded platform – reflow
(well, really, the sipX media lib stuff on which it depends) brings in quite a few dependencies not required for the reciprocate core, so the fact that the core resip stack works fine isn’t an indicator of success there. If you have any advice on what versions
of these dependencies to go with, it would be useful. My current plan is to build my code and try it natively on my desktop linux box, using the proper dev packages, to see if it works differently. Debugging it
if it doesn’t work should be easier, and if it does work, then I’ll know there’s a problem in the embedded side. Thanks for your help. Best regards, Jon From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx]
On Behalf Of Scott Godin 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
|