Re: [MMUSIC] RTSP for data recorder design

[Paul Kyzivat <[e-mail]>]

Kase,

Based on the additional info below I don't think siprec would fit your 
needs anyway. I'm not involved with RTSP, so I can't comment on that.

	Thanks,
	Paul

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