[MMUSIC] rfc5888: Multigroup management

Santiago Carot Nemesio <sancane.kurento@gmail.com> Fri, 17 June 2016 09:55 UTC

Return-Path: <sancane.kurento@gmail.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 3A15512B012 for <mmusic@ietfa.amsl.com>; Fri, 17 Jun 2016 02:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCI2Mru4PH7I for <mmusic@ietfa.amsl.com>; Fri, 17 Jun 2016 02:55:05 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC11C12B007 for <mmusic@ietf.org>; Fri, 17 Jun 2016 02:55:04 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id z186so67116529ywd.2 for <mmusic@ietf.org>; Fri, 17 Jun 2016 02:55:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=kg1eB7YTuM97o4vyQMZagFQjODfH1vjmSqxLy4Ch+kc=; b=WvR1ZDR+Vd5GfM0ij+nsEJhR6rq08D1/ybT9gyZ3PUYAcSnT8IgtlKLE9A+jj7nymx udFYtLMmX/QyWj0P6oKXb8+Kx+3BnZdYxWg5UOF0DnQhrYCvg1HAM5RubyViBuXNynIu pr0+j0gpgD1fi3qB07rQKJXe5oXWs161BoTDJuP8wJ/HhWU9pJiRzHpps50BTXCP5OWP XqBYfa7fQpfT4FLEzxrfIaVnouDui4/CkzKqVlIl9qcYzhz5qp5KzNlGLW4PoUR5kiGj uRZxbf2hq2ZthUn5vP3FoRot7d3ND5le4UsopXW88jEJRlVMowzQ7ZrMokS7Q6d6hLUJ j0RA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kg1eB7YTuM97o4vyQMZagFQjODfH1vjmSqxLy4Ch+kc=; b=V034gpKP3C9LzT8UV7JNRjLcYeyF/5UhzTl5fivSFaEiNhktBKs9G7nuZpHUYx7hL5 AbVzwaYIy9N/lGPDqWKEbN+r/zymCiZXxjPVefUzj6l0BwSdVzvIoTNxtnosIYmR80nD cxEoMbX2adnxOY3+rKimEPHZPc9RiL4rSTENYXN1xkioC2TdUi7orH8FQGWOHjB+tKg5 ocuFskS4fLPHh3GswkIlp0RrxanO2ftZTpa8nKNpTOYn43nYrFenK2rmYPlEjA6D/lga n/+r3e8U2xZynfkOuDDzqQGFlw6VMp5gEokgPRiAmRuUjyVB0AORNGKI7thY0KLtrvI0 /i9w==
X-Gm-Message-State: ALyK8tIumYM595SsHmxBH/aWBz1EbcgK7N7C4p7lnmpm2HJ2Zm+zFDJDRBxMJv2xZhZn2VScYk60TmWKeJqFug==
X-Received: by 10.37.208.131 with SMTP id h125mr550334ybg.7.1466157304189; Fri, 17 Jun 2016 02:55:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.84.65 with HTTP; Fri, 17 Jun 2016 02:55:03 -0700 (PDT)
From: Santiago Carot Nemesio <sancane.kurento@gmail.com>
Date: Fri, 17 Jun 2016 11:55:03 +0200
Message-ID: <CAHBuHNBabbwpCQNq-x_g7i3Ko27gkeo-zYZTLPQXDXUE09ac=Q@mail.gmail.com>
To: mmusic@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/IVLDCV4joTD-uVWLZO3PHpG7c_4>
Subject: [MMUSIC] rfc5888: Multigroup management
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 17 Jun 2016 09:57:23 -0000

Hi.

First of all, let me know if this list is the right place to deal with
this kind of questions, if this is not, please I would really
appreciate if you could address me to the right place.

I'm facing a problem regarding on how to identify groups when dealing
with negotiation which several groups might be involved in, specially
when groups involved have the same semantic.

Suposse there is an offer with next groups attributes:
...
a=group:LS 1 2 3
a=group:LS 1 2
...

Suppose that the other peer only supports medias identified by the
mids 1 and 2. Next would be the answer:
...
a=group:LS 1 2
a=group:LS 1 2
..

so attribute order is not mandatory and there is not way to identify
groups, how can the offerer know which group was offered with medias
1, 2 and 3, note that the answerer could have changed the order of the
attributes in the answer making this discrimination almost impossible.

Am I missing somthing, RFC58888 only warns you about that there may be
several a=groups lines in a session description, but not specifies how
to deal with this. Does attribute order matter for groups, if not how
can above situation be managed?

Regards.