- From: Matthew Kaufman <matthew.kaufman@skype.net>
- Date: Tue, 04 Oct 2011 19:27:08 -0700
- To: Neil Stratford <nstratford@voxeo.com>
- CC: Harald Alvestrand <harald@alvestrand.no>, public-webrtc@w3.org
On 9/28/2011 9:46 AM, Neil Stratford wrote: > > That would certainly be the intention. The idea is really to split > codec and ICE negotiation apart, but retain the ability to combine in > javascript to provide a PeerConnection style SDP based API if required. > This part is key, and I've brought it up in the past. The "PeerConnection" has a legitimate need to participate in the ICE negotiation, and so if ICE candidates are encoded as SDP rather than JSON it makes sense for it to generate and consume that SDP... but it is NOT appropriate for the PeerConnection to also be generating and consuming an SDP offer-answer for codec negotation. The codecs should be different objects than the PeerConnection, usable for other things (like local processing, recording, playback from file, etc.) and so it just doesn't make sense for the PeerConnection to be changing their settings at any time. (Or worse, for the PeerConnection's SDP processing to be the *only* way of changing their settings.) Matthew Kaufman
Received on Wednesday, 5 October 2011 02:28:47 UTC