Re: [MMUSIC] POF/PAN: Length of mid values

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 23 October 2013 03:06 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A8511E8100 for <mmusic@ietfa.amsl.com>; Tue, 22 Oct 2013 20:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.292
X-Spam-Level:
X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 bFIZEacGR1Dz for <mmusic@ietfa.amsl.com>; Tue, 22 Oct 2013 20:05:57 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id F164211E80EC for <mmusic@ietf.org>; Tue, 22 Oct 2013 20:05:56 -0700 (PDT)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta02.westchester.pa.mail.comcast.net with comcast id gSzC1m00k0xGWP851T5wp1; Wed, 23 Oct 2013 03:05:56 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id gT5w1m0093ZTu2S3YT5wys; Wed, 23 Oct 2013 03:05:56 +0000
Message-ID: <52673D14.7010800@alum.mit.edu>
Date: Tue, 22 Oct 2013 23:05:56 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C4EBB9C@ESESSMB209.ericsson.se> <CABkgnnX2OJxhFkHcH=DGo=VWgg6-M5TBS5fSpE2FaYc0r7Q2+Q@mail.gmail.com>
In-Reply-To: <CABkgnnX2OJxhFkHcH=DGo=VWgg6-M5TBS5fSpE2FaYc0r7Q2+Q@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382497556; bh=2NDCqpRN1rU155oGUY8Ko0QvVnPrHWZSfOmbnR2KWvs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AIXDIXcvUs/zewQKSr6cLWmKe2pVkzWs2yTBFNSub4ZRtm3jLIrBjBh5n9toOlI9l mr3edTB7hkFjupGSf9Z+EfhI5Oc/QQDNI9sHBEMlJeQr9cvtqb+P5Ta54f+FBhV3UQ Y6KYCwNoiWDK/WH/Q0gVE5QRopXyQdeRFVTbgMW/LhqiGWl/miRDeNrTbPWe5Jau3N tX0mEMjCeQwqny9uHdzo6CFK6IO+CTSJVOo9dGbRrJ6v/B2GMc7T+O6kh68DiwUqpj M/xJm6WuX3TaR97zYD7nvvxD1GboAmB02/1vbMEo3UQFX6GMji4du3ln3nBId9mvqP bbu2YPh9Oaumw==
Subject: Re: [MMUSIC] POF/PAN: Length of mid values
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 03:06:03 -0000

On 10/22/13 6:31 PM, Martin Thomson wrote:
> On 22 October 2013 11:12, Christer Holmberg
> <christer.holmberg@ericsson.com> wrote:
>> Wouldn't it be possible to simply assign e.g. a 1 character mid value prefix
>> to the Offerer and the Answerer?
>
> That would be possible iff you could derive that from the original
> context consistently, but I'm not sure that this is possible in SIP
> given 3PCC and all the crazy shit that goes on there.

I thought about that too.

We *could* say that if there is a middle box that turns offers into 
answers, it also has to fix up the resulting mess. It would, in 
principle, know enough to do it. Boxes that do that already have to fix 
up other stuff.

Or we could define an O/A negotiation for the prefixes. That would still 
require a middle box to do some fixup, but it would be simpler.

Or, as I suggested earlier, we could derive a prefix from other stuff in 
the offer and answer that is likely to result in unique prefixes for the 
two sides. And just ban POF/PAN if it doesn't. (In that case another O/A 
could probably resolve it.)

	Thanks,
	Paul