[Live-devel] RTSP Server Crash when switching from multicast to unicast

[david.myers at panogenics.com]

Thanks for the advice, I haven't fixed the crash, but I've stopped it
from happening, I think. 

In case anyone else hits this issue, I moved the call to
deleteServerMediaSession() to before the calls to close down the
streams, so my server shutdown code now looks like this:- 

void CRTSPWrapper::RemoveSMS()
{
 streamStream_t *stream = m_StreamArray[m_StreamIndex];
 rtspServer->deleteServerMediaSession(stream->sms);
 if (stream->isMulticast)
 {
 Medium::close(stream->rtcp);
 Medium::close(stream->sink);
 Medium::close(stream->framedSource);
 delete stream->rtcpGroupsock;
 delete stream->rtpGroupsock;
 }
 stream->iRefCount = 0;
 stream->sms = NULL;
 m_RemoveSuccess = 1;
}

David J Myers
AMG Panogenics

>Unfortunately, because the crash is triggered by (though not necessarily occurring in) your own application, which I can't reproduce, you're going to have to be specific about exactly where the crash is occurring, and why. (If you're not already doing so, I suggest replacing the "-O" compile flag with "-g", and running your server under "gdb".)

>> It seems that there is no client session to destroy if the rtp multicast address method is used, neither is the reference count incremented in this case.
> >

>Of course. I suspect that you may be misunderstanding the difference between "rtp://" [1] and "rtsp://" [2] URLs. "rtp://" [1] URLs are non-standard and specific only to VLC; they tell VLC to bind to a particular IP address and port number. This causes no interaction with the server, so (obviously) the server doesn't know when client(s) are listening to the (multicast) stream this way.

>A "rtsp://" [2] URL uses the (IETF standard) RTSP protocol - a unicast protocol (over TCP) that involves contacting the server, and asking the server for details about the stream (a multicast stream, in this case), and how to listen to it.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ [3]

On 2015-04-27 12:52, david.myers at panogenics.com wrote: 

> In order to switch my server implementation from multicast to unicast, I use the following function in my live555 wrapper code to close the current session before re-opening the new session. 
> 
> void CRTSPWrapper::RemoveSMS()
> {
> streamStream_t *stream = m_StreamArray[m_StreamIndex];
> if (stream->isMulticast)
> {
> Medium::close(stream->rtcp);
> Medium::close(stream->sink);
> Medium::close(stream->framedSource);
> delete stream->rtcpGroupsock;
> delete stream->rtpGroupsock;
> }
> rtspServer->deleteServerMediaSession(stream->sms);
> stream->iRefCount = 0;
> stream->sms = NULL;
> m_RemoveSuccess = 1;
> } 
> 
> I'm using VLC as the client to test this and I can connect to my server using a multicast url of the form:- rtp://@224.50.87.90:3000 
> 
> I can also connect using the unicast address form:- rtsp://10.50.87.90:554/stream0 
> 
> I find, if I have a unicast connection to the server and I call the above code to shut it down, I get a segmentation fault in deleteServerMediaSession. I don't get this crash if I connect only via the multicast addressing method. 
> 
> Digging a bit deeper, I'm finding the crash to be in the (RTSPServer.cpp) reclaimStreamStates() function called from the RTSPClientSession destructor. I suspect fStreamStates[i].subsession is not NULL but not legitimate, but I've no idea why not. 
> 
> It seems that there is no client session to destroy if the rtp multicast address method is used, neither is the reference count incremented in this case. 
> 
> Any advice or help would be appreciated. 
> 
> - David J Myers

-------------------------

Unfortunately, because the crash is triggered by (though not necessarily
occurring in) your own application, which I can't reproduce, you're
going to have to be specific about exactly where the crash is occurring,
and why. (If you're not already doing so, I suggest replacing the "-O"
compile flag with "-g", and running your server under "gdb".)

> It seems that there is no client session to destroy if the rtp multicast address method is used, neither is the reference count incremented in this case.
>
Of course. I suspect that you may be misunderstanding the difference
between "rtp://" [1] and "rtsp://" [2] URLs. "rtp://" [1] URLs are
non-standard and specific only to VLC; they tell VLC to bind to a
particular IP address and port number. This causes no interaction with
the server, so (obviously) the server doesn't know when client(s) are
listening to the (multicast) stream this way.

A "rtsp://" [2] URL uses the (IETF standard) RTSP protocol - a unicast
protocol (over TCP) that involves contacting the server, and asking the
server for details about the stream (a multicast stream, in this case),
and how to listen to it.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ [3]
 

Links:
------
[1] rtp://%E2%80%9C
[2] rtsp://%E2%80%9C
[3] http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150430/933517d8/attachment.html>