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

[Stefan Håkansson LK <[e-mail]>]

On 7/2/13 6:04 PM, José Luis Millán wrote:
> Hi,
>
> Please, let me know how this normal use case could be solved with the
> current API.
>
> Alice and Bob have accessed to a Web page offering a basic WebRTC
> application   that they use to speak and see each other. They are in the
> middle of a media session right now.
>
> Alice presses the "Video" button in her web application. A SDP offer
> with video description is sent to Bob:
>
> Bob doesn't want to see her, so his web application rejects the media by
> using any valid method for that:
> -- a=inactive
> -- m=video 0

My personal view is that even if we use SDP for carrying the association 
between RTP SSRCs and the MediaStream and MediaStreamTrack structures as 
well as negotiating codecs, we should not use it to negotiate what 
streams and tracks to use. It should only be used to set up the streams 
and tracks over the networks that is decided by the application.

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.

Stefan

>
> Alice web application received a SDP answer which was consumed
> successfully by the RTCPeerConnection. Alice thinks she is sharing her
> video, but she is not.
>
> The application "Video" button is disabled since the video is already
> being shared (theoretically)
>
> The application "self-Video" HTML5 video element displays Alice's face.
> She thinks that Bob is seeing her face too, but he did indeed rejected so.
>
> I hope this common scenario can be achieved somehow with the current
> API. I can't find how to do it though.
>
> Thanks in advance
>
> --
> José Luis Millán