Re: [MMUSIC] RTSP for data recorder design
"Saylor, Kase J." <kase.saylor@swri.org> Wed, 04 September 2013 16:19 UTC
Return-Path: <kase.saylor@swri.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA71D21E80C9 for <mmusic@ietfa.amsl.com>; Wed, 4 Sep 2013 09:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyxeZnMRek7O for <mmusic@ietfa.amsl.com>; Wed, 4 Sep 2013 09:19:31 -0700 (PDT)
Received: from esg260-1.itc.swri.edu (esg260-1.itc.swri.edu [129.162.252.40]) by ietfa.amsl.com (Postfix) with ESMTP id E44E711E80DE for <mmusic@ietf.org>; Wed, 4 Sep 2013 09:19:30 -0700 (PDT)
Received: from exchmail.swri.org (casht256-1.adm.swri.edu [129.162.243.120]) by esg260-1.itc.swri.edu (8.14.5/8.14.5) with ESMTP id r84GJPVn030007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Sep 2013 11:19:25 -0500
Received: from MBX260-1.adm.swri.edu ([169.254.2.43]) by CASHT256-1.adm.swri.edu ([129.162.243.120]) with mapi id 14.03.0146.000; Wed, 4 Sep 2013 11:19:25 -0500
From: "Saylor, Kase J." <kase.saylor@swri.org>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [MMUSIC] RTSP for data recorder design
Thread-Index: AQHOlGgO7GiKkfk/MkW7mFNV3B7HCZmL/gmAgAAH4wCAAARogIAoT7kAgAHmAAA=
Date: Wed, 04 Sep 2013 16:19:24 +0000
Message-ID: <72859288-FDC7-41A9-AD33-96E56501E13F@swri.org>
References: <862F245D-0795-48E1-8D5A-FEA6A0792D44@swri.org> <5203EABF.2080907@alum.mit.edu> <1383B2A3-D18B-4EC7-87EC-9AE93AE492DA@swri.org> <5D319E1E-0055-408A-8973-E110DFBC9BBD@swri.org> <5225C5DE.5040207@ericsson.com>
In-Reply-To: <5225C5DE.5040207@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [129.162.109.47]
Content-Type: multipart/alternative; boundary="_000_72859288FDC741A9AD3396E56501E13Fswriorg_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-04_06:2013-09-04, 2013-09-04, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=inbound_policy_notspam policy=inbound_policy score=0 kscore.is_bulkscore=9.00339025555752e-10 kscore.compositescore=0 circleOfTrustscore=1.46864835818517 compositescore=0.402580536503537 urlsuspect_oldscore=0.999491384728761 suspectscore=0 recipient_domain_to_sender_totalscore=151 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=218 rbsscore=0.402580536503537 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=-40 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1309040043
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] RTSP for data recorder design
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2013 16:19:35 -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 ksaylor@swri.org<mailto:ksaylor@swri.org> http://tacticalnetworks.swri.org<http://tacticalnetworks.swri.org/> On Sep 3, 2013, at 6:19 AM, Magnus Westerlund <magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>> wrote: 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 <ksaylor@swri.org<mailto:ksaylor@swri.org> <mailto:ksaylor@swri.org>> 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 <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu> <mailto:pkyzivat@alum.mit.edu>> 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 mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org<mailto:mmusic@ietf.org> 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: magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com> ----------------------------------------------------------------------
- Re: [MMUSIC] RTSP for data recorder design Paul Kyzivat
- [MMUSIC] RTSP for data recorder design Saylor, Kase J.
- Re: [MMUSIC] RTSP for data recorder design Saylor, Kase J.
- Re: [MMUSIC] RTSP for data recorder design Paul Kyzivat
- Re: [MMUSIC] RTSP for data recorder design Magnus Westerlund
- Re: [MMUSIC] RTSP for data recorder design Saylor, Kase J.
- Re: [MMUSIC] RTSP for data recorder design Magnus Westerlund
- Re: [MMUSIC] RTSP for data recorder design Saylor, Kase J.
- Re: [MMUSIC] RTSP for data recorder design Magnus Westerlund