- From: Eric Rescorla <ekr@rtfm.com>
- Date: Fri, 1 Jun 2012 07:51:56 -0700
- To: Justin Uberti <juberti@google.com>
- Cc: Cullen Jennings <fluffy@cisco.com>, public-webrtc@w3.org
On Fri, Jun 1, 2012 at 6:40 AM, Justin Uberti <juberti@google.com> wrote: > > > On Fri, Jun 1, 2012 at 12:40 AM, Eric Rescorla <ekr@rtfm.com> wrote: >> >> 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. > > > I'm not sure createAnswer needs to know if it's a PRANSWER or ANSWER, as > this is simply a choice by the application to finalize the offer-answer > exchange or not. So with that removed, it's simply a question of whether an > arbitrary answer created by CreateAnswer can be used as a PRANSWER or > ANSWER, and I think that this should be allowed. > > My intent was that you could always apply a (pr)answer as either type (i.e., > into setLD/setRD). In fact, some of the serial forking scenarios depend on > the ability of the caller to choose which answer is treated as final. I haven't worked through this completely, but I wonder if there is an opportunity to get confused in federated cases. Consider the 1-800-go-fedex case. I had assumed that the callee would do: 1. PR_ANSWER with one-way media (from the callee to the caller) 2. ANSWER with two-way media. In that case, if the caller imposes the PR_ANSWER as a final answer, isn't this going to create an error? Or have I misunderstood. Regardless, if we decide that they are interchangeable in this respect IMO we should remove the argument from createAnswer(). -Ekr
Received on Friday, 1 June 2012 14:53:05 UTC