W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: do we want success and failure callbacks on addStream?

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 24 Jul 2013 11:27:56 +0200
Message-ID: <CALiegf=mHqzr6H8THdypLiEp0zTQ9bcCVhoUhpheEVBenuW80g@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC