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

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

That is not what I understand from the above text from Harald:

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

If our SDP answer has a=recvonly then it is "affecting the sending of
similar media" since, in fact, we are NOT sending it.
And if it becomes port 0, then there won't be sending nor receiving 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.

That's the problem. You receive a SDP offer indicating one audio track
and one video track. If you want to receive both but just send audio
you must "reject" the video m line (with "a=recvonly"). And worse, if
the received SDP offer just has an audio m line then you cannot send
video to that peer (unless renegotiation is performed later). Well,
but that is the definition of SDP, something initially designed to
have a single full-duplex audio communication.






-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Friday, 6 March 2015 12:35:11 UTC