Re: [MMUSIC] Partial Offer/Partial Answer draft

[Adam Roach <[e-mail]>]

On 10/14/13 19:28, Martin Thomson wrote:
> On 14 October 2013 17:22, Adam Roach <[e-mail]> wrote:
>> It's certainly not unsolvable, it's just unsolved. From an information perspective, it can be done unambiguously. We just need to come up with an elegant syntax.
> Leaving impossibilities regarding the juxtaposition of the terms
> "elegant syntax" and "SDP" aside, I don't disagree.  I'm just
> disappointed that you didn't try.

The issue here was actually having too many ideas, not lacking any; and 
spelling all of them out in formal detail would have made the "open 
issue" much larger than was reasonable. I briefly considered putting 
several of them into an appendix, but writing out these approaches at 
the level of formality worthy of a document would have delayed things by 
another day or two, and I already was running much later delivering this 
than I was happy with.

I'll sketch out three of the more interesting ways you can skin this cat 
below.

>  From an information perspective, would you consider a partial offer
> that amends a group to (potentially) generate glare for all of the
> lines already in that group?  E.g., I have a group of "a b c" and
> generate a partial offer to add "d" to that group.  Does this cause
> glare with an offer to amend any of "a", "b", or "c"?

I would hate that.

> I think that could be made to work, but I don't like the
> ramifications.  Without further consideration, all I can envisage is
> the creation of a new grouping semantic.  Maybe I'm just being a
> little pessimistic.

I think so. Either that or just a bit unimaginative.

For the trivial case where we care *only* about being able to put new 
lines into bundles, we could very easily specify that any new media 
section that contains the same port as one or more other media sections 
is implicitly added to the same bundle as those media sections. It's an 
easy, clean, "done and done" solution. It's also very specific to 
solving the BUNDLE case (which is the must-have here) which means that 
it leaves any other grouping (LS, FID, SRF, ANAT, FEC, DDP) out to dry. 
For that reason, I don't think this is the approach we want.

The other two solutions that I would propose, which solve the general 
grouping case, are somewhat less elegant syntactically (all sniping 
aside), and vary primarily in how they choose to identify group lines. 
In the first case, you identify the a=group lines at the session level 
by the order in which they appear (the first one has an index of 1; the 
second has an index of 2; and so on).

Then, we could do something like define a new attribute, valid only in 
sdpfrag, and stripped out between partial processing and incorporation 
into the overall session, that indicates "this media section is also 
added to the indicated group."

For example, if you had an ongoing session that looked like this (yeah, 
I'm just grabbing from RFC 5888 because it's the easiest way to 
demonstrate my point, although I've changed the MIDs to match the notion 
of randomness that pof/pan calls for):

v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V
m=audio 30000 RTP/AVP 0
a=mid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN
m=video 30002 RTP/AVP 31
a=mid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V

And wanted to add a new video stream to the LS group, you could send a 
partial offer like:

m=video30004 RTP/AVP 31
a=mid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO
a=add-group:1

And that would mean "add this media to the first a=group line that is 
indicated at the session level," resulting in an final session that 
looks like this:

v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS ZLSQLQ*YBSYMLZD4ETXME5892052JKRN 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V
UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO
m=audio 30000 RTP/AVP 0
a=mid:ZLSQLQ*YBSYMLZD4ETXME5892052JKRN
m=video 30002 RTP/AVP 31
a=mid:8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V
m=video  30004 RTP/AVP 31
a=mid:UUWPVLGKPFU#*OI!GB**B*9S5E4#1RKO

(Note the on the a=group line is different than it had been before; also 
note that the third m-section does not include an "a=add-group" 
attribute, even though one was present in the partial offer).

An alternate approach, if we think that the use of numerical indices to 
point to the group we're talking about, is to instead say "add to the 
group that is uniquely identified as containing at least the following 
MIDs (and probably some others too)." For this example, the end result 
is the same, but the "add-group" attribute would instead look something 
like this:

a=add-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V

Which means "there is only one LS group that contains the MID 
8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V, and this media section should be added 
to it." If the combination of LS and "8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V" 
were not sufficiently unique to identify the group, then the attribute 
would include enough other MIDs until the group were uniquely 
identified; e.g.:

a=add-group:LS 8WVTFSA^ASZ7R70!9#OZ0WRKA0BR-J1V 
ZLSQLQ*YBSYMLZD4ETXME5892052JKRN

And so on. If, by some fluke, you wanted to add a new media section to a 
group that happened to be of the same type as another group whose 
members were a strict superset of the group you wanted to talk about, 
you'd have to fall back to a full offer. This is such an extreme corner 
case, however, that I don't think it bears much hand-wringing to worry 
about the glare that might result from such a situation.

For both of these last two cases, we would probably want to allow a 
partial offer or partial answer to also include an "a=group" at the 
session level, but only if it is defining a completely new group (i.e., 
not expanding an existing group). If we do this, we might choose to 
allow such POFs and PANs to incorporate media sections that aren't 
described in the sdpfrag (that is, existing and otherwise unmodified 
media sections). This does make the index-based approach to indicating 
group lines a bit more fiddly, as we need to define a canonical ordering 
for group lines in the rare circumstance that both sides try to add a 
new group simultaneously. As with this issue itself, it's an eminently 
solvable problem, but it *is* more specification and more code.

Of these three approaches, which I think are the most promising of the 
ones I've been able to come up with, I personally like the last one 
(where you describe a group by its type and the smallest set of MIDs 
required to uniquely identify it). I suspect they could all be refined 
and made slightly more elegant if we had enough people put their minds 
to the issue.

/a