Re: [MMUSIC] A proposal for how we would use the SDP that comes out of the MMUSIC interm

[Byron Campen <[e-mail]>]

On 10/9/15 12:56 PM, Peter Thatcher wrote:
>
> If the JS wants to send more information about what semantics it is 
> giving to each encoding/rsid, it is more than capable of doing so in 
> its signalling to the server.  We don't need to put all signalling 
> into SDP.
> We may choose, for convenience of the JS, to put a minor amount of 
> signalling in the JS, like we put the track ID into the SDP.  If so, 
> what you're really advocating for is an RSID that's a string instead 
> of an int:
     I thought about this (in fact, the rid value is already a string so 
you could do this with the present draft), but I'm not exactly happy 
with it. I appreciate the temptation to say that since this is webrtc, 
it is ok to just have the application hard-code stuff(eg; the meaning of 
the rid value "small"), and disallow any negotiation, but these are not 
properties you typically find in an IETF spec, for good reason.

     That said...
> ​I would point out, though, that the conference server really doesn't 
> need to know anything about the RSIDs.  It already knows the sizes of 
> the layers from the media itself and can just use that to choose what 
> to forward.  ​It just needs the RSIDs to know which FEC or RTX stream 
> goes with which layer.
>
     ...it might be doable to allow parameterless rid for send with the 
understanding that the receiver will figure out what to do by watching 
the RTP, _probably_ with an eye toward overall bitrate (since a lot more 
can vary besides resolution). This requires no hard-coding of semantics 
for "small", which is good. This is harder to implement, though. 
Ultimately, you're going to need to bring this idea to mmusic, the 
sooner the better.
>
>     Regarding PT demux, it is fine if we do not support sending an
>     offer with PT demux, but if a conferencing server sends us an
>     offer that uses PT demux, we kinda have to play along.
>     ​ ​
>     mmusic is not going to be happy if we say we'll reject such an
>     offer in rtcweb-jsep.
>
> ​
> ​ What goes out in the offer matters very little.  It's what goes out 
> as RTP that really matters.  And saying that the conference server can 
> request PT-based simulcast is 99% the way there to saying PT-based 
> simulcast is fully required ​
> ​
> ​ in WebRTC 1.0.  And I'm opposed to that.  ​
> ​
> If that's a requirement for simulcast in WebRTC 1.0, then I'd rather 
> have simulcast not be in 1.0.​
> ​  ​
>
> I think it is a valid choice to say WebRTC will only use a 
> non-PT-based subset of the MMUSIC work.  There's *a lot* of SDP out 
> there that WebRTC doesn't support, and PT-based simulcast would just 
> be one more of those things.
>
    I don't like PT demux any more than you, but what you're talking 
about here is implementing part of a spec, but omitting mandatory parts 
of it. This is not subsetting. You need to bring your objections to 
mmusic. There may be some compromise that can be worked out there.

Best regards,
Byron Campen