Re: [AVTCORE] Question (Dale R. Worley) Tue, 06 January 2015 03:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C932D1A0E10 for <>; Mon, 5 Jan 2015 19:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lEu1fWDV4itR for <>; Mon, 5 Jan 2015 19:52:42 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB2541A0AF8 for <>; Mon, 5 Jan 2015 19:52:41 -0800 (PST)
Received: from ([]) by with comcast id cTsY1p0062Bo0NV01Tshos; Tue, 06 Jan 2015 03:52:41 +0000
Received: from ([]) by with comcast id cTsg1p00D1KKtkw01Tsg9e; Tue, 06 Jan 2015 03:52:41 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id t063qd9V031524; Mon, 5 Jan 2015 22:52:39 -0500
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id t063qdWY031521; Mon, 5 Jan 2015 22:52:39 -0500
X-Authentication-Warning: worley set sender to using -f
To: Julius Friedman <>
In-Reply-To: <> (
Date: Mon, 05 Jan 2015 22:52:39 -0500
Message-ID: <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1420516361; bh=A3IB4do+hM7fWaKDpNXjkBeylTWehpBeJCuDNia+t1w=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=m8HE4ApaCd3CDkXSolrwMetBz/9qmhQ66eou9zOaqlo4LgfihgYwiPoXldV1L88Zx uJaE2mVHLf77tXih32k1tx+eFKsH31rg/+tFg2OT2omxYYrRk1y9+SB7eTrH+N1El3 /i+dcOQop6dWdHFwv75B09Ax1X01WKxcSoM3xMH7+WTmWLG3gCJ8WYXHjtcEwI15qr 6HKK0q8Rxh3GuLAMBTnwi5hm5C4tkL5bgS3AIgHeuH8PinHyAsYsOEl1pCzz5/6ANU oelSDmey27mia9ZmMoZL9oKpYJTnkYJxQ47Nu60Fa24rqnsQp2AY0fgKqB3FOnau9l rJILKv+rhp4zA==
Subject: Re: [AVTCORE] Question
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Jan 2015 03:52:44 -0000

Julius Friedman <> 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