Re: [MMUSIC] Offer/Answer PT Questions

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 23 February 2016 15:44 UTC

Return-Path: <pkyzivat@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 D53A11B3287 for <mmusic@ietfa.amsl.com>; Tue, 23 Feb 2016 07:44: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 xG88HbWq8lum for <mmusic@ietfa.amsl.com>; Tue, 23 Feb 2016 07:44:43 -0800 (PST)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7711B2FFD for <mmusic@ietf.org>; Tue, 23 Feb 2016 07:44:42 -0800 (PST)
Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-10v.sys.comcast.net with comcast id MrjN1s0052EPM3101rkiGd; Tue, 23 Feb 2016 15:44:42 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-07v.sys.comcast.net with comcast id Mrkh1s00D3KdFy101rkhyR; Tue, 23 Feb 2016 15:44:42 +0000
To: Colin Perkins <csp@csperkins.org>, Roman Shpount <roman@telurix.com>
References: <E42CCDDA6722744CB241677169E8365615E419C0@MISOUT7MSGUSRDB.ITServices.sbc.com> <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <CAD5OKxsDGhSA1WpzVVEvdd0CQdbnFn+ST+ZP_=aYVWBVdKKs4g@mail.gmail.com> <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56CC7E68.4040103@alum.mit.edu>
Date: Tue, 23 Feb 2016 10:44:40 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456242282; bh=iAQvXDL7Zj8G0jpM1hfMBuVlc6h3JwzjVRSXnmEizek=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Ui/Eg65lb6yBt+T2KZEaONIkUmW3YohspjtmBi5tI+yth3nNZy3QwGpDhPtXXgqIG 48YuG4AjmdXAxxAzKw8CsWNzhqqtbBBZjlj5ATFUPm1uGb5pTIQRKuiY6LGX/PHaaq xuMEb+MrSv3DhfZOSstcZ3LPJ6E0RBRFExaIKiWm+iDdUMEfpGGDghdZG6AvTdRWbL pSnSu3qIe810w6WNEtjkuAJaks0E4tsVMj2wTbxRMh+R1xWd8yzkwXYoqa8iLbxFjn kt610Q+ejFk5WfQpOIjKsvAQH26RNVyKuRKWif9CUDTRSC4LZQ1vW8TFlX6w2fAJWF L5za9dgpjWgJA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/-grb4TE2U30OUT0Hvv4AhJnSV2w>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] Offer/Answer PT Questions
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: <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: Tue, 23 Feb 2016 15:44:44 -0000

On 2/23/16 5:29 AM, Colin Perkins wrote:

> No objection in principle, but it’s not as simple as “a few network RTTs”:
>
> No ambiguity in decoding means that the packets need to have been played
> out, so the codec state for that PT can be discarded. Some systems can
> have large (multi-second) playout buffers.
>
> Any packets referring to the old PT also need to be gone. Formats
> like RFC 6354 allow large offsets between streams, referenced by PT (the
> example in Section 5 has a 5.1 second offset).

Thanks for the insight. It helps to ground the discussion.

I'm also interested in hearing if there might be *other* reasons behind 
the rules as they are written.

The advantage of the current rule is that it is easy to explain, and is 
sufficient to deal with the problem you describe above. Unfortunately it 
is also difficult/impossible to comply with in some cases. If we are to 
replace it, we need to find something else to replace it with.

Would it be possible to instead make a rule that a PT can't be reused 
until there are no active streams using it? (That any that were 
initiated have been terminated.) Note: I don't know RTP well enough to 
be confident that this even makes sense.

	Thanks,
	Paul