Re: Summary of replace track status

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".  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".



On Fri, May 22, 2015 at 11:51 AM, Adam Roach <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
>