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

[Byron Campen <[e-mail]>]

On 10/21/15 3:27 PM, Harald Alvestrand wrote:
> On 10/21/2015 08:35 PM, Martin Thomson wrote:
>> On 21 October 2015 at 06:57, Harald Alvestrand <[e-mail]> wrote:
>>> 1 - Toss all RIDs that it cannot parse fully
>> This.
>>
>> If you were able to handle options that didn't limit goats, then you
>> can add an alternative profile that doesn't include any max-goats
>> constraints:
>>
>> 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=rid:5 recv max-fr=10
>> a=rid:6 recv max-fr=5
>> a=rid:7 send max-fr=10
>> a=rid:8 send max-fr=5
>> a=simulcast: send rid=3;4,7;8 recv rid=1;2,5;6
>>
>> (I've probably gotten the syntax off here, but I hope that this is clear enough.
> But to a receiver that understands max-goats, this is a profile that
> says "send me 4 simulcast streams if you feel like it", not "send me
> either these two or those two".
>
> This may be harmless, but it may be surprising.
>
>
     a=simulcast: recv rid=1,5;2,6 send rid=3,7;4,8 means that there are 
two simulcast streams each for send and recv, and each of those may use 
one of two rids (but not both at the same time). Now, if the answerer 
doesn't remove any rids, that allows either end to switch out which rid 
it uses at will, which is pretty weird. Don't know why anyone would 
actually do this though, but it probably wouldn't cause too much havoc.

Best regards,
Byron Campen