Re: [MMUSIC] Offer/Answer PT Questions

Colin Perkins <csp@csperkins.org> Tue, 23 February 2016 10:29 UTC

Return-Path: <csp@csperkins.org>
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 8F9441B416F for <mmusic@ietfa.amsl.com>; Tue, 23 Feb 2016 02:29:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 YWavw3RzrG3f for <mmusic@ietfa.amsl.com>; Tue, 23 Feb 2016 02:29:36 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5431B416E for <mmusic@ietf.org>; Tue, 23 Feb 2016 02:29:36 -0800 (PST)
Received: from [130.209.247.112] (port=51991 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <csp@csperkins.org>) id 1aYADk-00056o-25; Tue, 23 Feb 2016 10:29:33 +0000
Content-Type: multipart/alternative; boundary="Apple-Mail=_DA40CA53-019F-45EF-BE26-4B6DF4CE0A19"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CAD5OKxsDGhSA1WpzVVEvdd0CQdbnFn+ST+ZP_=aYVWBVdKKs4g@mail.gmail.com>
Date: Tue, 23 Feb 2016 10:29:28 +0000
Message-Id: <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org>
References: <E42CCDDA6722744CB241677169E8365615E419C0@MISOUT7MSGUSRDB.ITServices.sbc.com> <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <CAD5OKxsDGhSA1WpzVVEvdd0CQdbnFn+ST+ZP_=aYVWBVdKKs4g@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.3112)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/ZK8tgtI_oKrLX6CTueMAO15vjKA>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>, 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 10:29:38 -0000

> On 22 Feb 2016, at 19:52, Roman Shpount <roman@telurix.com> wrote:
…
> One thing that bothered me here is that PT cannot be reused for the duration of the session. It is probably safe to reuse the PT after session modification if PT is no longer used. I always felt that dynamic PT reuse criteria were much stricter then realistically possible or needed. 
…
> I think the most important criteria here is that there should be no ambiguity regarding how an RTP packet with particular PT should be decoded. If it is guaranteed that there are no packets sent between Alice and Bob with PT 111 over some reasonable time interval (couple of network round trip times), then PT 111 can be safely reused. If, in this scenario Bob's end point knows that it was not sending anything with payload 111 recently, then it can safely reuse this payload. Alice could not be sending anything with payload 111 since Bob did not accept it previously. On the other hand, Bob must not reuse PT 100 for, let's say, CN, since there are packets with this payload in flight and this will create decoding ambiguity. To conclude, an end point should be able to safely reuse any PT that it is not currently accepting or was not sending or accepting for at least a few network round trip intervals.

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). 



-- 
Colin Perkins
https://csperkins.org/