Re: [rtcweb] AVPF vs AVP

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 15 September 2011 03:19 UTC

Return-Path: <HKaplan@acmepacket.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 DCD9D21F8A70 for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 20:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level:
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599]
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 lQjw6lz8Rn9L for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 20:19:39 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F2FA821F8A6C for <rtcweb@ietf.org>; Wed, 14 Sep 2011 20:19:38 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 14 Sep 2011 23:21:47 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 23:21:47 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [rtcweb] AVPF vs AVP
Thread-Index: AQHMcvCC1935An+dNEG35IBBpAPmuZVOCl6A
Date: Thu, 15 Sep 2011 03:21:46 +0000
Message-ID: <F31F6627-B4FD-48DB-8C95-ECCBA63DFFB4@acmepacket.com>
References: <4E70C387.1070707@ericsson.com>
In-Reply-To: <4E70C387.1070707@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <496C1C6BF0E3D54C98372085A76D3B9E@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "rtcweb@ietf.org" <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: Thu, 15 Sep 2011 03:19:40 -0000

I am shocked, Shocked!, to see you suggest that we disregard RFC 4585 and SDP rules, when we have an IETF specified means of indicating multiple profile support using RFC 5939 SDP Capability Negotiation.
;)

-hadriel


On Sep 14, 2011, at 11:08 AM, 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.
> 
> 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