Re: [MMUSIC] Partial Offer/Partial Answer draft

[Christer Holmberg <[e-mail]>]

Hi,

> 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"?

Well, there are cases where the adding of "d" could implicitly affect "a", "b" and/or "c".

Example:

    - Assume you use BUNDLE, and "a", "b" and "c" have previuosly been added to a BUNDLE group, sharing a single address.

    - Then, Alice sends a POF, which adds "d" to the BUNDLE group, AND also requests the "d" address to become the new BUNDLE address.

    - If the new address is approved by the answerer (Bob), that means that the address of "a", "b" and "c" will implicitly change.

    - Now, if Bob at the same time sends a POF in the other direction, towards Alice, modifying "a", "b" and/or "c", there might be a glare situation, in which Alice should reject the POF.

The easiest way to prevent this would be to say that an Offer/POF, MUST include all m- lines which may be affected (explictily or implicitly) by the Offer/POF.

Maybe change of BUNDLE address isn't the most realistic example, but there are also SDP attributes etc which must be identical for each m- line within a BUNDLE group, etc.

Regards,

Christer



















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=video 30004 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