From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Cullen Jennings <fluffy@cisco.com>
Thread-Topic: [rtcweb] My Opinion: Why I think a negotiating protocol is	a
 Good Thing
Thread-Index: AQHMjtZB6kdbKMH90Eeuh1H9I7A1XA==
Date: Thu, 20 Oct 2011 03:13:35 +0000
Message-ID: <B6990248-74BB-4421-8EEB-A99D3432B854@acmepacket.com>
References: <4E9D667A.2040703@alvestrand.no>
 <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com>
 <B5F4C6D1-3F54-4242-A89C-C2FC66AF8E7D@cisco.com>
 <570BDE5E-6EDC-4094-8DC0-094CEC3F12DF@acmepacket.com>
 <E44893DD4E290745BB608EB23FDDB7620DE659@008-AM1MPN1-043.mgdnok.nokia.com>
 <773FB266-721F-4C51-81A6-C01778BB68DF@cisco.com>
In-Reply-To: <773FB266-721F-4C51-81A6-C01778BB68DF@cisco.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28F41E960CC7374F8FE665CF1A94AAC1@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is	a	Good
 Thing
Precedence: list

[breaking your email up into chunks, 'cause my response is getting long]

On Oct 19, 2011, at 8:46 PM, Cullen Jennings wrote:

> I agree SDP is not used as an RTP API. I looked at a few RTP API and they=
 looked like "here is your compressed media and it's time stamp" and "send =
this compressed media with following time stamp to this IP, port. I don' th=
ink any one want that to be the level of API that gets exposed by the brows=
er. For one thing, the performance issues would likely not work.=20

Yeah when I said it I was kinda thinking "well not really 'RTP' library, be=
cause many of those are basically pseudo-sockets", but I was thinking like =
a media library (libraries that tie the codecs and RTP and SRTP and ICE lay=
ers together and provide an API to an app above).


> One question that comes up is when a browser adds support for a new CODEC=
, should the Java script code of a given web sight need to change to take a=
dvantage of it. If your answer to that is at least in some cases, No, then =
it means you need an API that allows the browser to do the negotiation of t=
he codecs.

I don't think you do.  At least for most "codecs", all a Browser needs to g=
ive/be-given is all the a=3Drtmp and a=3Dfmtp lines, or maybe even only the=
 portions after the PT numbers, as a list/table of strings and their payloa=
d-type numbers, per audio/video stream.  I know there are some other codec-=
specific attributes now and then (T.38 comes to mind, but it was arguably n=
ot your typical "codec" anyway)... but in general wouldn't rtpmap+fmtp cont=
ents do it?

There are a lot of other attributes, of course, but not per new codec.  Rig=
ht?


> Today SDP (and the mapping of it in Jingle), are pretty much the only gam=
es in town for that sort of negotiation. You can argue if we should use SDP=
 or invent something new. I'd love to hear your opinion on that. If we deci=
de we are going to use SDP, I think you end up with a API at roughly the le=
vel of what is the W3C WEBRTC draft today and something around the level of=
 protocol as described in ROAP.=20

Let's assume we have to use SDP - I don't actually think we do, but just fo=
r argument's sake.  That still doesn't mean we have to embed the offer/answ=
er model in the Browser, or even use it anywhere at all for pure web-apps. =
 The offer/answer model has some very specific semantics, which are actuall=
y restrictive.  For example, the offer/answer model assumes a symmetric med=
ia-line model: if you send one audio and one video m-line, the answer can o=
nly have one audio and one video m-line.

As an example of something that cannot be accomplished because of this: ima=
gine a Web-application which allows the Browser to communicate with a TeleP=
resence (TP) system.  TP systems have multiple cameras, screen displays, mi=
crophones, and speakers.  A PC-based Browser typically only has a single mi=
crophone and camera, but can display multiple video feeds separately and ca=
n render-mix the incoming audio streams.  Thus, a Browser to TP system woul=
d 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 indep=
endent m-line RTP session and has unique attributes to indicate position (l=
eft/center/right), which a Browser could in theory display on the left/cent=
er/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-line=
s (m=3D lines).  Clearly if and when SDP is changed to handle TelePresence =
cases, Browsers could be subsequently upgraded to handle it as well sometim=
e after; but they wouldn't need to if the Browser hadn't been involved in S=
DP and offer/answer to begin with.

The offer/answer model is an ok protocol between VoIP systems, but it's not=
 a good *API* between an application and its library.=20

-hadriel