[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.
- Re: [MMUSIC] rfc5888: Multigroup management Santiago Carot Nemesio
- Re: [MMUSIC] rfc5888: Multigroup management Bo Burman
- [MMUSIC] rfc5888: Multigroup management Santiago Carot Nemesio
- Re: [MMUSIC] rfc5888: Multigroup management Bo Burman