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

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