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

On 06/03/15 13:34, Iñaki Baz Castillo wrote:
>>> 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

I think he meant "sendonly"

> 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 think you're describing the difficulties with SDP and O/A - but from 
an app perspective I think it is quite easy. Just .stop() tracks you 
don't want to receive, and add tracks you want to send. The 
"negotiationneeded" event will fire if a new offer needs to go out.

>
>
>
>
>
>

Received on Friday, 6 March 2015 12:50:49 UTC