Re: [MMUSIC] RTSP for data recorder design

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

Paul,

Thanks for the link for siprec, unfortunately I am looking for a current IETF RFC that could be used. As siprec is informational at this time, it's not really an option. I think I'm pretty close with RTSP, but there's just a few things that I haven't sorted out. Perhaps I'll try to condense my confusing email into something a little bit more concise. Here we go:

1. I have data sources that provide data primarily as "streams" of multicast datagrams. We have specified the format of those datagrams, and we now need a way to record them so that they can be retrieved at a later time.

2. We have created a SOAP-based (role you own) interface that would provide the needed functionality, but if I could accomplish that functionality with RTSP, that would be better for the overall community.

3. I need the following functionality:
a. Nominate certain (or all) multicast streams for recording (I assume ANNOUNCE would be the way to do that)
b. Record said streams whenever needed
c. Allow a client to find out what streams are available
d. Allow the client to playback those streams

So my first questions was about "adding" streams to a session. After much rambling and attempts to provide example RTSP communications between client and server, my last question was about how, using DESCRIBE, would I be able to show all the streams that were in a single session (based upon the assumption that multiple data streams could be group under one session).

Does this at all help clear up my original post? Thanks again for your time and help.

--
Regards,

Kase Saylor
Southwest Research Institute

On Aug 8, 2013, at 2:28 PM, Kase Saylor <[e-mail]<mailto:[e-mail]>> wrote:

Paul,

Thanks for the link for siprec, unfortunately I am looking for a current IETF RFC that could be used. As siprec is informational at this time, it's not really an option. I think I'm pretty close with RTSP, but there's just a few things that I haven't sorted out. Perhaps I'll try to condense my confusing email into something a little bit more concise. Here we go:

1. I have data sources that provide data primarily as "streams" of multicast datagrams. We have specified the format of those datagrams, and we now need a way to record them so that they can be retrieved at a later time.

2. We have created a SOAP-based (role you own) interface that would provide the needed functionality, but if I could accomplish that functionality with RTSP, that would be better for the overall community.

3. I need the following functionality:
a. Nominate certain (or all) multicast streams for recording (I assume ANNOUNCE would be the way to do that)
b. Record said streams whenever needed
c. Allow a client to find out what streams are available
d. Allow the client to playback those streams

So my first questions was about "adding" streams to a session. After much rambling and attempts to provide example RTSP communications between client and server, my last question was about how, using DESCRIBE, would I be able to show all the streams that were in a single session (based upon the assumption that multiple data streams could be group under one session).

Does this at all help clear up my original post? Thanks again for your time and help.

--
Regards,

Kase Saylor
Southwest Research Institute


On Aug 8, 2013, at 2:00 PM, Paul Kyzivat <[e-mail]<mailto:[e-mail]>>
wrote:

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


_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic