RE: OfferToReceive in CreateAnswer

On 28 October 2012 18:49 : Stefan Hakansson wrote:
> 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.
> 

I disagree and believe it is equally important in the browser to browser case as would be the other missing options for setting the direction to sendOnly and Inactive. The use cases are the same in the browser to browser case as the interop case.

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

In this case what will the answer from A contain if the application does not call "OfferToReceive"?

In the case when both A and B have cameras and initially negotiate audio and video then there still has to be a way of changing the direction in a new offer for an existing stream. I assume the same constraints API could be used in this case and would need for example the option to set the direction to inactive to indicate a temporary pause to video in both directions and again I see nothing specific to an interop scenario.


Andy

 



> >
> >
>

Received on Monday, 29 October 2012 09:33:54 UTC