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

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. What about if I want to stop such a
remote track later during the call? renegotiation needed? Yes.


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




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

Received on Friday, 6 March 2015 13:04:12 UTC