- From: Eric Rescorla <ekr@rtfm.com>
- Date: Thu, 31 May 2012 21:40:50 -0700
- To: Justin Uberti <juberti@google.com>
- Cc: Cullen Jennings <fluffy@cisco.com>, public-webrtc@w3.org
On Thu, May 31, 2012 at 9:17 PM, Justin Uberti <juberti@google.com> wrote: > I think I could also go either way, but here are some reasons why we might > not want to embed the type information in the SessionDescription: > > Not clear what type should be for Specifically, the > PeerConnection.localDescription and .remoteDescription properties (could > be the type of the last-supplied SessionDescription, but seems like > unnecessary information to store; also could be null/empty string in this > case) > Use of PRANSWER vs ANSWER feels like an application decision; application > may want to either > > set a local PRANSWER, which means the type property needs to be mutable, or > we need to pass some param into CreateAnswer (which seems somewhat ad hoc in > the current draft) > apply a received ANSWER as a PRANSWER, which means the type property needs > to be mutable, or the application needs to munge the received JSON string. Is it safe to get an answer via createAnswer(PRANSWER) and then doSetLocal(ANSWER) or createAnswer(ANSWER), setLocal(PRANSWER)? My intuition would have been no [queue discussion of when callee.onaddstream() is called], but I'm willing to be convinced it's safe. If so, though, we should probably explicitly state it in the spec. -Ekr
Received on Friday, 1 June 2012 04:42:01 UTC