No RTP data #14

lattice0 · 2019-01-27T06:31:33Z

I'm trying to save a video from my vstarcam camera and I'm gettind this "no such media session" error. Could it be a bug in the camera's RTSP server?

 ./common_example rtsp://admin:[email protected]:10554/tcp/av0_0
Start play rtsp://admin:[email protected]:10554/tcp/av0_0
Then put video data into test_packet_recv.h264
connect error: Network is unreachable
connect error: Network is unreachable
connect error: Network is unreachable
/av0_0/av0_0start PLAY
SDP: 
GetMediaData: No such media session
GetMediaData: No such media session
GetMediaData: No such media session
GetMediaData: No such media session
GetMediaData: No such media session
...
GetMediaData: No such media session
GetMediaData: No such media session
start TEARDOWN
lz@vm:~/myRtspClient/example$

The text was updated successfully, but these errors were encountered:

lattice0 · 2019-01-27T07:04:25Z

I've inspected the packets with wireshark and I discovered that if I put the username and password before, like I did, no packet is sent to the IP. If I take it off, some packets are sent (TCP SYN/ACK I guess) but nothing more happens (I think the ack fails) and I get the same output as above

lattice0 · 2019-01-27T07:12:55Z

Ok I figured out I was using common_example which opens a HTTP fowarder. I tried complete_example and it showed a bunch of RTSP information from the camera, but in the end it does:

MyRTP_SetUp TCP: 0
Setup Session audio: MyRtsp: Success
MyRTP_SetUp TCP: 0
Setup Session video: MyRtsp: Success
RTSP/1.0 200 OK
Cseq: 5
Date: Sun, Jan 27 2019 07:10:47 GMT
Session: 879472606819128155
Transport: RTP/AVP;unicast;client_port=10332-10333;server_port=52936-52937


start PLAY
RTSP/1.0 200 OK
Cseq: 6
Date: Sun, Jan 27 2019 07:10:47 GMT
Session: 879472606819128155


No RTP data
No RTP data
No RTP data
No RTP data
No RTP data
No RTP data
No RTP data
try_times > 5
start TEARDOWN
RTSP/1.0 200 OK
Cseq: 8
Date: Sun, Jan 27 2019 07:10:54 GMT

However while it does this, I can see a lot of packets coming from the camera, which are certainly RTP packets

lattice0 · 2019-01-27T07:28:39Z

Here's the entire thing:

./complete_example rtsp://admin:[email protected]:10554/tcp/av0_0
Start play rtsp://admin:[email protected]:10554/tcp/av0_0
Then put video data into test_packet_recv.h264
RTSP/1.0 200 OK
Cseq: 1
Date: Sun, Jan 27 2019 07:17:16 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER


RTSP/1.0 200 OK
Cseq: 3
Date: Sun, Jan 27 2019 07:17:16 GMT
Content-Type: application/sdp
Content-Length: 402


v=0
o=VSTC 3757562112 3757562112 IN IP4 192.168.1.72
s=streamed by the VSTARCAM RTSP server
e=NONE
c=IN IP4 0.0.0.0
t=0 0
m=video 0 RTP/AVP 96
b=AS:1536
a=control:track0
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4d002a;sprop-parameter-sets=Z00AKp2oHgCJ+WbgICAoAAADAAgAAAMAfCA=,aO48gA==
m=audio 0 RTP/AVP 8	 
b=AS:64
a=control:track1
a=rtpmap:8 PCMA/8000/1


MyRTP_SetUp TCP: 0
Setup Session audio: MyRtsp: Success
MyRTP_SetUp TCP: 0
Setup Session video: MyRtsp: Success
RTSP/1.0 200 OK
Cseq: 5
Date: Sun, Jan 27 2019 07:17:16 GMT
Session: 8845803257451614577
Transport: RTP/AVP;unicast;client_port=10332-10333;server_port=59014-59015


start PLAY
RTSP/1.0 200 OK
Cseq: 6
Date: Sun, Jan 27 2019 07:17:16 GMT
Session: 8845803257451614577


No RTP data
No RTP data
No RTP data
No RTP data
No RTP data
No RTP data
No RTP data
try_times > 5
start TEARDOWN
RTSP/1.0 200 OK
Cseq: 8
Date: Sun, Jan 27 2019 07:17:23 GMT

Ansersion · 2019-01-28T02:42:48Z

Could you do me a favour by sending the packets captured by wireshark to [email protected]?
I will try to find the problem.

lattice0 · 2019-01-28T02:51:52Z

Thanks, I've just sent you. I'm also trying to figure out where the problem comes from but I'm having to learn the interns of the library first

lattice0 · 2019-01-28T02:58:46Z

I've sent you some weird open vpn captures, I don't know why it made this way. I've just sent you the correct one now, which shows the RTSP messages clearly

lattice0 · 2019-01-28T03:00:15Z

Sorry, I think both the captures include Open VPN

Just pick the last one I sent and add the filter

ip.addr==192.168.1.72

which is the IP of my camera

thank you and sorry for the confusion

lattice0 · 2019-01-28T04:12:32Z

I've found something important.

MyRTPUDPSession::GetMyRTPData

gets called, not the TCP version. But I remember these cameras working in TCP only. I think the program is trying to listen for UDP RDP packets but the camera is sending TCP ones.

I'm still strying to find where the program decides if the camera uses TCP or UDP

lattice0 · 2019-01-28T04:22:21Z

I also noticed the line

Transport: RTP/AVP;unicast;client_port=10330-10331;server_port=39110-39111

but not coming from the camera to the ports 10330, 10331, 39110, 39111 (don't know which one it was supposed to be).

Looks like the camera isn't sending RTP packets to these ports. The only port the camera communicates with is the one used to send the initial RTSP message.

So I guess these are the 2 problems: one is that the session being open by the program is a UDP one, and the other is that the camera isn't sending RTP packets to the ports it said it would.

Now I need to determine why, because this camera works with other RTSP libraries (at least it works with tinyCamMonitor on Android)

Ansersion · 2019-01-28T04:37:11Z

“Transport of RTP over TCP can be done in two ways: over independent TCP connections using [RFC4571] or interleaved in the RTSP connection”(https://tools.ietf.org/html/rfc7826#page-279)

Maybe it use RTSP-over-http (https://opensource.apple.com/source/QuickTimeStreamingServer/QuickTimeStreamingServer-412.42/Documentation/RTSP_Over_HTTP.pdf) which myRtspClient implemented.
Or some other way myRtspClient doesn't support. Maybe you could capture the packets from tinyCamMonitor to get more info. And send me a copy by the way.

lattice0 · 2019-01-28T04:54:38Z

I just captured tinyCamMonitor traffic and it's very similar to the traffic seen by your program. It is simply sending the packets through TCP, but to the same port it used for RTSP.

please filter it by doing

ip.addr==192.168.0.100

I'm sending the firefox send link through email (the archive is heavy now because it contains the video)

Ansersion · 2019-01-28T15:51:36Z

After looking into the RTSP packets, I found it had nothing to do with TCP. Maybe it's the upper layer protocol(ONVIF) that determines TCP or UDP which I know little about. I'll implements the feature soon.
There is a trick that may work it out.
Replace the line 80-94 in example/http_tunnel_example.cpp with:
Client.SetHttpTunnelPort(10554);
Client.SetPort(10554);
/*
if(RTSP_NO_ERROR == Client.DoRtspOverHttpGet()) {
cout << "DoGet OK" << endl;
}
cout << Client.GetResource();
if(RTSP_NO_ERROR == Client.DoRtspOverHttpPost()) {
cout << "DoPost OK" << endl;
}
*/

// /* Set rtsp access username */
Client.SetUsername("admin");

// /* Set rtsp access password */
Client.SetPassword("123456");

Replace line 1525 in myRtspClient/rtspClient.cpp with:
// char * encodedBytes = base64Encode(msg.c_str(), msg.length());
char * encodedBytes = msg.c_str();

lattice0 · 2019-01-28T18:11:21Z

I got this error:

rtspClient.cpp:1526:32: error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
 char * encodedBytes = msg.c_str();        if(NULL == encodedBytes) {

Could you explain what you found to be the problem? Maybe I can help add this feature. I didn't understand what you meant by 'it had nothing to do with TCP' and then you suggest the problem is that ONVIF determines what is TCP.

What feature you talking about implementing?

Ansersion · 2019-01-29T01:41:42Z

I am so sorry that I made it unclear. You can change the function like this(start from line 1522 in rtspClient.cpp):
ErrorType RtspClient::SendRTSP(int fd, uint16_t http_tunnel_port, string msg)
{
if(http_tunnel_port != 0) {
// char * encodedBytes = base64Encode(msg.c_str(), msg.length());
// if(NULL == encodedBytes) {
// Close(fd);
// return RTSP_SEND_ERROR;
// }
if(RTSP_NO_ERROR != SendRTSP(fd, msg)) {
Close(fd);
// delete[] encodedBytes;
return RTSP_SEND_ERROR;
}
// delete[] encodedBytes;
} else {
if(RTSP_NO_ERROR != SendRTSP(fd, msg)) {
Close(fd);
return RTSP_SEND_ERROR;
}
}
return RTSP_NO_ERROR;
}

Just like you found above, the library expects UDP packets but get TCP ones. The tinyCamMonitor works fine because when it sends RTSP "SETUP" it says "give me TCP"(Transport: RTP/AVP/TCP;unicast;interleaved=0-1):
SETUP rtsp://192.168.0.100:10554/tcp/av0_0/track0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
CSeq: 4
User-Agent: Live555
Authorization: Digest username="admin", realm="RTSPD", nonce="p802ob37bpq0t94522r6592vg0an7m78", uri="rtsp://192.168.0.100:10554/tcp/av0_0/track0", response="b5e1af68d80abb501711e73cff1e54fe"
Maybe you can look into RtspClient::DoSETUP(rtspClient.cpp line 493) to find more info.

I don't know why tinyCamMonitor knows it has to use TCP, not UDP. Maybe ONVIF tells it.
MyRtspClient also supported RTP over TCP, but only compatible with https://opensource.apple.com/source/QuickTimeStreamingServer/QuickTimeStreamingServer-412.42/Documentation/RTSP_Over_HTTP.pdf.

If you want it works in your situation, you could try the code above.

lattice0 · 2019-01-29T02:01:26Z

With the modification you suggested, the camera traffic stops after the RTSP describe, when I try the http tunnel example. If the problem is that I'm getting UDP packets, why did you suggest to use an http tunnel?

Also, I figured out before that the problem was that the program was creating a MyRTPUDPSession. I tried modifying from line 97 of MediaSession.cpp, the following:

    if(tunnelling_sock > 0) {
		RTPInterface = new MyRTPTCPSession;
	    if(!RTPInterface->MyRTP_SetUp(this, tunnelling_sock)) return MEDIA_SESSION_ERROR;
    } else {
		RTPInterface = new MyRTPUDPSession;
	    if(!RTPInterface->MyRTP_SetUp(this)) return MEDIA_SESSION_ERROR;
    }

to

if(tunnelling_sock > 0 || true) {
  	RTPInterface = new MyRTPTCPSession;
      if(!RTPInterface->MyRTP_SetUp(this, tunnelling_sock)) return MEDIA_SESSION_ERROR;
  } else {
  	RTPInterface = new MyRTPUDPSession;
      if(!RTPInterface->MyRTP_SetUp(this)) return MEDIA_SESSION_ERROR;
  }

which effectively created a MyRTPTCPSession instead of MyRTPUDPSession, but the problem persisted. Shouldn't this be the only modification needed?

I want to help in making Vstarcam cameras compatible because they're the top seller in aliexpress, so it'd be great for this library, and I'm also thinking in bulding something on top of this library (which will be open source of course)

Ansersion · 2019-01-29T02:28:23Z

Http tunnelling is the only situation that MyRtspClient use TCP. But it creates two sockets for sending and receiving respectively, which is not compitable with the camera that only use one socket. I will try to add this feature soon.

lattice0 · 2019-01-29T03:38:02Z

Ok, thank you for your help.

If I understood right, it's all a matter of using

int Create (const RTPSessionParams &sessparams, const RTPTransmissionParams *transparams=0, RTPTransmitter::TransmissionProtocol proto=RTPTransmitter::IPv4UDPProto)

when creating the object RTPInterface. And then passing a custom RTPTransmitter which will use the socket already created for out RtspClient. We'd have to implement some methods of the RTPTransmitter so data gets sent the right way through the socket.

Then we need to create a rule for RtspClient to know that some cameras (mine) need this custom transporter (how should we do that?)

Am I right? I could kinda implement that, or at least help you. I'm very intersted in helping make this library compatible with lots of cameras because live555 is a giant mess and I really want to use this to make a cool NVR for my cameras

Ansersion · 2019-01-29T07:35:47Z

Just now, I commit some code for trial. You can look into common_example.cpp for help. The key is DoSETUP.

lattice0 · 2019-01-29T18:36:51Z

Thank you. I just sent you the wireshark capture of me using the http tunneling example but I've just read and you tell me to use common_example. I get

lz@vm:~/myRtspClient/example$ ./common_example rtsp://admin:[email protected]:10554/tcp/av0_0
Start play rtsp://admin:[email protected]:10554/tcp/av0_0
Then put video data into test_packet_recv.h264
connect error: Network is unreachable
start PLAY
SDP: 
GetMediaData: No such media session
GetMediaData: No such media session
GetMediaData: No such media session

lattice0 · 2019-01-29T18:43:22Z

Well, I've exchanged the first lines of complete example with common example and it worked, I got an image. It is a little buggy in the end though: https://imgur.com/a/rKlTmXi

(please ignore my last email with the wireshark capture)

Do you know why the image is like that?

Ansersion · 2019-01-30T02:11:51Z

Maybe you can try to enlarge the buffer, please refer to issue #6

h1uke · 2019-05-08T12:17:51Z

I am also getting a "No RTP Data" on certain types of AXIS cameras running latest firmware, but the cause for this looks different than the one discussed above.

Console output:

./common_example rtsp://10.10.9.105/axis-media/media.amp
Start play rtsp://10.10.9.105/axis-media/media.amp
Then put video data into test_packet_recv.h264
debug: mt=video,line=rtpmap:96 H264/90000
debug: mt=video,line=fmtp:96 packetization-mode=1;profile-level-id=4d0029;sprop-parameter-sets=Z00AKeKQCgC3YC3AQEBpB4kRUA==,aO48gA==
debug: mt=video,line=control:rtsp://10.10.9.105/axis-media/media.amp/stream=0
debug: mt=video,line=framerate:5.000000
debug: mt=video,line=transform:1.000000,0.000000,0.000000;0.000000,1.000000,0.000000;0.000000,0.000000,1.000000
debug: mt=audio,line=rtpmap:97 MPEG4-GENERIC/16000/1
debug: mt=audio,line=fmtp:97 streamtype=5;profile-level-id=2;mode=AAC-hbr;config=1408;sizelength=13;indexlength=3;indexdeltalength=3;bitrate=64000
debug: mt=audio,line=control:rtsp://10.10.9.105/axis-media/media.amp/stream=1
MediaInfoCheck: 0
MyRTP_SetUp TCP: 3
Adding destination
start PLAY
SDP: v=0
o=- 12517865589777074219 1 IN IP4 10.10.9.105
s=Session streamed with GStreamer
i=rtsp-server
t=0 0
a=tool:GStreamer
a=type:broadcast
a=range:npt=now-
a=control:rtsp://10.10.9.105/axis-media/media.amp
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:50000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4d0029;sprop-parameter-sets=Z00AKeKQCgC3YC3AQEBpB4kRUA==,aO48gA==
a=control:rtsp://10.10.9.105/axis-media/media.amp/stream=0
a=framerate:5.000000
a=transform:1.000000,0.000000,0.000000;0.000000,1.000000,0.000000;0.000000,0.000000,1.000000
m=audio 0 RTP/AVP 97
c=IN IP4 0.0.0.0
b=AS:64
a=rtpmap:97 MPEG4-GENERIC/16000/1
a=fmtp:97 streamtype=5;profile-level-id=2;mode=AAC-hbr;config=1408;sizelength=13;indexlength=3;indexdeltalength=3;bitrate=64000
a=control:rtsp://10.10.9.105/axis-media/media.amp/stream=1

No RTP data
No RTP data
No RTP data
^C

RTSP handshake captured by Wireshark:

DESCRIBE rtsp://10.10.9.105/axis-media/media.amp RTSP/1.0
CSeq: 1

RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Base: rtsp://10.10.9.105/axis-media/media.amp/
Server: GStreamer RTSP server
Date: Tue, 23 Apr 2019 11:14:14 GMT
Content-Length: 854

v=0
o=- 12517865589777074219 1 IN IP4 10.10.9.105
s=Session streamed with GStreamer
i=rtsp-server
t=0 0
a=tool:GStreamer
a=type:broadcast
a=range:npt=now-
a=control:rtsp://10.10.9.105/axis-media/media.amp
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:50000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4d0029;sprop-parameter-sets=Z00AKeKQCgC3YC3AQEBpB4kRUA==,aO48gA==
a=control:rtsp://10.10.9.105/axis-media/media.amp/stream=0
a=framerate:5.000000
a=transform:1.000000,0.000000,0.000000;0.000000,1.000000,0.000000;0.000000,0.000000,1.000000
m=audio 0 RTP/AVP 97
c=IN IP4 0.0.0.0
b=AS:64
a=rtpmap:97 MPEG4-GENERIC/16000/1
a=fmtp:97 streamtype=5;profile-level-id=2;mode=AAC-hbr;config=1408;sizelength=13;indexlength=3;indexdeltalength=3;bitrate=64000
a=control:rtsp://10.10.9.105/axis-media/media.amp/stream=1
//////////////////////////////////////
SETUP rtsp://10.10.9.105/axis-media/media.amp/stream=0 RTSP/1.0
Transport: RTP/AVP/TCP;interleaved=0-1
CSeq: 2

RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6CDEFDFB;mode="PLAY"
Server: GStreamer RTSP server
Session: 617suw+aMAmF7a3m; timeout=60
Date: Tue, 23 Apr 2019 11:14:14 GMT
/////////////////////////////////////
PLAY rtsp://10.10.9.105/axis-media/media.amp RTSP/1.0
CSeq: 3
Session: 617

RTSP/1.0 454 Session Not Found
CSeq: 3
Server: GStreamer RTSP server
Date: Tue, 23 Apr 2019 11:14:14 GMT
///////////////////////////

An attempt to narrow it down:

the camera sets up a non-numeric session name which cannot be correctly parsed, this causes the next PLAY command to fail
a '454 Session Not Found' camera response is not interpreted correctly: the App should not proceed after this, but it does

Ansersion · 2019-05-09T01:43:17Z

Thanks.
It's rfc7826(charpter 4.3) which makes rfc2326(charpter 3.4) obsoleted.
I just modified it.

lattice0 changed the title ~~GetMediaData: No such media session~~ No RTP data Jan 27, 2019

Ansersion mentioned this issue Mar 1, 2019

No RTP data #18

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

No RTP data #14

No RTP data #14

lattice0 commented Jan 27, 2019

lattice0 commented Jan 27, 2019

lattice0 commented Jan 27, 2019

lattice0 commented Jan 27, 2019

Ansersion commented Jan 28, 2019

lattice0 commented Jan 28, 2019

lattice0 commented Jan 28, 2019

lattice0 commented Jan 28, 2019

lattice0 commented Jan 28, 2019

lattice0 commented Jan 28, 2019

Ansersion commented Jan 28, 2019

lattice0 commented Jan 28, 2019

Ansersion commented Jan 28, 2019 •

edited

Loading

lattice0 commented Jan 28, 2019

Ansersion commented Jan 29, 2019

lattice0 commented Jan 29, 2019

Ansersion commented Jan 29, 2019

lattice0 commented Jan 29, 2019

Ansersion commented Jan 29, 2019

lattice0 commented Jan 29, 2019

lattice0 commented Jan 29, 2019

Ansersion commented Jan 30, 2019

h1uke commented May 8, 2019

Ansersion commented May 9, 2019

No RTP data #14

No RTP data #14

Comments

lattice0 commented Jan 27, 2019

lattice0 commented Jan 27, 2019

lattice0 commented Jan 27, 2019

lattice0 commented Jan 27, 2019

Ansersion commented Jan 28, 2019

lattice0 commented Jan 28, 2019

lattice0 commented Jan 28, 2019

lattice0 commented Jan 28, 2019

lattice0 commented Jan 28, 2019

lattice0 commented Jan 28, 2019

Ansersion commented Jan 28, 2019

lattice0 commented Jan 28, 2019

Ansersion commented Jan 28, 2019 • edited Loading

lattice0 commented Jan 28, 2019

Ansersion commented Jan 29, 2019

lattice0 commented Jan 29, 2019

Ansersion commented Jan 29, 2019

lattice0 commented Jan 29, 2019

Ansersion commented Jan 29, 2019

lattice0 commented Jan 29, 2019

lattice0 commented Jan 29, 2019

Ansersion commented Jan 30, 2019

h1uke commented May 8, 2019

Ansersion commented May 9, 2019

Ansersion commented Jan 28, 2019 •

edited

Loading