Re: Summary of replace track status

On 5/22/15 6:09 PM, Peter Thatcher wrote:
> Thank you for the example.
>
> I don't view that as "needs renegotiation" as much as "the RtpSender 
> was configured to send in a codec it's not capable of sending". Once 
> we, someday, have direct  control of RtpSenders (sans SDP), the 
> browser would basically view this as "JS told me to do something I 
> can't do".

Or hopefully "something I can do". I hope getting rid of 
SDP-renegotiation will mean getting rid of the need for it, rather than 
getting rid of what it provides. ;)

+1 on replaceTrack not triggering renegotiation, since the whole reason 
for its existence is to avoid renegotiation. Therefore, people would 
probably rather it fail than trigger renegotiation, or they would have 
used addTrack/removeTrack. It's also easy enough to fall back to 
addTrack/removeTrack if so desired.

>   And if you view SetLocalDescription/SetRemoteDescription as a very 
> poor API for controlling RtpSenders (which, in reality, it is), then 
> this is also a case of "JS told me to do something I can't".  And all 
> the browser can do is either throw an exception or send nothing.
>
> Thus, I think we can make a general rule of "If the application 
> configures the RtpSender to do something impossible it either throws 
> an exception or sends nothing".

Certainly, RtpSender should not be required to do the impossible, but if 
you include anything requiring renegotiation in this, then I think that 
would need to be in the form of a proposal, since the spec says [1]:

"When attributes on an |RTCRtpSender| are modified, the encoding is 
either changed appropriately, or a negotiation is triggered to signal 
the new encoding parameters to the other side."

[1] http://w3c.github.io/webrtc-pc/#rtcrtpsender-interface

.: Jan-Ivar :

> On Fri, May 22, 2015 at 11:51 AM, Adam Roach <adam@nostrum.com 
> <mailto:adam@nostrum.com>> wrote:
>
>     On 5/22/15 09:56, Stefan Håkansson LK wrote:
>
>         On 22/05/15 16:15, Peter Thatcher wrote:
>         [...]
>
>                  * Detection/reporting of that negotiation would be
>             needed: as said
>                  above, there seem to be consensus of that if the new
>             track (provided by
>                  replaceTrack) would require a re-negotiation,
>             replaceTrack should fail.
>                  How quickly can this be detected? How should it be
>             reported back to the
>                  application?
>
>
>             ​I don't recall of the top of my head any situation in which
>             replaceTrack could trigger a renegotiation. Perhaps if we
>             had some
>             scenarios were we thought that might come up, we could
>             know how long it
>             would take to detect.  Does anyone have any concrete examples?
>
>         I agree, some concrete examples here would be helpful.
>
>
>     Here's the easy example: I've started a session with a stream
>     comes from a USB camera with an on-chip H.265 encoder, so the
>     codecs I've indicated in my offer include H.265. The answer only
>     indicated H.265 for this stream.
>
>     I have another stream, from a different source, which I cannot
>     encode to H.265 real-time. I call replaceTrack to swap this stream
>     in for the H.265 stream. Unless we renegotiate the media line,
>     this isn't going to work.
>
>     /a
>