Re: [MMUSIC] Offer/Answer PT Questions

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 22 February 2016 20:42 UTC

Return-Path: <christer.holmberg@ericsson.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 7B21A1A1EFA for <mmusic@ietfa.amsl.com>; Mon, 22 Feb 2016 12:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Z-E5Jul8kE3D for <mmusic@ietfa.amsl.com>; Mon, 22 Feb 2016 12:42:33 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866F41A1EF1 for <mmusic@ietf.org>; Mon, 22 Feb 2016 12:42:32 -0800 (PST)
X-AuditID: c1b4fb2d-f794c6d000006f31-f4-56cb72b6052c
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.11.28465.6B27BC65; Mon, 22 Feb 2016 21:42:30 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 21:42:29 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Offer/Answer PT Questions
Thread-Index: AdFrl0kuiZ+JG67LRQCl2lgEejcpMAAYtOkAAGpJ4lD///3bAIAAB/sA///p1yA=
Date: Mon, 22 Feb 2016 20:42:28 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37E36086@ESESSMB209.ericsson.se>
References: <E42CCDDA6722744CB241677169E8365615E419C0@MISOUT7MSGUSRDB.ITServices.sbc.com> <56C89F86.7020401@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37E35E33@ESESSMB209.ericsson.se> <CAD5OKxsDGhSA1WpzVVEvdd0CQdbnFn+ST+ZP_=aYVWBVdKKs4g@mail.gmail.com> <56CB6DB6.30802@alum.mit.edu>
In-Reply-To: <56CB6DB6.30802@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7ru62otNhBjd2S1hMXf6YxWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG1Q83WQo2C1Q8mPiMpYGxgbeLkZNDQsBE 4vb/d2wQtpjEhXvrgWwuDiGBw4wSD1Z9AksICSxmlJgzNaGLkYODTcBCovufNkhYRMBX4tnj 22AlwgL6Eu8XHWGHiBtI7H15AMr2k1izswfMZhFQlZj5fA8riM0L1Hth53NmiF3LmCQ2HvgO luAU0JKYsv4YI4jNCHTQ91NrmEBsZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBC2kkTjkies EPU6Egt2Q9zPLKAtsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbR4tTi4tx0 I2O91KLM5OLi/Dy9vNSSTYzAODm45bfuDsbVrx0PMQpwMCrx8G6IOh0mxJpYVlyZe4hRgoNZ SYQ3NQYoxJuSWFmVWpQfX1Sak1p8iFGag0VJnHeN8/owIYH0xJLU7NTUgtQimCwTB6dUA2PI L2ltZd6Fe5u7Z+mJRAZEBPr8rlUPD2HefvLJ2YuF3YJTD077HnlbOfy9+b7gxv+TJ1wIW15t vVaVS0Xkicy0jtbNZ4/OmSeXeW3GLPVtazIUy3jkDd9eFzJ582FVw+GbR9t0mRt/xykcUY25 uizyIddH6fQjBWdZZM3Fw/Yf7f2x/iTHx81KLMUZiYZazEXFiQBxgatljwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/EYiqB7e5p4cmQmAW9oWuoxpJXZg>
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: Mon, 22 Feb 2016 20:42:34 -0000

Hi,

>> 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.
>
> I agree that this is how it *should* be. I don't know if we can change this safely or not. It seems likely to me that 
> some implementations might be freaked out by this. It is worth discussion.
>
> There are cases where it really isn't feasible to meet the current requirement. In particular, when a transfer is 
> done via 3pcc the transferee won't know the history of past PT usage. So I expect in cases such cases the rule is commonly broken.
>
> Coming up with clear rules for when PTs can be recycled could be a challenge.

Well, I think we have to try, because these kind of issues keep causing problems.

The fact that something may freak about because we fix it is not a reason for not fixing it :)

Regards,

Christer