Re: [Bug 17249] New: SdpType usage must be chosen

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.

>
> -Ekr
>