Re: OfferToReceive in CreateAnswer

On 10/28/2012 02:34 PM, Harald Alvestrand wrote:
> On 10/28/2012 12:47 PM, Hutton, Andrew wrote:
>> On 28 October 2012 07:48 Harald Alvestrand Wrote:
>>
>>> The problem raised is what OfferToReceive means when you're in answer
>>> mode..... the absolutely simplest resolution is to say "OfferToReceive*
>>> is meaningless when you answer and has no effect".
>>>
>>> But the text should be clear about what the effect is.
>>>
>> The constraint to indicate that the application only wants to receive
>> video surely applies to the answer as much as it applies to the offer
>> the problem is that the name and the text in the draft implies to that
>> it only relates to the offer.
>>
>> I am assuming that this relates to the direction attribute in SDP and
>> so why does the API not also include the other options?
> Sorry, I can't parse this sentence.... the intent of the ability to do
> constraints is that the application should indicate what it wants to do,
> and the browser should tweak the offer (or answer) to fit. This may
> cause offering or refusing to accept m-lines, or flipping around with
> the direction attributes; if we conclude that all m-lines should always
> be accepted, independent of the tracks and constraints, but that they
> should be set to a=inactive when the user doesn't want to use them,
> that's a logical conclusion.
>
> But it's not the only possible one.
>
> (personally, the only consideration I consider important here is that
> two applications that connect without setting any options should be able
> to use audio and video. Everything else is for specialized use cases,
> and those who want to use those use cases should indicate what they
> desire.)
+1

And I think OfferToReceive* would mostly be useful in interop cases.

For the browser-browser case; imagine a situation where the session 
initiator (A-side) doesn't have a camera, and the app does not use 
OfferToReceive video; but the answerer has a camera and is willing to 
send video.

As per the latest JSEP draft, what would happen is that the offer from 
the A contains an audio m-line only; the B-side answers to it and audio 
starts flowing A->B. The B side then adds its local stream with audio 
_and_ video to the PeerConnection at the B-side; as a result an offer 
with two m-lines (audio and video) is sent to A; and there will be audio 
only A->B and audio+video B->A.

>
>

Received on Monday, 29 October 2012 06:39:46 UTC