Anyone familiar with the low level RTSP protocol?

Mickey Lane

Mickey Lane

n3wb
Aug 11, 2017
15
0
I'm writing some code to set up cameras via RTSC. Both of the cameras I have are pretty crappy software wise: Reolink and SV3C. I can get VLC to log the access to both of the cameras OK and I duplicate the OPTIONS transaction exactly as VLC does it. With my code, the SV3C works, the Reolink just hangs after receiving the following:

OPTIONS rtsp://192.168.1.147:554/h264Preview_01_main RTSP/1.0
CSeq: 1

I have compared this to the VLC log eleventy-seven times. It's exact. No different with/without the User-Agent: <blah> line. The CSeq value doesn't seem to matter.

Are there variations on opening sockets? The VLC log doesn't show any of that.

I don't think the Reolink is disconnecting after receiving a command (why would it?) or the recv call would barf.

Any thoughts?
 
I'm not very familiar with the RTSP protocol, unfortunately, but I suggest you do WireShark captures to get the most accurate picture of what is going on when it works versus when it doesn't. It could be something as simple as a missing line break at the end of your request.
 
  • Like
Reactions: Mickey Lane
yes RTSP session are not always the same, you have the UDP/TCP port that can be random
 
bp2008 said:
I'm not very familiar with the RTSP protocol, unfortunately, but I suggest you do WireShark captures to get the most accurate picture of what is going on when it works versus when it doesn't. It could be something as simple as a missing line break at the end of your request.
Click to expand...

That's a good suggestion on the Wireshark. Haven't used that for years.

I'm familiar with the extra line breaks at the end of the messages (same as HTTP). I've tried with several variations. No diff.
 
yes rtsp negociation is on 554 but during negociation camera will tell you ports to use and also you may get a token and also some cameras are buggy because they annouce they could do TCP whenever they cannot (had problem with low cost china Digoo cams).
 
Dodutils said:
yes rtsp negociation is on 554 but during negociation camera will tell you ports to use and also you may get a token and also some cameras are buggy because they annouce they could do TCP whenever they cannot (had problem with low cost china Digoo cams).
Click to expand...

Here's the first bit of the VLC log. This is for the Reolink RLC-410 camera. The 'unauthorized' bit at the end is another thing I know how to deal with. I'm not getting that far yet.

[01ec2604] logger interface: using logger.
[01ec2604] logger interface debug: opening logfile `log.txt'
Opening connection to 192.168.1.147, port 554...
...remote connection opened
Sending request: OPTIONS rtsp://192.168.1.147:554/h264Preview_01_main RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.2.6 (LIVE555 Streaming Media v2016.02.22)


Received 152 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 2
Date: Tue, Aug 29 2017 14:54:35 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARA
METER


Sending request: DESCRIBE rtsp://192.168.1.147:554/h264Preview_01_main RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.2.6 (LIVE555 Streaming Media v2016.02.22)
Accept: application/sdp


Received 175 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 401 Unauthorized
CSeq: 3
Date: Tue, Aug 29 2017 14:54:35 GMT
WWW-Authenticate: Digest realm="LIVE555 Streaming Media", nonce="6d103b17dbfabe0
5e1d9a4ba06e41211"
 
I see you get "RTSP/1.0 401 Unauthorized" here is were you should retry with the good credentials

Can you turn off camera RTSP authentication ? if no you'll have to deal with Basic or Digest Auth (Digest in this case)

You get 401 error because it is the way camera tells you "I want authentication" and then it send you infos about the digest you'll need to use to send back the right "Authorization: Digest" HTTP header's back to camera.
 
Last edited:
Dodutils said:
I see you get "RTSP/1.0 401 Unauthorized" here is were you should retry with the good credentials
Click to expand...

You probably didn't read this part: "The 'unauthorized' bit at the end is another thing I know how to deal with. I'm not getting that far yet."

I'm not getting past "OPTIONS rtsp://192.168.1.147:554/h264Preview_01_main RTSP/1.0"
 
Mickey Lane said:
You probably didn't read this part: "The 'unauthorized' bit at the end is another thing I know how to deal with. I'm not getting that far yet."

I'm not getting past "OPTIONS rtsp://192.168.1.147:554/h264Preview_01_main RTSP/1.0"
Click to expand...

Oh sorry... I am not english native so sometime I missread so the "full log" is the "good VLC" and the very first line is were you get stuck ?

I would recommend you to make a network sniff capture of the VLC session and also your own session, if you are on windows, use Smartsniff (very small and easy for such network capture, much light than Wireshark) and post it here so I can read it.

First set a filter to grab oly 554

upload_2017-8-31_15-42-13.png

You should get something like this

upload_2017-8-31_15-40-35.png

But just in case there are some hidden characters in either VLC (doubt it) or your own code (best bet) you can also switch to Options->Display Mode->Hex Dump and get this

upload_2017-8-31_15-43-13.png
 
Last edited:
  • Like
Reactions: Mickey Lane and bp2008
I set up Wireshark and muddled my way through capturing good and bad. I was having difficulty exporting just the parts I wanted so I just did a screen grab of the interesting parts of the display. Yeah, I know..

Anyway, here is 'good' (VLC) and 'bad' (my code). Aside from the ACK value of 73 (which I have no clue about meaning), everything seems the same. localhost is ..1.77, camera is ..1.47.

good.PNG


bad.PNG
 
[QUOTE="...if you are on windows, use Smartsniff (very small and easy for such network capture, much light than Wireshark) [/QUOTE]

I will try that. I have used Wireshark and found the difference. Now to figure out what it means
 
Mickey Lane said:
I have used Wireshark and found the difference. Now to figure out what it means
Click to expand...

I guess the second capture is your own code and see "Continuation" stick to the end of RTSP/1.0 strange, I don't know in which langage you are coding ... looks like no #0 at the end if you are coding C ;-)

And bout the "Ack", do not look at it as it is part of low level TCP negociation protocol SYN, ACK SYNACK and you definitly do not have to deal with it, it is the System that deal with it.

This is also why I like SmartSniff, it will only show you the DATA and not the low level TCP session control packets.

But when you have to deal with more complex network problems then WireShark become usefull because it can show you the control packets that SmartSniff do not show.
 
Last edited:
  • Like
Reactions: Mickey Lane
bp2008 said:
Your wireshark captures don't show the raw data. SmartSniff looks like it would be easier to get along with.
Click to expand...
Well in fact Wireshark can show it, no problem (including deeper analysis/decsription of the RTSP protocol itself) but as you can see it is not as readable as SmartSniff, this is why I alwasy recommend this small SmartSniff freeware tool (part of excellent NirSoft utilities by the way) that is enough and produce easy/clear readable info when you only need to get the DATA part of the TCP/UDP packets.

upload_2017-8-31_17-10-0.png
 
  • Like
Reactions: Mickey Lane
Problem resolved thanks to several people and tools..

It turns out that Reolink cameras demand \r\n on the end of a line and SV3C works with only \n. Both return \r\n.


SmartSniff bad (#2) and good (#4)
ss bad.PNG

ss good.PNG
 
I had a similar issue writing a simple web server. Running the server on Windows it was fine, but running it on Linux, the WriteLine methods I was using only output a \n instead of \r\n as the protocol demanded. So I figured if it was something like that it would be blatantly obvious in a packet capture.
 
Mickey Lane said:
Problem resolved thanks to several people and tools..
It turns out that Reolink cameras demand \r\n on the end of a line and SV3C works with only \n. Both return \r\n.
Click to expand...

If we stick to the RFC you should always end a header with CRLF not only LF so it is ReoLink that is doing it right and SV3C that is more permissive as the RFC specify only "should be able to handle only LF" and "should" is not "must" ;-)
 
Can I wake this topic up again with a different problem that deals with the same subject?

I send an OPTIONS rtsp message to one camera and get the supported options back. I send it to another camera and get a 'unauthorized' and information for digest authentication. I've got most of it sorted out except the exact algorithm for making the "response=<MD5>" portion of the request.

Here's the Perl function that tries to make the MD5 string:

<pre>
#
#
#
sub views_calc_response_md5_value {

my $realm_no_quotes = shift;
my $nonce = shift;


# HA1 = md5("user:Streaming Server:test") cut 'n paste from some forum
my $ha1 = md5_hex ("$main::account:$realm_no_quotes:$main::password");
print "HA1:\n";
print " Account = $main::account\n";
print " Realm = $realm_no_quotes\n";
print " Password = $main::password\n";
print " MD5 = $ha1\n";

# HA2 = md5("POST:live/my_stream.sdp")
my $method = "DESCRIBE";
my $url;
if (1) {
#
# The variable in main does not have the leading slash
#
$url = "/$main::rtsp_dir";
}
else {
#
# This returns something like "rtsp://192.168.1.149:554/h264Preview_01_main"
#
$url = viewspkg_rtsp_strings::views_sub_set_up_rtsp_url();
}
my $complete_string = "$method:$url";
my $ha2 = md5_hex ($complete_string);
print "HA2:\n";
print " Method = $method\n";
print " Url = $url\n";
print " Complete string = $complete_string\n";
print " MD5 = $ha2\n";
# RESPONSE = md5(HA1+":"+nonce+":"+HA2)
my $ha = md5_hex ("$ha1:$nonce:$ha2");
print "HA: $ha\n";

return $ha;
}

</pre>

and here's the output of the print statements

<pre>
HA1:
Account = admin
Realm = LIVE555 Streaming Media
Password = campw801
MD5 = 0ac7edf1454dc7bc06226124ee9b2ed3
HA2:
Method = DESCRIBE
Url = /h264Preview_01_main
MD5 = 2857f096df41a5e9fbf08bda3662d4bd
HA: 3adca96b01a815542e1896e26da7e06f
</pre>
 
You must log in or register to reply here.
Top Bottom