Re: [MMUSIC] Simulcast worries: Fallback in the a=rid language

[Peter Thatcher <[e-mail]>]

I can think of some more alternatives:

Alternative 4.  Offer doesn't constrain max-goats until it know the
answerer supports and then does a re-offer with max-goats constrained:

offer 1:

a=rid:1 recv max-goats;max-fr=50
a=rid:2 recv max-goats;max-fr=20
a=rid:3 send max-goats=44;max-fr=20
a=rid:4 send max-goats=22;max-fr=10
a=simulcast: send rid=3;4 recv rid=1;2

answer 1:

a=rid:1 send max-goats;max-fr=50
a=rid:2 send max-goats;max-fr=20
a=rid:3 recv max-goats=44;max-fr=20
a=rid:4 recv max-goats=44;max-fr=10
a=simulcast: recv rid=3;4 send rid=1;2

offer 2:

a=rid:1 recv max-goats=47;max-fr=50
a=rid:2 recv max-goats=22;max-fr=20
a=rid:3 send max-goats=44;max-fr=20
a=rid:4 send max-goats=22;max-fr=10
a=simulcast: send rid=3;4 recv rid=1;2

Problem: You'd probably need a re-offer for all recv lines doing this,
since all attributes are optional.




Alternative 5.  Accept all RIDs, drop constraints it does not understand,
*but remove the problematic RIDS from the simulcast line*.

Offer 1:

a=rid:1 recv max-goats=47;max-fr=50
a=rid:2 recv max-goats=22;max-fr=20
a=rid:3 send max-goats=44;max-fr=20
a=rid:4 send max-goats=22;max-fr=10
a=simulcast: send rid=3;4 recv rid=1;2

Answer 1:

a=rid:1 send max-fr=50
a=rid:2 send max-fr=20
a=rid:3 recv max-fr=20
a=rid:4 recv max-fr=10
a=simulcast: recv rid=3;4

Offer 2:

a=rid:1 recv max-fr=50
a=rid:2 recv max-fr=20
a=rid:3 send max-fr=20
a=rid:4 send max-fr=10
a=simulcast: send rid=3;4 recv rid=1;2


Alternative 6.  Mark constraints as optional

Offer 1:

a=rid:1 recv max-goats=47?;max-fr=50
a=rid:2 recv max-goats=22?;max-fr=20
a=rid:3 send max-goats=44;max-fr=20
a=rid:4 send max-goats=22;max-fr=10
a=simulcast: send rid=3;4 recv rid=1;2

Basically, have a marker for "I'd prefer this be the max, but if you don't
support this kind of max, at least send me something".  Notice the "?".







On Wed, Oct 21, 2015 at 6:57 AM, Harald Alvestrand <[e-mail]>
wrote:

> I'm worried about the extensibility of the constraints model in the RID
> language.
> Consider for instance this situation:
>
> - A knows about a new constraint "max-goats"
> - B doesn't know about it
>
> A sends:
>
> a=rid:1 recv max-goats=47;max-fr=50
> a=rid:2 recv max-goats=22;max-fr=20
> a=rid:3 send max-goats=44;max-fr=20
> a=rid:4 send max-goats=22;max-fr=10
> a=simulcast: send rid=3;4 recv rid=1;2
>
> This indicates that A offers two simulcast layers and is willing to
> receive two.
>
> B does not know about "max-goats". It's willing to do simulcast and obey
> the FR constraint, but it has no way of knowing whether the streams it
> generates will violate the goats restriction or not.
>
> Alternatives:
>
> 1 - Toss all RIDs that it cannot parse fully
> 2 - Accept all send RIDs that it can promise to handle, toss all receive
> RIDs that it cannot promise to restrict itself to (because it doesn't
> understand the restriction).
> 3 - Accept all RIDs, drop constraints it does not understand.
>
> Resulting SDP would be:
>
> 1:
>
> a=simulcast:
>
> doesn't look good. You're not going to simulcast today.
>
> 2:
>
> a=simulcast:recv rid=3;4
> a=rid:3 recv max-fr=20
> a=rid:4 recv max-fr=10
>
> Works for incoming simulcast to B, but the ability to simulcast to A has
> been lost: Expanding the language at A has created failure modes that
> lead to lost functionality.
>
> 3:
>
> a=simulcast: recv rid=3;4 send rid=1;2
> a=rid:1 send max-fr=50
> a=rid:2 send max-fr=20
> a=rid:3 recv max-fr=20
> a=rid:4 recv max-fr=10
>
> We keep simulcast capability, but if the goats restrictions were
> important to A, it will now have to detect that capabilities were
> dropped, and will have to do another offer/answer in order to prevent
> itself being overrun by goats from B.
>
> What's the USEFUL semantics to support on extensibility?
>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>