[Live-devel] Making RTSP commands work when streaming RTP over TCP

[Matt Schuckmann]

Ah yes now I see how the routing to the correct stream handlers work, 
that's a peace of work. Took me a while to see the statics in 
RTPInterface.cpp and see how all the routing works.

So once I figured that out I started to plumb in a callback so that the 
SocketDescriptor could notify a non RTP entity (i.e. the RTSPClient 
object) that non RTP data had come in. That seemed to be going well 
until I got out to the RTSPClient class and realized that it assumes it 
owns the TCP stream and whenever it sends data it immediately pends on 
the socket for the reply, throwing away any RTP data it encounters while 
waiting (I'm actually puzzled why this doesn't work). This poses a 
problem for my nonRTPCallback solution because the SocketDescriptor in 
the RTPInstance will never get a chance to see the data and do the 
forwarding. I think to make this work we'd have to change the way most 
of the RTSPClient commands work, it would have to be a little more event 
driven, i.e. RTSPClient sends the command then lets the TaskScheduler 
take over when the data arrives the RTPSClient::incomingRequestHandler 
would get called (via a callback from the SocketDescriptor) and the 
RTSPClient could parse the response and notify it's client of the result 
via a callback. This would probably be a breaking change with how 
RTSPClient works now but it would certainly simplify getting this 
feature working. I suppose one could provide 2 RTSPClient classes; the 
current one and a new one that is event driven and works well with 
RTPovertTCP. What would you prefer to see a radical breaking change in 
how RTSPClient works or a second event driven RTSPClient class perhaps 
with the common code between the two re-factored out to a base class? Or 
can you see yet another solution?

So while I debate the merits of changing RTSPClient I went ahead and 
with my original idea of creating a second TCP connection once the first 
is taken over for streaming and by golly it works (with the server mods 
I mentioned before).  I don't have all the kinks and corner cases worked 
out yet but it does work. Would this be something you'd want to have in 
the library.

Thanks,
Matt S.

Ross Finlayson wrote:
>> I'm starting think that the problem is even more insidious than just 
>> RTSP replys don't get recognized by the client. I think the current 
>> implementation prevents multiple streams in the same session from 
>> being received using RTP over TCP, I think I experienced this the 
>> first time I tried it. Does this sound correct?
>
> No, that's not correct.  There is no problem having multiple streams 
> (e.g., audio + video) in a single RTP-over-TCP connection.  (The data 
> format includes a tag which identifies each sub-stream, and our 
> receiving software handles this OK.)
>
>>
>> Is the problem that the RTPSource that is created for the first 
>> stream now owns the TCP socket and it has no way to forward data 
>> that's not for it on to the other interested parties (other 
>> RTPSources and the RTSPClient)?
>
> Basically, yes.