Re: [rtcweb] AVPF vs AVP

"Roni Even" <ron.even.tlv@gmail.com> Fri, 16 September 2011 05:48 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 05A3C21F8BA7 for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 22:48:13 -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 uke1A3Wa7dNx for <rtcweb@ietfa.amsl.com>; Thu, 15 Sep 2011 22:48:12 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7B321F8BA6 for <rtcweb@ietf.org>; Thu, 15 Sep 2011 22:48:12 -0700 (PDT)
Received: by yie12 with SMTP id 12so3144855yie.31 for <rtcweb@ietf.org>; Thu, 15 Sep 2011 22:50:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=tCAq7YGSdM3CzULpurdC3IBegP0rSqMZ5bQmShtFQA4=; b=cdpgOSgZMCwkmwNFLtMR+mbmiPmohh5kOqH3ovSeMVoAUbXMGFz1DZidIh12Uw7kTV 2HwRVwhU0kFtVzKC0Qt5l0HzEQ/ZLRvixxEAFcsRmEkFsQugZ1IU9yqscPbjsN5ePalL 1VLmSvoEai8qoRUgAH9gRfEDRpKJm44TPG1VQ=
Received: by 10.68.16.196 with SMTP id i4mr1680957pbd.512.1316152225109; Thu, 15 Sep 2011 22:50:25 -0700 (PDT)
Received: from windows8d787f9 ([59.37.10.82]) by mx.google.com with ESMTPS id i8sm8466833pbl.2.2011.09.15.22.50.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 22:50:24 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Christer Holmberg'" <christer.holmberg@ericsson.com>, "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>, <rtcweb@ietf.org>
References: <4E70C387.1070707@ericsson.com> <4e72059c.e829440a.4094.ffffb025@mx.google.com> <7F2072F1E0DE894DA4B517B93C6A05852233F1E3F6@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F1E3F6@ESESSCMS0356.eemea.ericsson.se>
Date: Fri, 16 Sep 2011 08:49:00 +0300
Message-ID: <4e72e3a0.e829440a.4094.0760@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: Acxy8IefSwNpefInRDiRlAjJbviBHwAvLJWQACE6AAAAAGah0A==
Content-Language: en-us
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:48:13 -0000

Christer,
This is not the issue, since the capneg talks about how to address the
systems that do not support it.
In the current proposal it will work as long as it will have a distinction
when to send AVP or AVPF and for video calls it must say that you MUST send
AVPF regardless of what is the system on the other side otherwise it will
fail to achieve a reasonable video call.
What I object is to always sending AVP with AVPF information. This usage
should be based on the type of media that is being used (video MUST always
use AVPF!!!!)
Roni

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Friday, September 16, 2011 8:34 AM
> To: Roni Even; Magnus Westerlund; rtcweb@ietf.org
> Subject: RE: [rtcweb] AVPF vs AVP
> 
> 
> Hi Roni,
> 
> >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.
> >
> >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
> 
> Do those devices support CapNeg?
> 
> Regards,
> 
> Christer
> 
> 
> 
> > > -----Original Message-----
> > > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> > > Behalf Of Magnus Westerlund
> > > Sent: Wednesday, September 14, 2011 6:09 PM
> > > To: rtcweb@ietf.org
> > > Subject: [rtcweb] AVPF vs AVP
> > >
> > > 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.
> > >
> > > 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
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> > =