On Wed, Jul 24, 2013 at 2:27 AM, Iņaki Baz Castillo <ibc@aliax.net> wrote: > 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? I think you're misunderstanding the context in which an error would be fired. It's not going to be in response to the other side rejecting the offer but in response to the PC not being able to construct a new offer which would reflect the stream. Recall that the effect of invoking addStream() is to call .onrenegotiationneeded() not to actually exchange any signaling messages. To give an example, consider what happens if you add a closed stream. This isn't ever going to work, so there needs to be an error reported here, even though we have no idea of the other side's capabilities. -Ekr 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 14:25:58 UTC