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 UTC