Re: [MMUSIC] RTSP for data recorder design

[Paul Kyzivat <[e-mail]>]

Kase,

Its hard to discern your exact requirements. But you should at least 
look at the work in progress by the siprec workgroup. You can find the 
relevant drafts at:

http://datatracker.ietf.org/wg/siprec/

This may not be what you need, but is worth a look.

	Thanks,
	Paul

On 8/8/13 8:49 PM, Saylor, Kase J. wrote:
> 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
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>