- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Fri, 6 Mar 2015 14:03:24 +0100
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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