IETF Logo Mail Archive

Re: [rtcweb] AVPF vs AVP

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 16 September 2011 18:03 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 0535E21F8B7B for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 11:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.506
X-Spam-Level:
X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 NtKzl9SEmKHS for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 11:03:56 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6B89921F8582 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 11:03:56 -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; Fri, 16 Sep 2011 14:06:09 -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; Fri, 16 Sep 2011 14:06:10 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Roni Even <ron.even.tlv@gmail.com>
Thread-Topic: [rtcweb] AVPF vs AVP
Thread-Index: AQHMcvCC1935An+dNEG35IBBpAPmuQ==
Date: Fri, 16 Sep 2011 18:06:10 +0000
Message-ID: <87AC7090-D372-4CC7-A20B-560B0598D7E5@acmepacket.com>
References: <4E70C387.1070707@ericsson.com> <4e73497a.280d440a.69d0.ffff9f98@mx.google.com>
In-Reply-To: <4e73497a.280d440a.69d0.ffff9f98@mx.google.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <998C8E51AC956648A6130C9E3D287371@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: Fri, 16 Sep 2011 18:03:57 -0000

On Sep 16, 2011, at 9:03 AM, 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.

You can't do that.  Not only is it not kosher in the sense that you're really offering two media sessions, rather than alternatives for one, but it actually won't work in practice: if the SDP offer crosses an SBC or App-Server B2BUA, some of them will treat them as two media sessions and thus offer 2 different port numbers on their UAC side and make it no longer distinguishable from a normal offer of two media sessions.
(and I've tested this on an SBC)

-hadriel

v2.23.0 | Report a Bug | By Email