Re: OfferToReceive in CreateAnswer

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

Received on Sunday, 28 October 2012 13:34:31 UTC