Re: "pranswer" status (or get rid of it)

> On May 22, 2017, at 4:49 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> 
> Hi,
> 
> Firefox does not support "pranswer" and Chrome breaks ICE/DTLS things
> if "pranswer" is used.
> 
> I still see the "pranswer" monster in the WebRTC 1.0 draft. We don't
> need it. It can be perfectly emulated via JS by means of (assuming
> SIP):
> 
> 1) pc.createOffer() => offer
> 
> 2) pc.setLocalDescription(offer)
> 
> 3) Send INVITE
> 
> 4) Receive 183 with SDP
> 
> 5) pc.setRemoteDescription(pranswer)
> 
> 6) Receive 200 with SDP
> 
> 7) pc.setLocalDescription(pc.localDescription)
> 
> 8) pc.setRemoteDescription(answer)
> 
> "pranswer" is the ugliest and most useless stuff in WebRTC API and
> nobody implements/uses it.
> 
> Can we get rid of it before 1.0.0 is out?
> 
> -- 
> Iñaki Baz Castillo
> <ibc@aliax.net>
> 

I'm not sure exactly how to say this but many of your email suggest you might be missing a subtle detail here. 

Lets say the offer in step 1 included a hardware codec for video, the question of relevance for browsers is if in step 5 the SDP did not use that hardware codec, are the resources freed so another tab or application could use the hardware codec. In step 8, if that SDP used the hardware codec, that would fail if they were freed in step 5 and used by something else. The differences between pranwser and answer in webrtc is basically if the unused resources from the offer are freed for other uses or not. The only people that have to do extra work to support this are browsers and most of the major ones plan to do it but it is not high priority. It becomes more important as multiple things are using resources at the same time and as there is more support for hardware codecs.

Received on Monday, 22 May 2017 22:44:58 UTC