- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 6 Mar 2015 11:39:37 +0000
- To: Iñaki Baz Castillo <ibc@aliax.net>, Harald Alvestrand <harald@alvestrand.no>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 06/03/15 11:55, Iñaki Baz Castillo wrote: > 2015-03-06 11:02 GMT+01:00 Harald Alvestrand <harald@alvestrand.no>: >> I think we have agreement that calling track.stop() on an incoming track >> causes the next createOffer or createAnswer to put zero in that port number >> or putting "a=recvonly" in for that m-line. > > Yep, and that's crazy. Basically you call stop() on a remote/receiving > track and what it happens is that you won't send "similar" media to > the peer, but will still receive that track from the peer! yes, that > track in which you called stop(). This is SDP land, for IETF/JSEP. But I think you're not right. Stopping the reception of a track (track.stop()) does not need to affect the sending of "similar" media. > > This is crazy, this is SDP (where a sending track must match a receiving track). No, m-lines can describe unidirectional media (sendonly/reconly). This is (I think) already described in JSEP and SDP documents. > > I would not like to be the guy responsible of documenting that. > >
Received on Friday, 6 March 2015 11:40:08 UTC