- From: Eric Rescorla <ekr@rtfm.com>
- Date: Wed, 19 Sep 2012 08:16:44 -0700
- To: "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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 15:17:53 UTC