Subject: [MMUSIC] RID negotiation enhancements

From: Adam Roach <[email-masked]>
Date: Mon, 2 Nov 2015 14:24:18 +0900

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Nov 2015 14:45:05 +0900

On 2 November 2015 at 14:24, Adam Roach <[email-masked]> wrote:
> 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”

Note that the offerer either does not have any way to permit the use
of "max-goats" if it does not understand the extension.  Thus, in
effect the answerer is already doing this.

I think that we should change the semantics to allow the answerer to
ignore and remove stuff it doesn't understand on the offerers "send"
RIDs, as you propose.

---

From: Adam Roach <[email-masked]>
Date: Mon, 2 Nov 2015 14:49:23 +0900

On 11/2/15 14:24, Adam Roach wrote:
> 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.
>

It has been brought to my attention that this was not a complete 
expression of my thoughts on the topic. I meant to say something like "I 
do not recommend we pursue such a mechanism."

/a

---

From: "Roni Even" <[email-masked]>
Date: Mon, 2 Nov 2015 16:01:38 +0200

Hi Adam,
This make sense to me  just some comments for the last case

So we have two cases of handling rid 1 and 3. The above ,means no support for max-goat while the following response means that the answerer supports max-goats but is not going to send it now but may send it later using a new offer/answer exchange

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”

 Offer:

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

[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

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic