[MMUSIC] RID negotiation enhancements

[Adam Roach <[e-mail]>]

In the MMUSIC meeting today, I brought up two proposed enhancements to 
the parameter extensibility mechanism.

I will mention the first one only in passing, as it did not receive any 
support in the room (and several people spoke out in opposition to it). 
It generally floated the idea of "soft constraints" that the offerer 
proposes, but doesn't want the RID to be removed if they cannot be 
honored (for whatever reason). If this sounds compelling to you, read 
the concrete proposal in the MMUSIC slides and comment on it.

Given the feedback at the meeting, I do not

The second proposed enhancement was to treat constraints in the send 
direction differently than those in the receive direction. It has been 
observed that it should not matter if the answerer doesn’t understand a 
constraint on a stream that it will receive. If the stream is being 
constrained in a way it doesn’t understand, why should it care?

Based on this, it would seem to make sense to have the answerer simply 
remove unsupported parameters from any received “a=rid:x send” lines 
(i.e. for streams the answerer will be receiving). This makes the rules 
different based on whether the line is “send” or “recv”

So, for example, if an offer contains:

    a=rid:1 recv max-br=64000;max-goats=72
    a=rid:2 recv max-br=64000
    a=rid:3 recv max-br=32000;max-goats=16
    a=rid:4 recv max-br=32000
    a=simulcast:recv rid=1,2;3,4

The the answerer, who doesn’t understand max-goats, would respond:

    a=rid:2 send max-br=64000
    a=rid:4 send max-br=32000
    a=simulcast:send rid=2;4

That's consistent with what's in the current document.

If we simply reverse the direction of the streams, we get different 
behavior:

Offer:

    a=rid:1 send max-br=64000;max-goats=72
    a=rid:2 send max-br=64000
    a=rid:3 send max-br=32000;max-goats=16
    a=rid:4 send max-br=32000
    a=simulcast:send rid=1,2;3,4

The answer omits the constraints that it doesn't understand, but keeps 
the RID lines:

    a=rid:1 recv max-br=64000
    a=rid:2 recv max-br=64000
    a=rid:3 recv max-br=32000
    a=rid:4 recv max-br=32000
    a=simulcast:recv rid=1,2;3,4

[In practice, the offerer wouldn't actually do this -- it would only 
offer rids 1 and 3; I only include 2 and 4 in the example to show the 
difference in behavior between the two directions]

We didn't discuss this, but it seems like a no-brainer. Does anyone have 
a concrete reason we *shouldn't* change the processing rules to behave 
this way?

/a