Re: [rtcweb] AVPF vs AVP

"Roni Even" <ron.even.tlv@gmail.com> Fri, 16 September 2011 05:42 UTC

Return-Path: <ron.even.tlv@gmail.com>
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 099F021F8B8F for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 22:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 AU+xxJ7J54+Z for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 22:42:45 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 692FF21F8B4C for <rtcweb@ietf.org>; Thu, 15 Sep 2011 22:42:45 -0700 (PDT)
Received: by pzk33 with SMTP id 33so350099pzk.4 for <rtcweb@ietf.org>; Thu, 15 Sep 2011 22:44:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=F7SKDa91ApS+1yy+zFY4NL2a+xlvsIwUgXQznEWYAow=; b=d0LDlTb8plWy5XKJ4xiKjBH5E4aX436dvXeqoEhS4lRUNsCxK9S/eCjeD+UuDv1o4H kSa5Oirz3ukjs+IVI4iYLrgGAGyKodwx6s5b3b8irETtYsjejwNeb0eDFZI2uzFdZGAR Z+33nVeYvxWn8QjypeeCoJ7mzAPYC71FLPOdY=
Received: by 10.68.44.129 with SMTP id e1mr3082033pbm.113.1316151898518; Thu, 15 Sep 2011 22:44:58 -0700 (PDT)
Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id 4sm29912064pbk.5.2011.09.15.22.44.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 22:44:57 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> <4E722269.30304@ericsson.com>
In-Reply-To: <4E722269.30304@ericsson.com>
Date: Fri, 16 Sep 2011 08:43:31 +0300
Message-ID: <4e72e259.4401440a.4bc3.ffffd7d2@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcxzwV8zx0ZJbyF8Sausjk/9knnSngAccuog
Content-Language: en-us
Cc: rtcweb@ietf.org
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: Fri, 16 Sep 2011 05:42:46 -0000

Magnus,
I can agree that if you are doing video call you must send AVPF regardless
if you are talking with this type of systems that you call "not legacy" or
systems that you call "legacy". This must be a MUST in the text otherwise
the so called "legacy" end point will think it is AVP and will not send
feedback messages which will break video conferencing applications. 

Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
> Sent: Thursday, September 15, 2011 7:06 PM
> To: Roni Even
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] AVPF vs AVP
> 
> 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.
> 
> 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
> ----------------------------------------------------------------------