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

On 06/03/15 14:03, Iñaki Baz Castillo wrote:
> 2015-03-06 13:50 GMT+01:00 Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com>:
>>>> 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"
>
> That makes more sense, right. Anyhow it looks so strange for me that
> fact that we must call track.stop() on a remote track in order to
> generate a "proper" SDP answer.

We use SDP O/A to sync the session between endpoints, so the alternative 
to "call track.stop() on a remote track to generate a 'proper' answer" 
would be to mangle the SDP itself, not what I'd like to do...

> What about if I want to stop such a
> remote track later during the call? renegotiation needed? Yes.

Agreed, there would have to be a re-negotiation.

>
>
>>> 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.
>
> When it comes to renegotiation thinks become hard and a complex
> signaling plane becomes necessary. Imagine Trickle ICE is in use (so
> partial candidates are being sent on the wire) while you add more
> tracks so renegotiation must happen. I wouldn't want to deal with
> that.

Received on Friday, 6 March 2015 13:23:22 UTC