- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Sun, 28 Oct 2012 19:49:24 +0100
- To: public-webrtc@w3.org
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