IETF Logo Mail Archive

Re: [MMUSIC] Replay in RTSP?

Ross Finlayson <finlayson@live555.com> Wed, 10 January 2024 21:22 UTC

Return-Path: <finlayson@live555.com>
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 61AF6C14CF15 for <mmusic@ietfa.amsl.com>; Wed, 10 Jan 2024 13:22:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AO0dDwZI3d8 for <mmusic@ietfa.amsl.com>; Wed, 10 Jan 2024 13:22:06 -0800 (PST)
Received: from us.live555.com (us.live555.com [52.8.240.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B224C14F60E for <mmusic@ietf.org>; Wed, 10 Jan 2024 13:22:05 -0800 (PST)
Received: from smtpclient.apple (localhost.live555.com [IPv6:0:0:0:0:0:0:0:1]) by us.live555.com (8.17.1/8.17.1) with ESMTP id 40ALLtn3058678; Wed, 10 Jan 2024 13:21:56 -0800 (PST) (envelope-from finlayson@live555.com)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
From: Ross Finlayson <finlayson@live555.com>
In-Reply-To: <87le8xxbr9.fsf@hobgoblin.ariadne.com>
Date: Thu, 11 Jan 2024 10:21:45 +1300
Cc: Josip Bodružić <josip.bodruzic@outlook.com>, mmusic@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4FD52AD-8BCA-4B38-AF17-74ABE8C9555D@live555.com>
References: <87le8xxbr9.fsf@hobgoblin.ariadne.com>
To: "Dale R. Worley" <worley@ariadne.com>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/zbu4Q9grH-Uft7rAORQe_rjUzf4>
Subject: Re: [MMUSIC] Replay in RTSP?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.39
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: <https://mailarchive.ietf.org/arch/browse/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, 10 Jan 2024 21:22:10 -0000


> On Jan 11, 2024, at 7:51 AM, Dale R. Worley <worley@ariadne.com> wrote:
> 
> My belief is that the reason that RTSP does not have a "replay feature"
> is that the general model of "media stream" does not have the concept
> that the media is stored somewhere, and therefore there is no
> pre-existing "beginning" return to and thus obtain again the stream
> data that was previously obtained.  That is, it is the media stream
> source that defines the concept of a beginning point of a persistent
> blob of stored media.  (Or ending point, for that matter.)

Yes, and the media server can specify - using a “a=range:” field in the media’s SDP description - the start and end times of the media.  And a RTSP client can specify - with a “Range:” header in a “PLAY” command - the point in time that media should start (when it’s streamed).  So while the OP is correct that there’s no specific “Replay” command in RTSP, there *is* a way for RTSP clients to request that stored media be played from a particular point in time.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

v2.23.0 | Report a Bug | By Email