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

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 23 October 2013 03:35 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 9368611E8105 for <mmusic@ietfa.amsl.com>; Tue, 22 Oct 2013 20:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.631
X-Spam-Level:
X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 H0KpFj2ANkQo for <mmusic@ietfa.amsl.com>; Tue, 22 Oct 2013 20:35:54 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C336E11E82B8 for <mmusic@ietf.org>; Tue, 22 Oct 2013 20:35:49 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-4e-5267440a6fe6
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id F3.28.03802.A0447625; Wed, 23 Oct 2013 05:35:38 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Wed, 23 Oct 2013 05:35:38 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] POF/PAN: Length of mid values
Thread-Index: Ac7PUkEvfSSwviXnTPSLJog1JkUgBQAE1/MAAAmZgAAABTpZSA==
Date: Wed, 23 Oct 2013 03:35:37 +0000
Message-ID: <wb6s40uj8o6p7jj1faymc36x.1382499334481@email.android.com>
References: <7594FB04B1934943A5C02806D1A2204B1C4EBB9C@ESESSMB209.ericsson.se> <CABkgnnX2OJxhFkHcH=DGo=VWgg6-M5TBS5fSpE2FaYc0r7Q2+Q@mail.gmail.com>, <52673D14.7010800@alum.mit.edu>
In-Reply-To: <52673D14.7010800@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM+JvjS6XS3qQwftT+hZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxt+USe8EJ7opl81ezNzBO4Oxi5OSQEDCR 6O/oYoOwxSQu3FsPZHNxCAkcZpRo+fofylnCKHHy+j8gh4ODTcBCovufNkiDiICvxLPHt8Ga hQWMJd5OnssMETeRePx+ATuE7SSx5vdMJpBWFgFViUOLRUFMXgE3iVvTc0EqhAS2MEp8PGEN YnMK6EjMX3wPbCIj0DnfT61hArGZBcQlbj2ZzwRxpoDEkj3nmSFsUYmXj/+xQtToSCzY/YkN wtaWWLbwNVgNr4CgxMmZT1gmMIrMQjJqFpKWWUhaZiFpWcDIsoqRPTcxMye93GgTIzDcD275 rbqD8c45kUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgtLS2VNOZ4T/n +nmdToda0cvZso+bgzkXrZ+55sIXtktsny/zVn34uW3ylNWqGzsNhBf9/CHWWu/0JfDz/vSM O8c8H+yZHtUYyuzd7hAnsiPWM3LbOmmvVGa9yF71xmLWN1zRW2Z+a5vmoLQ45Yjpy7KL31/d lCgxXhpXUmTzZ2fKjAMGeqfUlFiKMxINtZiLihMB1rl0t0UCAAA=
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:35:59 -0000

Hi,

Yed, the prefix could also be negotiated, e.g. using a new 'midpref' attribute.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:


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
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic