W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2015

Re: Should pc.getRemoteStreams() include all remote tracks after pcsetRemoteDescription() ?

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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D1AAACF@ESESSMB209.ericsson.se>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC