Subject: Re: [MMUSIC] RTSP for data recorder design

From: Magnus Westerlund <[email-masked]>
Date: Tue, 3 Sep 2013 13:19:58 +0200

Hi,

Looking at what you want to do I would say that RTSP could fit the bill.
However, the issue is the level of underspecification existing around
the RECORD usage of RTSP 1.0. We have left record out of RTSP 2.0
because there where no one to drive the use case. It can clearly be
defined as an extension.

In RTSP my understanding the procedure to record a multicast stream the
recording server can receive would be the following. See example in 14.6
of RFC2326:

1. Client does ANNOUNCE with session description.
2. SETUP for each stream to be recorded in same session where transport
header specifies that it is a multicast address to record from.
3. Send RECORD to start recording.

There is a lot of uncertainties from specification point of view how to
do this in RFC2326. RTSP 1.0 is 92 pages and RTSP 2.0 is 320 pages
without specifying recording, but adding some other features. This is an
example of how insufficient as a specification RFC 2326 is. If you think
RTSP is a good match, then perhaps building on RTSP 2.0 defining the
RECORDING functionality is the way for you.

Cheers

Magnus

On 2013-08-08 21:44, 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 <[email-masked]
> <mailto:[email-masked]>> 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 <[email-masked]
>> <mailto:[email-masked]>>
>> 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
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Saylor, Kase J." <[email-masked]>
Date: Wed, 4 Sep 2013 16:19:24 +0000

Magnus,

Thank you so much for your reply. It would seem that RECORD is not function that really got much "traction"and I haven't been able to find any example of an RTSP server that provides the capability. Also, it would seem, that even though the RFC clearly states that RTP is not required, there doesn't seem to be a way to define a transport-protocol other that RTP.

--
Regards,

Kase J. Saylor, PMP
Manager - Tactical Networks &
Communications
Southwest Research Institute
San Antonio, TX
210.522.3703
[email-masked]<mailto:[email-masked]>
http://tacticalnetworks.swri.org<http://tacticalnetworks.swri.org/>

On Sep 3, 2013, at 6:19 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers

Magnus

--
Regards,

Kase Saylor

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

Paul,

--
Regards,

Kase Saylor

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

Kase,

Thanks,
Paul

         v=0

         v=0

   C->S: RECORD

   C->S: RECORD

   C->S: PLAY

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

 list_recorded_data

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

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

   C->S: SETUP

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

   C->S: PLAY

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

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

         v=0

Kase Saylor

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

--

Magnus Westerlund

SE-164 80 Stockholm, Sweden| mailto: [email-masked]<mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 5 Sep 2013 08:51:45 +0200

On 2013-09-04 18:19, Saylor, Kase J. wrote:
> Magnus,
> 
> Thank you so much for your reply. It would seem that RECORD is not
> function that really got much "traction"and I haven't been able to find
> any example of an RTSP server that provides the capability. Also, it
> would seem, that even though the RFC clearly states that RTP is not
> required, there doesn't seem to be a way to define a transport-protocol
> other that RTP. 
> 

I am not surprised that you are not fining implementations of RECORD.

Regarding alternative transport if you look at
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ I hope
you will more clearly see how you can define alternative transports. In
RTSP 1.0 specification the extension points are not explicitly defined
nor have syntax that enables graceful handling of non-supporting agents.

To define a new transport is really the following:

1. Define the transport components that you need. For example IP/UDP/FOO
stack.
2. Give them an identifier to be used in the transport headers,
transport specs.
3. Determine which parameters your transport needs to exchange and how
that is accomplish in the transport header, possibly defining new
transport parameters.
4. Register the necessary parameters and identifiers to avoid collisions
with any other transport.

Cheers

Magnus

> [email-masked] <mailto:[email-masked]>
> http://tacticalnetworks.swri.org <http://tacticalnetworks.swri.org/>
> 
> On Sep 3, 2013, at 6:19 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>> Hi,
>>
>>> <mailto:[email-masked]>
>>>> <mailto:[email-masked]>
>>>>>> unicast;client_port=4588-4589;server_port=6256-6257
>>>>>>
>>> [email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked]>

-- 

Magnus Westerlund

---

From: "Saylor, Kase J." <[email-masked]>
Date: Thu, 5 Sep 2013 14:21:08 +0000

Let me try an example (if you don't mind) to see if I'm following this correctly:

We have a multicast message that get sent on our system (periodic data and event-based data) and we have defined the structure of the datagram. Let's call our defined datagram as FOO (sorry that I'm not being original here). For RTSP 1.0 (I cannot use 2.0 at this time) I would do the following?

transport-protocol  =    "IP"
profile             =    "FOO"
lower-transport     =    "UDP"

    C->S: SETUP rtsp://example.com/foo RTSP/1.0
          CSeq: 302
          Transport: IP/FOO/UDP;multicast;ttl=127;port=5200

    S->C: RTSP/1.0 200 OK
          CSeq: 302
          Date: 23 Jan 1997 15:35:06 GMT
          Session: 47112344
          Transport: IP/FOO/UDP;multicast;
            ttl=127;port=5200

You said something about registering parameters. Where/how would I do that? Thank you again for your time and help :-)
--
Regards,

Kase J. Saylor, PMP

On Sep 5, 2013, at 1:51 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>>
 wrote:

Cheers

Magnus

--
Regards,

Kase J. Saylor, PMP
Manager - Tactical Networks &
Communications
Southwest Research Institute
San Antonio, TX
210.522.3703
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
http://tacticalnetworks.swri.org <http://tacticalnetworks.swri.org/>

On Sep 3, 2013, at 6:19 AM, Magnus Westerlund
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
wrote:

Hi,

Cheers

Magnus

--
Regards,

Kase Saylor

Paul,

--
Regards,

Kase Saylor

Kase,

Thanks,
Paul

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!

question is when I was to add a stream using ANNOUNCE, if I use
the same

        v=0

        v=0

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

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

"path" based upon record start time, could be one way to mark
recording

  C->S: PLAY

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

list_recorded_data

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

  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

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

  C->S: PLAY

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

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

        v=0

Kase Saylor

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

--

Magnus Westerlund

--

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 6 Sep 2013 09:16:15 +0200

On 2013-09-05 16:21, Saylor, Kase J. wrote:
> We have a multicast message that get sent on our system (periodic data
> and event-based data) and we have defined the structure of the datagram.
> Let's call our defined datagram as FOO (sorry that I'm not being
> original here). For RTSP 1.0 (I cannot use 2.0 at this time) I would do
> the following?
> 

The only think missing from the above is the IP address in an
destination parameter.

But, for the above instead of IP/FOO/UDP, it would rather be FOO/UDP. IP
is ommitted here. In RTSP 2.0 we allow a more flexible specification
with more than three levels if needed.

> 
> 
> You said something about registering parameters. Where/how would I do
> that? Thank you again for your time and help :-)

So for the above it would be basically be to register the transport
FOO/UDP. If you have no new parameters you don't need to register anything.

And for RTSP 1.0 there exist no registry for this parameters. Only the
most high level concept has been retrofitted with registries, i.e.
methods, headers, status codes and option tags.

If you are going this direction and you settle on a particular protocol
names and combinations. An email to this list about this at leas allows
us to know that you are using that combination. Possibly you would like
to register this for RTSP 2.0. The relevant registry has the policy of
specification required. See Section 22.13.1 of
draft-ietf-mmusic-rfc2326bis.

Cheers

Magnus Westerlund