Re: [MMUSIC] rfc5888: Multigroup management

Bo Burman <bo.burman@ericsson.com> Wed, 13 July 2016 16:54 UTC

Return-Path: <bo.burman@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 734A412D0E0 for <mmusic@ietfa.amsl.com>; Wed, 13 Jul 2016 09:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 GdvK-hVFcxkE for <mmusic@ietfa.amsl.com>; Wed, 13 Jul 2016 09:54:15 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4184112B006 for <mmusic@ietf.org>; Wed, 13 Jul 2016 09:54:15 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-a9-5786723464e0
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 30.0C.18043.43276875; Wed, 13 Jul 2016 18:54:13 +0200 (CEST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 13 Jul 2016 18:53:13 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wXAc4YfU41aC/JeIw3Ow3ayXk4ys3xqF8Nxk2Y0Oyho=; b=hH4h2GJpH9NkhswM3BkSrAmTXPi0NpvuPEP53j24k/6EVbPQh8YuHTQw5jHQI5TDD4FeGPpsS3xAsqGlahQOXVhHhZVYA8Rt+s1RWG8CVVz1XpwESNB6ZQMxkJ1aSgdfPM9CJxMZRLCuCfgu0nUfQqmybkvtupwSJdiGAr1vvpo=
Received: from AM3PR07MB1188.eurprd07.prod.outlook.com (10.163.188.26) by AM3PR07MB1187.eurprd07.prod.outlook.com (10.163.188.25) with Microsoft SMTP Server (TLS) id 15.1.539.14; Wed, 13 Jul 2016 16:53:12 +0000
Received: from AM3PR07MB1188.eurprd07.prod.outlook.com ([fe80::c918:f7a3:5bb8:fbcd]) by AM3PR07MB1188.eurprd07.prod.outlook.com ([fe80::c918:f7a3:5bb8:fbcd%14]) with mapi id 15.01.0539.019; Wed, 13 Jul 2016 16:53:12 +0000
From: Bo Burman <bo.burman@ericsson.com>
To: Santiago Carot Nemesio <sancane.kurento@gmail.com>
Thread-Topic: [MMUSIC] rfc5888: Multigroup management
Thread-Index: AQHRyH6qwvVi/Rc6WU6N7AQmbRyFRJ/yXDfAgAFI7gCAIw/5IA==
Date: Wed, 13 Jul 2016 16:53:12 +0000
Message-ID: <AM3PR07MB11882BD5DBADD89C77A384A08D310@AM3PR07MB1188.eurprd07.prod.outlook.com>
References: <CAHBuHNBabbwpCQNq-x_g7i3Ko27gkeo-zYZTLPQXDXUE09ac=Q@mail.gmail.com> <AM3PR07MB1188A669C09623F656E70E638D2A0@AM3PR07MB1188.eurprd07.prod.outlook.com> <CAHBuHNC8LmYLmDcB-zm0xAqDKSeHRANfmb7NSVOV+hx2tVP8WQ@mail.gmail.com>
In-Reply-To: <CAHBuHNC8LmYLmDcB-zm0xAqDKSeHRANfmb7NSVOV+hx2tVP8WQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com;
x-originating-ip: [192.176.1.87]
x-ms-office365-filtering-correlation-id: f241c8ac-0b40-46cb-d89d-08d3ab3e2d17
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1187; 6:NH4NV8PLjAz+8Xw3yf6yg2FuKIgcLghfEw3rUZ3iyZZ27aOreSlFORdAEgc95Ob7iclteKRvUd7OUZ0O2XdxJmctsdsaTP+NH/ZsRI/ioN5f+KV0YLd1NzJF6VZNiSITWgvRuoVGqhIqUp8zq5egqC2SWBKotiCrkijoFdUFGboFwr9WnCkj1shB0xn08bXGiZgfa6E6y+3ldbEwEDRm4cof0DK7buaZVpS80ja5k9ctuUS6BNa3yUOGdedZEGlq0yd7gdsbWf9+O5hrcqyAU00meySJNUdQaUYNNWzb6ow=; 5:wQd4OdPeh9cwzdiHIHIDFdEDmDG15XBRrU/j6Xwxl0wC+fJxpZ5JroyizfbY6ynJkHhUEOvo28oGM0XDV0R5c18HTMYCtD6aNjM+1m3gRN+iKnD87hlOmrnW/7lkmkGKPvFDvuhjaKO37/sHaxkW/w==; 24:IghcdNMZhkNtrvMnzx7Y9//ECvkUyHwbOoruJT/Hsuc4As6L/nTdBAoqMgntO3587qqGn3lU/Fl0EaZHcj+EARNEyYq9J+ou3g2nWL9nAZc=; 7:GPxaYNk/M+huUcEG6sl8Uel9rzx3Osu2oW8c/20qYbIVZVF32+N8vBWtKHpo216jUGnF0qIT1wZT0KDt2k5C8MlBAUS3jrTnEb1/GhD8I4/2gbzt2aMDSK9bMVpuzwlP9LQIbxaXfHvo9oKPbz3Tw6efmPVOePOtBR0l3yr+g5mCpEcdx2hdCvkPteFiuRPlzfZ8m7xbU5GAc/AgHRnD1PK+nmJjJdBFkvfJjk3kovTO3rw0dEswalO5efRHIBTl
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB1187;
x-microsoft-antispam-prvs: <AM3PR07MB1187A7CA8E7D42BC250D3F348D310@AM3PR07MB1187.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(37575265505322);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM3PR07MB1187; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB1187;
x-forefront-prvs: 000227DA0C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(13464003)(199003)(76104003)(51694002)(189002)(66066001)(92566002)(102836003)(3846002)(81156014)(33656002)(3660700001)(6116002)(5250100002)(19580395003)(110136002)(101416001)(86362001)(19580405001)(81166006)(189998001)(586003)(87936001)(105586002)(7846002)(5002640100001)(3280700002)(9686002)(305945005)(76176999)(11100500001)(7736002)(5003600100003)(7696003)(2906002)(106356001)(106116001)(74316002)(2950100001)(54356999)(97736004)(8676002)(2900100001)(68736007)(4326007)(8936002)(50986999)(76576001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1187; H:AM3PR07MB1188.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 16:53:12.1711 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1187
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42KZGbFdRde0qC3c4NRnFoupyx+zWBx9f4nd gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4sLyFveCJQsW/Xc/YGhh/yHcxcnJICJhI zP78lQ3CFpO4cG89kM3FISRwhFFi+csJjBDOCUaJydMfs4M4LAK9zBJXWy4zg7QICVxjlOif qg9R9ZhRortxBliCTUBDYv6Ou4wgtoiAmUTbtqtAczk4mAXUJa4uDgIJCwOt/vVnJStEianE yym/2CFsJ4ndU2+AxVkEVCWmzbgIdh6vQIzEgbcH2CD2vmKU2PlVDsTmFAiU2Dt3CxOIzQj0 wvdTa8BsZgFxiVtP5jNBvCYgsWTPeWYIW1Ti5eN/rBD1kRKTJ55lBzlNQkBBYslfSYgSX4lj UxsZIex3bBJzJ9RC2G4Sz9Z9hhqZLdF28Q8TRKuVxLwzsRDh9YwSBxutIGwZidV/nzOBQkdC 4AyrxP/mpewQ56dKLF/byjiBUXsWkktngQNIU2L9Ln2IsKLElO6H7LPAnheUODnzCcsCRpZV jKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIHp4uCW31Y7GA8+dzzEKMDBqMTDq2DQGi7EmlhW XJl7iFGCg1lJhJensC1ciDclsbIqtSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQi mCwTB6dUA2P8zFc9Qlq9Pc92fprjL/lmckZy9yFj3wCdy68WLPw8fXqG1fHW+ArXNWmc/xa9 sH7ot/Huw7KNuz9PD1E4N+eZsOj5La/CSwP1U2LXvM19xnaS9+EWQ//pfz/O0Fqf2mkVk/Uk 0fzfPD6R0FNT5h2R8XTuSfWbZ15iYrCD/aXf9rTw6cet+W8qsRRnJBpqMRcVJwIAF5a2dxMD AAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/ye8KCbVzBXveyc2DinP1nxe6rac>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [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: Wed, 13 Jul 2016 16:54:17 -0000

Hi,

Apologies for the delay in responding.

I still don't really understand what you are trying to do, or what you think is not possible today?

In your original mail you said that the problem occurs when there are several groups with the same semantic. To me, that seems per definition to result in (and be identical to) a single group containing the union of mid in all sub-groups.

Why is that not OK? If there would exist a need to recognize and separate out the sub-groups from the offer in the answer, the used (common) semantic could not really be sufficient for your grouping purposes, could it? One solution could thus be to introduce another sub-grouping semantic, in addition to the "union" semantic, which is something that 5888 already supports by simply allowing for multiple groupings. How to set this additional sub-grouping in the offer depends on your need for separation in the answer.

You can obviously look to the offer to see what groups and media that are offered, and to the answer to know what groups and medias that were accepted, even per group. Any media that were offered but not accepted in the answer is not included there, so you cannot get any information about non-accepted media from just looking the answer. Do you somehow want a track-record of non-accepted media and groups in the answer?

Regards,
/Bo

> -----Original Message-----
> From: Santiago Carot Nemesio [mailto:sancane.kurento@gmail.com]
> Sent: den 21 juni 2016 10:58
> To: Bo Burman <bo.burman@ericsson.com>
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] rfc5888: Multigroup management
> 
> Hi,
> 
> thanks a lot for your reply, see comments below.
> 
> 2016-06-20 15:39 GMT+02:00 Bo Burman <bo.burman@ericsson.com>:
> > Hi,
> >
> > I think this list should be capable to answer your question.
> >
> > It seems to me that you in general need to consider the semantics of
> > the grouping. Looking to your example below, I don't really understand
> > what you try to express with a=group:LS 1 2 3 a=group:LS 1 2
> > Obviously, if media lines with mid 1, 2, and 3 are lip-synchronized (LS), so are mid 1 and 2, since it is a true subset of the
> first group. The second "a=" line is redundant even to start with. As such, just removing or disregarding the resulting
> repeated line in the answer in your example does not cause any concern or ambiguity.
> 
> This is not a real case at all, I just wanted to raise awareness about this concern, so that's just a simple example of
> ambiguity in case any peer needs to distinguis this case, So the semantic regarding of the grouping of medias is
> application dependant you can not make assumptions about what application do or even what they are trying to do, but
> from the implementation point of view perhaps you need to distinguish what group was offered with what medias and
> what medias were accepted for any specific group.
> 
> So I suspects that just as it is right now this is not possible.
> Please, fixme if I'm wrong or I'm missing something.
> 
> Thanks