W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

Re: Interaction of AddStream and OfferToReceive

From: Justin Uberti <juberti@google.com>
Date: Wed, 19 Sep 2012 14:44:20 -0700
Message-ID: <CAOJ7v-0tnDaZGGjBO0LxQ+Enu2dvFoKO_sqZSrnhh-wuHQ6EXg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Your table looks right to me.


On Wed, Sep 19, 2012 at 8:16 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Wed, Sep 19, 2012 at 8:04 AM, Suhas Nandakumar (snandaku)
> <snandaku@cisco.com> wrote:
> >
> >
> > Sent from my iPad
> >
> > On Sep 19, 2012, at 7:23 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:
> >
> >> I am trying to get clear on the interaction of the
> >> OfferToReceive{Audio,Video} with
> >> which m-lines go in the SDP. My general model is that the browser tries
> to
> >> guess based on what streams you add and then you can finely control it
> >> with constraints. I.e., I believe you get the following table for audio
> and a
> >> similar one for video:
> >>
> >>
> >>                                |    AddStream(audio)   |    No
> AddStream(audio)
> >>
> -------------------------------------------------------------------------------
> >> OfferToReceiveAudio unspecified |    m=audio, sendrecv  |    no m-line
> >>> case 1 here can be m=audio with port set to 0 to indicate interest in
> the audio but will be added eventually. in this case the direction can be
> inactive and be updated on negotiation.
>
> I don't know what "case 1" is.
>
> Regardless, I don't understand the point of adding an m-line for audio
> if the user has
> expressed no interest in audio.
>
> -Ekr
>
>
Received on Wednesday, 19 September 2012 21:45:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 19 September 2012 21:45:09 GMT