| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
Hi, Just to follow on from this. I have an explanation for the behaviour I have seen. Whether I am missing something completely (I don’t think I am) remains to
be seen ! Having rebuilt the code for desktop Linux, the problem (and all the outcomes of diagnosis as described below) was the same. Debugging didn’t yield much additional
info, and, the example use from recon, where the Flows are wrapped in a FlowManagerSipXSocket, and passed off to the sipx media handling, didn’t immediately yield anything. What troubled me, having looked through all the FlowManager/TurnAsyncUdpSocket/TurnAsyncSocket was, that the whole system was event driven off of data becoming
available, such that it could be added to the appropriate rx queue, and the Fake select socket descriptor could be signalled, so the user code could use that to determine data ready. Equally, Flow::receive() / receiveFrom() could never return data unless this
async system was working. What struck me, was that nowhere, in my scenario, was this whole process being kicked off. No asio async operation was being started by the Flow / FlowManager
in the case of UDP without TURN, ie. the most basic transport. Also, there is no public access on the Flow to the one API which could kick this operation off, ie. turnReceive(). If you look at Flow::ActivateFlow(…) you will see in the case of NatTraversal mode, mTurnSocket->connect(…) is called. This ultimately results in TurnAsyncUdpSocket::onConnectSuccess()
being called, which calls turnReceive() and starts the async processing. In the non-NatTraversal case, turnReceive() is not called, which means the async socket processing is never started. This breaks the Flow behaviour completely. I changed Flow::activateFlow(…) to read: else
{ changeFlowState(Ready); mMediaStream.onFlowReady(mComponentId); mTurnSocket->turnReceive(); // <-- JS change } And the RTP Flows now receive data as I would have expected all along. My gut tells me it’s a bug, but it seems so fundamental, that I feel I must have missed
something. This is with reciprocate-1.9.9 from GitHub. Best regards, Jon From: Jon Spyve
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
|