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

On Fri, Jun 1, 2012 at 10:51 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> 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.
>

Yes, definitely - the state machine won't tolerate PRANSWER after ANSWER;
doing this kind of mutation will usually lead to tears.

What we want to do is to support the converse - multiple callees all send
ANSWERs, but the caller wants to apply some sort of last-one-wins policy
(for whatever reason), so all ANSWERs are treated as PRANSWERs until the
caller decides to pick one as the final ANSWER.


> Regardless, if we decide that they are interchangeable in this respect
> IMO we should remove the argument from createAnswer().
>

Agreed.

>
> -Ekr
>