Re: [MMUSIC] Offer/Answer PT Questions

"Drage, Keith (Nokia - GB)" <keith.drage@nokia.com> Tue, 23 February 2016 12:10 UTC

Return-Path: <keith.drage@nokia.com>
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 462CA1B310D for <mmusic@ietfa.amsl.com>; Tue, 23 Feb 2016 04:10:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=unavailable
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 JLyiE3_g8J2j for <mmusic@ietfa.amsl.com>; Tue, 23 Feb 2016 04:10:45 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89151B4292 for <mmusic@ietf.org>; Tue, 23 Feb 2016 04:04:28 -0800 (PST)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 9C1386C136328; Tue, 23 Feb 2016 12:04:24 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1NC4Oie018945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Feb 2016 12:04:24 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u1NC40S7014155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Feb 2016 13:04:22 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.98]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 23 Feb 2016 13:04:12 +0100
From: "Drage, Keith (Nokia - GB)" <keith.drage@nokia.com>
To: EXT Colin Perkins <csp@csperkins.org>, Roman Shpount <roman@telurix.com>
Thread-Topic: [MMUSIC] Offer/Answer PT Questions
Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lD///3bAIAA9P4A///VdXA=
Date: Tue, 23 Feb 2016 12:04:12 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE903FF@FR712WXCHMBA11.zeu.alcatel-lucent.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>
In-Reply-To: <7A0EA65A-83B0-4596-89D8-2E59F5AEA70F@csperkins.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADE903FFFR712WXCHMBA11z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/RV21ad5RVcNvTkON5K23bUKAhGE>
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 12:10:50 -0000

I agree that here we are discussing offer / answer, but we must also remember that any rules must be consistent with declarative usages of SDP.

It may also be that some of those declarative rules are also inherited by offer answer, such as the answer to the question as to whether the requirement to remember payload type usage (and whether than applies to both offers and answers, or independently to each).

Regards

Keith

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of EXT Colin Perkins
Sent: 23 February 2016 10:29
To: Roman Shpount
Cc: mmusic@ietf.org; Paul Kyzivat; Christer Holmberg
Subject: Re: [MMUSIC] Offer/Answer PT Questions

On 22 Feb 2016, at 19:52, Roman Shpount <roman@telurix.com<mailto: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/