Re: [MMUSIC] POF/PAN: SDP group attribute in a POF/PAN?

[Paul Kyzivat <[e-mail]>]

On 10/21/13 3:29 PM, Adam Roach wrote:
> On 10/21/13 12:54, Christer Holmberg wrote:
>> one also needs to specify the location of the m- line mid value in the
>> group:BUNDLE mid value list.
>
> I don't believe that's true.
>
> The only ordering consideration that I'm aware of for group:BUNDLE is
> that the first indicated mid is the one that the transport information
> is taken from. By the time we're into partial exchanges, the transport
> information for all the lines in the same bundle should be identical.

I guess that could be specified as a requirement for use of POF.

> To ensure a common view of groups, we probably want to define things
> such that new lines added to a group are appended to the list. Is there
> any reason you can think this doesn't work for BUNDLE?
>
> To be clear, let's set aside the prospect of changing transport
> addresses for a BUNDLE: I don't think it's unreasonable to require a
> full offer/answer exchange to do that kind of thing.

In conjunction with limiting to groups with all m-lines/ports the same, 
that does simplify things.

There remains the problem of indicating *which* (if any) group a newly 
added m-line joins.

There could be many group lines, even multiple with the same semantics. 
In particular there could be several independent bundles. There is 
nothing that is guaranteed to uniquely identify one of them.

The best I can see is to invent some new media-level attribute. For 
example, a=groupref. This could have the same syntax as a=group, but 
different usage. The 'semantics' and 'identification-tag's in it would 
be used to query a=group lines in the full SDP. Any that match would get 
the mid of this new m-line added. (This would allow you to say "I want 
this m-line bundled the same as this other m-line.) We might allow "*" 
to wildcard the semantics so you could add the m-line to different kinds 
of groups.

Of course there could be an error if this groupref didn't match 
anything. That could be defined to either fail, add to no group, or 
define a new group.

This would be a funny kind of SDP attribute, because it might not have 
meaning in a full SDP. (Or I guess it could be defined to work in a 
similar way. There would be some differences.)

	Thanks,
	Paul