RTP-Info header is missing

[aklemets]

The RTSP PLAY response does not include the RTP-Info header. This header includes the initial RTP time stamp and sequence number. It is important, the absence of this header can cause interop problems.
Also the Transport header in the SETUP response should include the ssrc parameter (which specifies the SSRC of the RTP packets.)

[RogerHardiman]

Hi.
Thanks for the bug reports.
The RTSPCameraServer was originally a quick proof of concept. I published the code and then forgot about it (I use the library mainly as a client)

I'm having a look at the code and the RFC.
I will either add RTP-Info with just the URL and the Sequence Number, or I'll drop in Range: npt=xxxx- so there is a start time to go with the RTP-Info RtpTimestamp

Are you happy to re-test as I make the changes?

Thanks
Roger

[aklemets]

Yes, that would be great. You are right about the Range header, it also needs to be present in the PLAY response, to be used together with the RTP-Info header. Please let me know when you make these changes, I will give them a try. (No earlier than August 13, though, as I will be on vacation until then.) Thanks, Anders

…

________________________________ From: Roger Hardiman <[email protected]> Sent: Tuesday, July 31, 2018 12:29:27 AM To: ngraziano/SharpRTSP Cc: Anders Klemets; Author Subject: Re: [ngraziano/SharpRTSP] RTP-Info header is missing (#43) Hi. Thanks for the bug reports. The RTSPCameraServer was originally a quick proof of concept. I published the code and then forgot about it (I use the library mainly as a client) I'm having a look at the code and the RFC. I will either add RTP-Info with just the URL and the Sequence Number, or I'll drop in Range: npt=xxxx- so there is a start time to go with the RTP-Info RtpTimestamp Are you happy to re-test as I make the changes? Thanks Roger — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#43 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/Aaa3gsuk8cU1ij1wAenQ7F9YKcmziYQAks5uMAdXgaJpZM4VneBz>.

[RogerHardiman]

First set of fixes done. SSRC is now in Transport.
For RTP-Info I've added in the URL and RTP Sequence Number.
the rtptime is slightly harder. The rtptime comes from a video capture timestamp and I currently don't have access to the timestamps in the thread that handles the PLAY reply. Need to refactor some code first.

[RogerHardiman]

Extra information emailed in by Andres...

I am back from vacation and pulled down the fix that you made to the RTSP server code to advertise the ssrc in the RTSP SETUP response.

I tested my client stack against it, and this part is working fine.

I notice a couple of other problems, however:
(note the *** on the rtptime parameter is to highlight the area of interest)

You are including a “Range: npt=0-“ header in the PLAY response, and this causes an incorrect mapping between RTP timestamps after a PAUSE and subsequent PLAY.

I will explain with this example:

In the response to the first PLAY request, I see these headers:

Range: npt=0-
RTP-Info: url=rtsp://localhost/video.mp4;seq=62814

This is telling me that the RTP packet with sequence number 62814 should be mapped to time 0 in the Media Player’s (NPT) time line. I subsequently receive RTP packet with sequence number 62814. It has RTP time stamp 5623290. So, I establish a mapping between the RTP time line and the NPT time line such that 5623290 maps to 0.

About ten seconds later I send a PAUSE request, and then send a PLAY request again. The response to the second PLAY request has these headers:

Range: npt=0-
RTP-Info: url=rtsp://localhost/video.mp4;seq=3812

This tells me that the RTP packet with sequence number 3812 has NPT time 0. When I receive RTP packet #3812, it has RTP timestamp 6701580. RTP time 6701580 is mapped to NPT time 0.

The problem is, after resuming from paused state, the packet timestamps unexpectedly jump to 0 after applying the RTP->NPT conversion.

To fix this problem, you can include the rtptime parameter in the RTP-Info parameter, and ensure that the mapping between rtptime and the Range header stays constant. So, in the first PLAY response, could include rtptime like this:

Range: npt=0-
RTP-Info: url=rtsp://localhost/video.mp4;seq=62814;**rtptime=5623290**

And in the second PLAY response, you would include rtptime like this:

Range: npt=0-
RTP-Info: url=rtsp://localhost/video.mp4;seq=3812;rtptime=**5623290**

Note that the rtptime value is the same in both cases, because the RTP<->NPT mapping is unchanged. When I receive RTP packet #3812, which as RTP timestamp 6701580, I will map it to NPT as follows: (6701580 – 5623290)/90 + 0 = 11981 milliseconds. Alternatively, you can adjust the value on the Range header and the rtptime header any other way, as long as the mapping stays the same. For example:

Range: npt=**11.981**-
RTP-Info: url=rtsp://localhost/video.mp4;seq=3812;**rtptime=6701580**

I notice that your server responds with “Session: 0”. The value of the session ID on the Session header must be randomly chosen, however, and must be at least 8 characters long. See RFC-2326 section 3.4.

After I close Windows Media Player, the TCP connection to your server is closed, but several minutes later your server is still generating data and is printing that 1 RTSP client is connected. I would expect the server to detect that the TCP socket has been closed. And if it cannot, then it should enforce the RTSP session timeout, which defaults to 60 seconds. If the RTSP client has not sent a RTSP command, such as OPTIONS or GET_PARAMETER in 60 seconds, the server should close the connection.

If you fix any of these issues, I will be happy to test again.

[ikriz]

I'm running Multiple RTSP servers on a single machine (far from optimal) on different ports to provide multiple camera streams, also noticed the client-ports in the UDP transport response were strange. plus the sdp was missing some info:
sdp.Append($"a=control:rtsp://{ipstr}:{Port}/stream/trackID=0\n");

[RogerHardiman]

Hi @ikriz
Thanks for the post.

If you could open a new Issue report about the UDP ports, that would be great.

But for now I'll ask about the "a=control:xxxxx" issue.

RFC 2326 Section C.1.1 tells us that a=control can be an Absolute URL (containing rtsp:// and the server IP address, port and the stream name) or a Relative URL (like what SharpRTSP's demo currently uses, and the RTSP client takes the RTSP address and adds what is in a=control: to the end of it.
This then makes a URL that is used for the SETUP command.

In your post you have swapped this to an Absolute URL.
Did you use the Absolute URL in place of the existing Relative URL or did you add it somewhere else in the SDP?
And can I ask what this fixed (eg what was the RTSP client doing without it).

Then I can understand why the Absolute URL worked when the relative one did not.

Thanks
Roger