Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing

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

On 10/20/2011 05:13 AM, Hadriel Kaplan wrote:
> As an example of something that cannot be accomplished because of
> this: imagine a Web-application which allows the Browser to
> communicate with a TelePresence (TP) system.  TP systems have
> multiple cameras, screen displays, microphones, and speakers.  A
> PC-based Browser typically only has a single microphone and camera,
> but can display multiple video feeds separately and can render-mix
> the incoming audio streams.  Thus, a Browser to TP system would
> produce an asymmetric media stream model: multiple video streams from
> the TP system to the Browser, and one video stream from the Browser
> to the TP system, and the same for audio.  Each TP audio and video
> stream is an independent m-line RTP session and has unique attributes
> to indicate position (left/center/right), which a Browser could in
> theory display on the left/center/right of your browser window.
> Doing that is currently not possible with SDP offer/answer; not only
> because the SDP attributes aren't yet defined, but because the
> offer/answer model assumes a symmetric number of media-lines (m=
> lines).  Clearly if and when SDP is changed to handle TelePresence
> cases, Browsers could be subsequently upgraded to handle it as well
> sometime after; but they wouldn't need to if the Browser hadn't been
> involved in SDP and offer/answer to begin with.
I think this is doable with the current toolbox. There is an API that 
treats outgoing and incoming MediaStreams (over the same PeerConnection) 
separately, so nothing stops having an asymmetric setup. In addition, 
you could have several PeerConnections if that would help.

Each incoming MediaStream has an unique label, so it is quite simple to 
associate the received MediaStream with the right display 
(left/center/rigth).

The role of the SDP o/a (or ROAP) is IMO only to enable that those 
MediaStreams are sent as RTP streams between peers and can be assembled 
correctly to MediaStreams at the receiving peer (typically a MediaStream 
consists of several RTP streams, e.g. audio+video).