Re: [rtcweb] AVPF vs AVP

Harald Alvestrand <harald@alvestrand.no> Wed, 14 September 2011 19:30 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C4421F8D5F for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 12:30:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.421
X-Spam-Level:
X-Spam-Status: No, score=-108.421 tagged_above=-999 required=5 tests=[AWL=2.178, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3umeu0Ejdg7 for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 12:30:30 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 25CCB21F8D55 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 12:30:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3BAF239E0D2 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 21:32:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5CVOIHj+WrS for <rtcweb@ietf.org>; Wed, 14 Sep 2011 21:32:37 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id BA68439E098 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 21:32:37 +0200 (CEST)
Message-ID: <4E710155.8080409@alvestrand.no>
Date: Wed, 14 Sep 2011 21:32:37 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E70C387.1070707@ericsson.com>
In-Reply-To: <4E70C387.1070707@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] AVPF vs AVP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Sep 2011 19:30:30 -0000

On 09/14/11 17:08, Magnus Westerlund wrote:
> Hi,
>
> There has been this long thread with the subject partially containing
> "AVPF". I want to clarify something in this context around AVPF. Rather
> than the SRTP question.
>
> An end-point that is AVPF compliant is in fact interoperable with an AVP
> one as long as the trr-int parameter is set reasonably large. A
> parameter value of 1.5-5 seconds (I would recommend 3s) will ensure that
> they are in fact compatible. This avoids the risk of any side timing out
> the other if the AVP side is using the default 5 s minimum interval.
>
> Based on this one could in fact have the RTCWEB nodes always use AVPF
> for RTP/RTCP Behavior. The AVPF feedback messages are explicitly
> negotiated and will only be used when agreed on.
>
> This leaves us with any signaling incompatibilities when talking to a
> legacy device. If one don't want to use cap-neg I see two directions to go:
>
> 1) RTCWEB end-point will always signal AVPF or SAVPF. I signalling
> gateway to legacy will change that by removing the F to AVP or SAVP.
>
> 2) RTCWEB end-point will always use AVPF but signal it as AVP. It will
> detect the AVPF capabilities of the other end-point based on the
> signaling of the feedback events intended to be used.
>
> I think 1) is cleaner for the future. 2) might be more pragmatic.
If 2) is more pragmatic, the IETF should update the definition of AVP to 
allow use of AVPF functionality.
The responses seem to indicate that in practice, this is already being 
done (and this is a clear indication that the concept of "profile" in 
RTP has failed to achieve its purpose).

*shudder*
> In both cases I believe there are methods for negotiating a lower
> trr-int than some AVP fallback value to preserve interoperability.
>
>
> However, this still don't resolve the question if the "S" should be in
> front of the RTP profile indicator or not. But it might help by removing
> the F or not in the profile.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>