Re: [rtcweb] AVPF vs AVP

"Roni Even" <ron.even.tlv@gmail.com> Fri, 16 September 2011 06:24 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 C398A21F8BA4 for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 23:24:51 -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 UMjnMoU8uC5Y for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 23:24:51 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECF4221F8B90 for <rtcweb@ietf.org>; Thu, 15 Sep 2011 23:24:50 -0700 (PDT)
Received: by ywa6 with SMTP id 6so3154082ywa.31 for <rtcweb@ietf.org>; Thu, 15 Sep 2011 23:27:04 -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=BCaouhi3lkwDTLwoatCkR3c4bQsrma3ih0EBqRfOq+g=; b=SBg/BwM8GB1LAvJjYkl0iyN+la16JRG/8/prixgixFyq3uSk4zM1d980hfSikKhTpB 4Z9uZmCcdt2Imey/Mh9AO2H7BBnYSroi8ZOEFyoBmxjrQegQdEIs568vjV70IryUBUCW NpQFkwLNYWcqlNa7wvcKc4u/Dk2eBqsLRdVq0=
Received: by 10.68.35.8 with SMTP id d8mr1091683pbj.415.1316154424237; Thu, 15 Sep 2011 23:27:04 -0700 (PDT)
Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id i3sm30157615pbg.10.2011.09.15.23.27.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 23:27:03 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Christer Holmberg'" <christer.holmberg@ericsson.com>, "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> <4E722269.30304@ericsson.com> <4e72e259.4401440a.4bc3.ffffd7d2@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E40A@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F1E40A@ESESSCMS0356.eemea.ericsson.se>
Date: Fri, 16 Sep 2011 09:25:39 +0300
Message-ID: <4e72ec37.231a440a.0179.ffffe41b@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/9knnSngAccuogAABA7PAAAScegA==
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 06:24:51 -0000

Hi Christer,
Again, the word is MUST for video. I think that systems that will interwork
with RTCWEB systems will support AVPF since they will need to support
current video codecs. I do not see RTCWEB systems interwork with systems
that support only H.261 or even H.263, so I assume that the interworking
will be with systems that also use AVPF for video.


As for CLUE, we can discuss it in CLUE if relevant at all. It may be
relevant only for the video capture that should be used for interworking
with non CLUE systems.
 
Roni


> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Friday, September 16, 2011 8:51 AM
> To: Roni Even; Magnus Westerlund
> Cc: rtcweb@ietf.org
> Subject: RE: [rtcweb] AVPF vs AVP
> 
> 
> Hi,
> 
> >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.
> 
> If the video conf app *requires* AVPF, you should include AVPF in the
> m= line.
> 
> The AVP+a=rtcp-fb proposal is an alternative to CapNeg, where there is
> "built-in" fallback to AVP in case the answerer does not support AVPF.
> 
> And, IF we choose to go forward with this proposal, it should also be
> adopted by CLUE.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> > > -----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
> > >
> > ---------------------------------------------------------------------
> -
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> > =