Subject: [MMUSIC] rfc5888: Multigroup management

From: Santiago Carot Nemesio <[email-masked]>
Date: Fri, 17 Jun 2016 11:55:03 +0200

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.

---

From: Bo Burman <[email-masked]>
Date: Mon, 20 Jun 2016 13:39:22 +0000

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.

If on the other hand two different grouping semantics were used in the offer, like
a=group:LS 1 2 3
a=group:BUNDLE 1 2
and if, as in your example, the answerer does not support media with mid 3, the resulting
a=group:LS 1 2
a=group:BUNDLE 1 2
still makes sense, where media 1 and 2 are both lip-synchronized and part of the same BUNDLE.

I don't think this is possible to generalize, since you could envision grouping semantics (current or future) that has some implicit or explicit relation. Grouping semantics could for example be defined such that they are mutually exclusive. Say, "this is media only from cows" and "this is media only from foxes"; a media line belonging to both of those groups would describe media from one strange animal. The RFC 5888 grouping is to be seen as a general signaling mechanism and does not concern itself with specific grouping semantics.

Best Regards
/Bo

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Santiago Carot Nemesio
> Sent: den 17 juni 2016 11:55
> To: [email-masked]
> Subject: [MMUSIC] rfc5888: Multigroup management
> 
> 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
> 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.
> 
> 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.
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Santiago Carot Nemesio <[email-masked]>
Date: Tue, 21 Jun 2016 10:58:24 +0200

Hi,

thanks a lot for your reply, see comments below.

> 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…

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