Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API

[Iñaki Baz Castillo <[e-mail]>]

2013/7/3 Stefan Håkansson LK <[e-mail]>:
> One way in this specific case could be that Bob's application (since Bob
> does not want to see Alice) simply does not show the video. Bob's
> application could in addition signal this to Alice's application (in
> some app proprietary way) and Alice's app could remove the video stream
> (or track) from PeerConnection to save bandwidth and processing.

Let me understand it:

So we are forced to use SDP in any WebRTC application but we cannot
use SDP for common features (i.e. detecting that the remote peer has
rejected our new offered stream/track). Thus regardless we use SDP we
cannot do SIP, right? and instead we must use a proprietary signaling
mechanism for those so common features already present in SIP and SDP,
right?

So live with SDP but don't use SDP, am I wrong?

So be free to implement any custom signaling protocol (proprietary
protocol) but not a standard like SIP since SIP's SDP usage cannot be
implemented in WebRTC, right?

Opss, I forgot, I can parse my new generated SDP at JS level (the SDP
with my new video stream/track offer) and then also parse the received
SDP, and detect wheter there is "a=inactive" or "m" line with port 0
to detect that the remote has rejected my stream. Am I really right?

Regards.


--
Iñaki Baz Castillo
<[e-mail]>