[AVTCORE] On RFC2326

Julius Friedman <juliusfriedman@gmail.com> Sun, 18 January 2015 19:33 UTC

Return-Path: <juliusfriedman@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992F41ACDF4; Sun, 18 Jan 2015 11:33:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 opf1zxFMOEYh; Sun, 18 Jan 2015 11:33:31 -0800 (PST)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3371ACDF8; Sun, 18 Jan 2015 11:33:30 -0800 (PST)
Received: by mail-pd0-f169.google.com with SMTP id z10so32315610pdj.0; Sun, 18 Jan 2015 11:33:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JmG0IH5hHX7DWvG/jQrkoxi1x5csQPYAl6RDActu4XY=; b=OtoVX5J8rliFa304HklPgSHLrxO40Wux7hblCpllLqLEcGHXwouHWLEnEZ19deWN3s Jei7HEPJQ4GLYp2hEf8nntN9V7Gwt/rHJxBmo5eumNsrrLbtFhEz6dyYy1DWiX/B9OKW nIK1fuZ+dWuY0D3Zd1XeHQRhWpj3K5uYR4maLzU+WrZ64Yteha89Ge4nZ4KZZpI5TgqP fDb7Zg/c6jbVgnU9SUBs0lqd/FiMh1PeZtpkJ8Un1YmQ2hnKiS5/cepH8uhfkKkJgSZG qgvknqYwwjkpZaBmRg4pCjxAUKRn/Q3qqmE1QjiIQZgBLTRURSxvjCNeLA0Bq4aG3nnk hOyQ==
MIME-Version: 1.0
X-Received: by 10.70.22.227 with SMTP id h3mr38904429pdf.160.1421609610062; Sun, 18 Jan 2015 11:33:30 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Sun, 18 Jan 2015 11:33:30 -0800 (PST)
Date: Sun, 18 Jan 2015 14:33:30 -0500
Message-ID: <CACFvNHVFUe7jHEK00ja3Vppi5GYeKptOuVPi97HrYU3DdiyLCA@mail.gmail.com>
From: Julius Friedman <juliusfriedman@gmail.com>
To: mmusic@ietf.org, avt@ietf.org
Content-Type: multipart/alternative; boundary="047d7b6da18ad13458050cf2472f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/pUuHiDlRvqscNyqNiAZ7QZxndGU>
Subject: [AVTCORE] On RFC2326
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Jan 2015 19:33:32 -0000

Unfortunately I have more information which I have found to be
contradictory and possibly erratum.

Quite Succinctly,

"

10.7 <https://tools.ietf.org/html/rfc2326#section-10.7> TEARDOWN

   The TEARDOWN request stops the stream delivery for the given URI,
   freeing the resources associated with it. If the URI is the
   presentation URI for this presentation, any RTSP session identifier
   associated with the session is no longer valid. Unless all transport
   parameters are defined by the session description, a SETUP request
   has to be issued before the session can be played again.

"


However earlier in the document.


"

10.4 <https://tools.ietf.org/html/rfc2326#section-10.4> SETUP

....


The server generates session identifiers in response to SETUP
   requests. If a SETUP request to a server includes a session
   identifier, the server MUST bundle this setup request into the

   existing session or return error "459 Aggregate Operation Not
   Allowed" (see Section 11.3.10
<https://tools.ietf.org/html/rfc2326#section-11.3.10>).

"


If a users obtains a session Id related to an aggregate controlled
media and only one of the sub sessions received a "TEARDOWN" then the
RFC makes the server incorrectly remove the SessionId which is still
being used for the other sub-sessions.



The draft doesn't do any better in making this clearer IMHO.


Please advise,


I will also probably be filling more errata unless I can be directed
on how to properly convey the information without filling it.


I hope all else is well as I STILL haven't heard back from anyone
regarding both the clarifications I made. (Which is pretty ridiculous,
it's been over 2 years I have been asking these questions almost)


-Julius