Re: [rtcweb] AVPF vs AVP

Magnus Westerlund <> Thu, 15 September 2011 12:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B7B121F8A70 for <>; Thu, 15 Sep 2011 05:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.5
X-Spam-Status: No, score=-106.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TVP0q8UAqT6W for <>; Thu, 15 Sep 2011 05:03:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8063E21F8997 for <>; Thu, 15 Sep 2011 05:03:36 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-4f-4e71ea1b808c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DE.FD.20773.B1AE17E4; Thu, 15 Sep 2011 14:05:47 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 15 Sep 2011 14:05:47 +0200
Message-ID: <>
Date: Thu, 15 Sep 2011 14:05:46 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Harald Alvestrand <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [rtcweb] AVPF vs AVP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Sep 2011 12:03:37 -0000

On 2011-09-14 21:32, Harald Alvestrand wrote:
> 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.

No, Harald that I think is a bad idea. The core of AVPF is the timing
rule. From my perspective the important aspect is that one do implement
the timing rules. Thus it is important we have the label of AVPF to
indicate these rules.

Thus my proposal is really to say that an RTCWEB end-point SHALL
implement and always use the AVPF timing rules. It might send feedback
messages if those have been negotiated with a=rtcp-fb attribute.

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

It works fine on the RTP level. But the signalling aspects has clearly
been botched.


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: