Geek Answers Handbook

How to test a network device for a valid RTSP stream?

I am working on a project that transmits video / audio via RTSP using the VLC Media Player plugin. I would like to provide a network scan option for RTSP cameras. I am sure that this will consist of requesting a list of all network devices and testing for port 554. I can take care of all this. However, as soon as I get to this, how can I check the device through port 554 to make sure it is a valid RTSP camera?

I suppose there must be something in Winsock to be able to do this, but how do I check the socket connection and make sure that it is a valid RTSP stream to which I can connect? Regardless of which method is used, I do not need to try to connect via RTSP to everyone using some kind of authentication. I am looking for a lower level method to determine if port 554 really provides an RTSP stream.

+7
source share
1 answer

There is no reliable way to scan the network for available RTSP streams. You can still do a big search, given the following:

  • To get the best results (as opposed to speed) you will need to search for brute force at available addresses, that is, check the adapter and mask addresses, generate addresses and try one after another in several streams (or asynchronous sockets)
  • You will need port 554 and / or user-provided interactively; real devices (which are hundreds of models) can use different ports, even with default settings
  • You can assign more likely candidates to the top of the list of IP addresses by doing a network search for real addresses using UPnP, ZeroConf
  • If you have specific providers / models, you can also search for specific providers, which usually include sending a UDP broadcast message and listening for a response
  • OPTIONS The RTSP command should be good enough for the test, you can use the interactive RTSP tool to see how it works. In any case, no guarantees exist, since the devices may require authentication.

You have the best chance with OPTIONS to get back anything meaningful anyway. DESCRIBE may require you to log in, you may need to authenticate even for OPTIONS . However, you have an RTSP answer that assumes something exists 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 execute a successful DESCRIBE command and get meaningful results, you need to know the resource URI on the device, which is not always obvious. The best providers (which, obviously, are a minority) flexibly support incoming requests, while others believe that the client is aware of the specifics of the device. 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 the magic of ch0_unicast_secondstream , you are not getting any sense from the device.

+3
source

More articles:


All Articles