Re: [MMUSIC] rfc5888: Multigroup management

[Bo Burman <[e-mail]>]

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:[e-mail]] On Behalf Of Santiago Carot Nemesio
> Sent: den 17 juni 2016 11:55
> To: [e-mail]
> 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
> 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.
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic