Re: [rtcweb] AVPF vs AVP

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A6CD21F86EE for <>; Thu, 15 Sep 2011 09:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.502
X-Spam-Status: No, score=-106.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IRrmHHeBBtKf for <>; Thu, 15 Sep 2011 09:03:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 79F6021F8AFB for <>; Thu, 15 Sep 2011 09:03:53 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-cf-4e72226b9d57
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DC.5D.02839.B62227E4; Thu, 15 Sep 2011 18:06:04 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 15 Sep 2011 18:06:03 +0200
Message-ID: <>
Date: Thu, 15 Sep 2011 18:06:01 +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: Roni Even <>
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 16:03:54 -0000

On 2011-09-15 16:01, Roni Even wrote:
> Magnus,
> I noticed that you claim that all AVPF feedback messages are explicitly
> negotiated, is this a requirement. At least RTCP-SR-REQ is not negotiated in
> SDP.

You are correct, had not actually noticed that. Fortunately that isn't
an real issue.

First of all the support of AVPF can still be negotiated with the
a=rtcp-fb. Simply the trr-int configuration lets both side show support
of AVPF.

Secondly, for the RTCP-SR-REQ if one uses the header extension to
deliver the synch data then that is explicitly indicated. And if you
ignore or don't understand the request then you simple fall back to
normal synchronization procedures with more delay before completing it.

> As for using AVPF while signaling AVP that will confuse endpoint that so not
> understand this convention and can support AVPF. They will see an offer with
> AVP but with parameters that are not part of AVP. They can respond with AVP
> without the AVPF parameter and behave like AVP endpoints even though they
> support AVPF. This will prevent them from sending AVPF feedback messages.

They can still use AVPF timing rules, even if the other end-point is AVP
only. They only need to restrict themselves from sending feedback messages.

> This may be a problem for what you call "legacy" video conferencing
> endpoint. (I do not like the term legacy here since these are not legacy
> endpoint but AVP/AVPF compliant EPs 

Yes, I agree it is not without issues in that regard.

I would also like to note that if you require AVPF and don't think
talking to AVP only end-points then one really should include the AVPF
in the m= line to prevent fallback.

> I think that if we are not going to use cap-neg we should make it
> historical. 

I kind of agree with that also. But if it constantly fails in the market
I think we have to recognize that and do something else that works better.


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: