RE: OfferToReceive in CreateAnswer

On 28 October 2012 13:34 Harald Alvestrand Wrote:
> To: Hutton, Andrew
> Cc:
> Subject: 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. 

Agreed so why does the current constraints API only include the option for receive only when there are other options that the application might want such as send only.

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

Sorry but I don't think that is a logical conclusion as "a=inactive" does not mean that the user doesn't want to use them it simple means they are inactive and this usually means for a temporary period after which a new offer will change the direction again. Also RTCP does not stop when the stream in inactive.  

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

Ok so somebody must have stated a use case for the receive only case but if the constraints API is going to be used to set the direction in this way it needs to be able to support all the direction options. If you can imagine a use case that needs to set the direction to recvonly it is just as easy to think of one that will need sendonly or inactive.


Received on Sunday, 28 October 2012 16:03:20 UTC