Re: [rtcweb] AVPF vs AVP

Harald Alvestrand <harald@alvestrand.no> Fri, 16 September 2011 14:11 UTC

Return-Path: <harald@alvestrand.no>
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 E6B0521F84F9 for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 07:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.692
X-Spam-Level:
X-Spam-Status: No, score=-107.692 tagged_above=-999 required=5 tests=[AWL=2.907, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 x88OcAcyj2fs for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 07:11:29 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0B821F84ED for <rtcweb@ietf.org>; Fri, 16 Sep 2011 07:11:29 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2FAFF39E0BC for <rtcweb@ietf.org>; Fri, 16 Sep 2011 16:13:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugTgyHGcthVW for <rtcweb@ietf.org>; Fri, 16 Sep 2011 16:13:42 +0200 (CEST)
Received: from [172.16.48.184] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id B542339E089 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 16:13:41 +0200 (CEST)
Message-ID: <4E735994.2090007@alvestrand.no>
Date: Fri, 16 Sep 2011 16:13:40 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E70C387.1070707@ericsson.com> <4e73497a.280d440a.69d0.ffff9f98@mx.google.com>
In-Reply-To: <4e73497a.280d440a.69d0.ffff9f98@mx.google.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 14:11:31 -0000

On 09/16/2011 03:03 PM, Roni Even wrote:
> Magnus,
> Maybe we can take the approach from
> draft-holmberg-mmusic-sdp-multiplex-negotiation and offer the same m-line
> with the same port number twice, one as AVP and one as AVPF and let the
> other side chose, he can answer with a port=0 for the profile it does not
> want. If the multiplex proposal has backward interoperability than this
> proposal also does.
The backwards compatibility case for this one (grouping type = PICKONE?) 
would be that the responder establishes two RTP sessions, one with AVP 
and one with AVPF. Presumably, one has to do a second SDP O/A to get rid 
of the one the initiator doesn't want, and hope that the responder 
hasn't started using that one for media.

In draft-holmberg, the backwards compatibility case is that the 
responder establishes two RTP sessions, and both are used - each for one 
media type. No second pass is needed (as far as I can tell from current 
discussion).

A lot of things become simpler if 2-pass SDP O/A is an acceptable 
mechanism - first send a very rich offer in order to figure out what the 
other side is willing to do, then a very lean offer with only the 
mechanisms one prefers and knows that the responder is capable of 
supporting.
But is this an acceptable strategy? It has costs both in time-to-setup 
and possibly a quite confusing intermediate state of the SDP session.

> Roni Even
>
>> -----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
>