Question

I am working on a project which streams video/audio through RTSP using VLC Media Player plugin. I would like to provide an option to scan the network for RTSP cameras. I’m sure this will consist of querying a list of all network devices, and testing for port 554. All this I can take care of. However, once I have gotten this far, how do I test the device through port 554 to make sure it’s a valid RTSP camera?

I’m assuming there should be something in Winsock to be able to do this, but how should I test a socket connection and make sure it’s a valid RTSP stream which I can connect to? Whatever method is used, I shouldn’t have to attempt to connect via RTSP to each using any sort of authentication, I’m looking for a lower-level way of determining if the port 554 is actually providing an RTSP stream.

Answer 1

There is no reliable way to scan network for available RTSP streams. You can still do a great searching considering the following:

1. For best findings (as opposed to speed) you will need to do a brute force search on available addresses, that is checking adapeter addresses and masks, generating addresses and trying one by one in multiple threads (or async sockets)
2. You will want port 554 and/or provided by user interactively; real devices (which a hundreds of models) might be using different ports, even with default settings
3. You can put more likely candidates onto top of the IP address list by searching network for real addresses using UPnP, ZeroConf
4. Having specific vendors/models in mind you can also implement vendor-specific searches, which typically involve sending broadcast UDP message and listening for response
5. OPTIONS RTSP command should be good enough for a test, you can use interactive RTSP tool to see how it works. There are no guarantees of any kind anyways since devices might require that you authenticate.

You have most chances with OPTIONS to receive back anything meaningful anyway. DESCRIBE might already require that you log in, you might have to authenticate even for OPTIONS. Still you have RTSP response that assumes that something exists over there.

Connection to 192.168.0.59:554 using TCP

OPTIONS * RTSP/1.0
CSeq: 1

RTSP/1.0 401 Unauthorized
CSeq: 1
Date: Tue, Oct 16 2012 22:22:53 GMT
WWW-Authenticate: Basic realm="RTSP/RTP stream"

To issue a successful DESCRIBE command and receive meaningful results, you need to know resource URI on the device which is not always obvious. Better vendors (who are obviously a minority) support incoming requests flexibly, other assume the client is aware of device specific. For example,

Connection to 192.168.0.59:554 using TCP

OPTIONS * RTSP/1.0
CSeq: 1

RTSP/1.0 200 OK
CSeq: 1
Date: Tue, Oct 16 2012 22:26:54 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE

DESCRIBE rtsp://192.168.0.59/ch0_unicast_secondstream RTSP/1.0
CSeq: 2
Accept: application/sdp

RTSP/1.0 200 OK
CSeq: 2
Date: Tue, Oct 16 2012 22:27:22 GMT
Content-Base: rtsp://192.168.0.59/ch0_unicast_secondstream/
Content-Type: application/sdp
Content-Length: 506

v=0
o=- 1350426392586736 1 IN IP4 192.168.0.59
s=Session of second stream
i=Second Codec Stream
t=0 0
a=tool:LIVE555 Streaming Media v2007.08.03
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:Session of second stream
a=x-qt-text-inf:Second Codec Stream
m=video 0 RTP/AVP 26
c=IN IP4 0.0.0.0
a=control:track1
m=audio 0 RTP/AVP 97
c=IN IP4 0.0.0.0
a=rtpmap:97 PCMU/16000
a=control:track2
m=metadata 0 RTP/AVP 98
c=IN IP4 0.0.0.0
a=rtpmap:98 METADATA/64000
a=control:track3

DESCRIBE rtsp://192.168.0.59 RTSP/1.0
CSeq: 3
Accept: application/sdp

RTSP/1.0 404 Stream Not Found
CSeq: 3
Date: Tue, Oct 16 2012 22:27:29 GMT

Note that without knowing magic ch0_unicast_secondstream you don’t get anything making much sense from the device.