- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Wed, 24 Jul 2013 11:27:56 +0200
- To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- Cc: "piranna@gmail.com" <piranna@gmail.com>, Jim Barnett <Jim.Barnett@genesyslab.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
2013/7/24 Cullen Jennings (fluffy) <fluffy@cisco.com>: > I think we should use a callback on addStream Which information would such a callback provide? Would it be called with an "error" argument if the remote rejects ALL THE TRACKS of the stream with "port 0" in their "m" line? Would it be called with "error" argument if JUST some of the tracks of the stream are rejected? what about if an invalid SDP is returned? what about if SIP is signaed and a 488 replied? What about if the remote accepts all the tracks in the stream but set "a=inactive" for SOME of them? Since we CANNOT inspect the SDP at JS level for matching there our local streams and track, it is just impossible to realize of what happened in the remote side upon receipt of our updated offer. And again: this means that I add a video track, signal it via re-INVITE to the peer, the peer replies with "a=inactive" or port 0 for such a track and I do not know whether the remote wants to receive my video or not. Yes, it could signal me (via custom sig protocol) something like "I do not want your video" but that is not feasible if we play SIP since such a signaling is done via SDP. -- Iñaki Baz Castillo <ibc@aliax.net>
Received on Wednesday, 24 July 2013 09:28:44 UTC