[MMUSIC] RTSP for data recorder design

["Saylor, Kase J." <[e-mail]>]

To Whom it may concern,

I am helping the US Army develop standards for a network recorder on US Army vehicles. We like to use available standards when at all possible, and my research seems to indicate that RTSP would be a great candidate standard. I've been poring over the RTSP specification (along with the SDP standard) and I have your douce code for LiveMedia. However, I still have a few questions concerning the RTSP standard and its use for our particular need. It seems like there is plenty of examples on the Internet for the PLAY method, but not much for RECORD. I really hope that someone may be able to provide some insight that will get me moving in the right direction. On to the questions!

Our recorder requires the ability to "nominate" data streams for recording, so I believe the correct RTSP method is ANNOUNCE. My first question is when I was to add a stream using ANNOUNCE, if I use the same Session number for multiple streams, does this basically create a presentation? For example:

C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0
           CSeq: 3
           Date: 7 Aug 2013 15:35:06 GMT
           Session: 47112344
           Content-Type: application/sdp
           Content-Length: 332

           v=0
           o=- 2890844526 2890845468 IN IP4 192.168.0.123
           s=Threat Stream 1
           i=Threat stream from threat service on the Boomerang
           c=IN IP4 239.192.0.123/127
           t=0 0
           a=unique_id:threat1
   a=data_type:threat
           m=message 12345

(some response back from server)

C->S: ANNOUNCE rtsp://192.168.0.1/mission_recorder RTSP/1.0
           CSeq: 4
           Date: 7 Aug 2013 15:35:07 GMT
           Session: 47112344
           Content-Type: application/sdp
           Content-Length: 332

           v=0
           o=- 2890844527 2890845471 IN IP4 192.168.0.123
           s=Position Stream 1
           i=Position stream from position service
           c=IN IP4 239.192.0.124/127
           t=0 0
           a=unique_id:pos1
   a=data_type:position
           m=message 12346
(some response back from server)

Based upon these two announce messages, is it safe to assume that the following command would cause the recorder to start recording those two data streams (assuming the current date/time is 8/4/2013 1530 GMT)?

     C->S: RECORD rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
           CSeq: 5
           Content-Type: text/parameters
           Session: 47112344
   Range: clock=20130804T153000Z-

Furthermore, would the following command stop the recorder (assuming the current date/time is 8/4/2013 1532 GMT)? I didn't see anywhere in the RFC for stopping a recording.

     C->S: RECORD rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
           CSeq: 6
           Content-Type: text/parameters
           Session: 47112344
   Range: clock=- 20130804T153200Z


I apologize but I have at least one or two more questions ;-) After tearing down a session, how would one go back and playback recorded data? From my RECORD example I've assumed that providing a URI with a "path" based upon record start time, could be one way to mark recording events. Do you think this is an acceptable approach? Then the play command would something like:

     C->S: PLAY rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
           CSeq: 6
           Content-Type: text/parameters
           Session: 1234567

I suppose I could specify unique parameters and use the GET_PARAMETER method to list the available recordings. Perhaps something like:

     C->S: SETUP rtsp://192.168.0.1/mission_recorder RTSP/1.0
           CSeq: 1
   Transport: unicast;client_port=4588-4589

     S->C: RTSP/1.0 200 OK
           CSeq: 1
   Date: 5 Aug 2013 11:15:07 GMT
           Session: 1234567
           Transport: unicast;client_port=4588-4589;server_port=6256-6257

     C->S: GET_PARAMETER rtsp://192.168.0.1/mission_recorder RTSP/1.0
           CSeq: 7
           Content-Type: text/parameters
           Session: 1234567
           Content-Length: 15

   list_recorded_data


     S->C: RTSP/1.0 200 OK
           CSeq: 7
   Date: 5 Aug 2013 11:15:10 GMT
           Content-Length: 46
           Content-Type: text/parameters

           list_recorded_data:20130804T153000Z,20130804T213000Z

     C->S: TEARDOWN rtsp://192.168.0.1/mission_recorder RTSP/1.0
           CSeq: 8
   Session: 1234567

     S->C: RTSP/1.0 200 OK
           CSeq: 8


Then we'd specify the proper way to interpret the response from the server and open up a new RTSP session to playback the recorded data. For example:

     C->S: SETUP rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
           CSeq: 1
   Transport: multicast;client_port=4588-4589

     S->C: RTSP/1.0 200 OK
           CSeq: 1
   Date: 6 Aug 2013 11:15:07 GMT
           Session: 7654321
           Transport: multicast;client_port=4588-4589;server_port=6256-6257

     C->S: PLAY rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
           CSeq: 2
           Content-Type: text/parameters
           Session: 7654321

     S->C: RTSP/1.0 200 OK
           CSeq: 2
   Date: 6 Aug 2013 11:15:10 GMT

Okay, last question, would the DESCRIBE method for rtsp://192.168.0.1/mission_recorder/20130804T153000Z be expected to describe the "streams" that were recorded? In other words could the following be expected?

C->S: DESCRIBE rtsp://192.168.0.1/mission_recorder/20130804T153000Z RTSP/1.0
           CSeq: 312
           Accept: application/sdp, application/rtsl, application/mheg

S->C: RTSP/1.0 200 OK
           CSeq: 312
           Date: 7 Aug 2013 15:35:07 GMT
           Content-Type: application/sdp
           Content-Length: 332

           v=0
           o=- 2890844527 2890845471 IN IP4 192.168.0.123
           s=Position Stream 1
           i=Threat stream from threat service on the Boomerang
           c=IN IP4 239.192.0.124/127
           t=0 0
           a=unique_id:pos1
   a=data_type:position
           m=message 12346
   s=Position Stream 1
           i=Position stream from position service
           c=IN IP4 239.192.0.124/127
           t=0 0
           a=unique_id:pos1
   a=data_type:position
           m=message 12346

I really have no idea how multiple streams would be described!

Thanks in advance for any help!
--
Regards,

Kase Saylor
Southwest Research Institute