Re: [MMUSIC] [AVTCORE] Question

worley@ariadne.com (Dale R. Worley) Tue, 06 January 2015 03:52 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF201A19E4 for <mmusic@ietfa.amsl.com>; Mon, 5 Jan 2015 19:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWngCwbGyZpY for <mmusic@ietfa.amsl.com>; Mon, 5 Jan 2015 19:52:42 -0800 (PST)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBBA1A0E10 for <mmusic@ietf.org>; Mon, 5 Jan 2015 19:52:41 -0800 (PST)
Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-02v.sys.comcast.net with comcast id cTsJ1p0072Bo0NV01Tsh6c; Tue, 06 Jan 2015 03:52:41 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-05v.sys.comcast.net with comcast id cTsg1p00D1KKtkw01Tsg9e; Tue, 06 Jan 2015 03:52:41 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id t063qd9V031524; Mon, 5 Jan 2015 22:52:39 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id t063qdWY031521; Mon, 5 Jan 2015 22:52:39 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Julius Friedman <juliusfriedman@gmail.com>
In-Reply-To: <CACFvNHXhFQe2CEKsv4q637SoGa-vKuhztN+a1ywK1ewU_Sa6KA@mail.gmail.com> (juliusfriedman@gmail.com)
Sender: worley@ariadne.com
Date: Mon, 05 Jan 2015 22:52:39 -0500
Message-ID: <87d26sefaw.fsf@hobgoblin.ariadne.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420516361; bh=A3IB4do+hM7fWaKDpNXjkBeylTWehpBeJCuDNia+t1w=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=P/JVyDQdWFLnV2+G1fLp4n97mvOhNCn5Yr+/jUHjvY7m2Zhw+W4O/yn7D6Vhnj8oN XxcGE47fkeNk3c8fkkmbqyLiNAHmc8oPt1W/dq806HSf0lS6dyse4LZfMenzKb+73T V21xnJFe23yMiKnkSWqaFmdVS55ccPeXjr9JeJsYf0m/axzc9nxFEmwXOWVGSOU+tZ tuEdlOV6NcNr/1+w509jeDCwe1V7lftdtI5MUJO6F2YgIfDvlpPX/kZ0d/OrSpCE8q bCCtZtpQ9C5GFBA463v79ONi1v9fSCAT6Lj5MoN1eZCBHuXeE4uQqXlBJnSEL8/Wye dTRM4Sbuxj0qA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Yxm5whOdl27XtqzK01hDPp_-eM4
Cc: avt@ietf.org, mmusic@ietf.org
Subject: Re: [MMUSIC] [AVTCORE] Question
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 06 Jan 2015 03:52:44 -0000

Julius Friedman <juliusfriedman@gmail.com> writes:
> I would like to address your response:
>
> "In any case, why would we want to prevent seeking on a stored media
> object?  I can see why if the media is an un-stored media stream, but in
> that case, the software likely doesn't know the total length that the
> media will have."
>
> I will justify how "likely" this is as follows:
>
> 1) A Live 10 minute `media` which has been playing for 3 minutes, leaving
> me 7 minutes in play but unable to seek.
>    a) If the stream was stored or recorded this obviously wouldn't be an
> issue

But how would we know that the media is 10 minutes long if it was not
already stored?  If it was truly live, we'd only know that it was
*scheduled* to be 10 minutes long, not that it will actually *be* 10
minutes long.

> 2) I have a server which requires authorization to seek but not to play.

Why would we want to support that?

> 3) I am a client and I have started playing and 'PAUSE' is not supported
>
> 4) I am a server re-streaming from a server where "Range" is not supported

I'm no expert in RTSP, but my understanding is that these two situations
are only expected to happen when the media is truly live, that is, the
server does not know how long the media will be.

> "Perhaps referring to the mailing list discussion for this RFC would
> reveal the answer."
>
> Which mailing list is that? 'mmusic' they have also been addressed, several
> times. I never get a response from them.

I assume you mean "I have asked before on mmusic and received no
response."  Perhaps nobody else cares about the proposed capability?

I mean the mailing list discussion surrounding this document when it was
made an RFC.  (Better, look up the Internet-Draft name and refer to the
appropriate mailing list archive for the time when the I-D was being
discussed.)

Dale