W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: [SPAM] RE: VS: Teleco Integrators vs Web Developers vs Browser Implementers

From: Roman Shpount <roman@telurix.com>
Date: Fri, 5 Jul 2013 19:46:55 -0400
Message-ID: <CAD5OKxvdv9=1JPatx1xUSbz+bKahwxxBbE9uai815_ZSNi1R2w@mail.gmail.com>
To: "piranna@gmail.com" <piranna@gmail.com>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Eric Rescorla <ekr@rtfm.com>, Tim Panton <thp@westhawk.co.uk>, Robin Raymond <robin@hookflash.com>, cowwoc <cowwoc@bbs.darktech.org>, "public-webrtc_w3.org" <public-webrtc@w3.org>, Christer Holmberg <christer.holmberg@ericsson.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, Iņaki Baz Castillo <ibc@aliax.net>, Ted Hardie <ted.ietf@gmail.com>, Parthasarathi R <partha@parthasarathi.co.in>, Martin Thomson <martin.thomson@gmail.com>, Martin Steinmann <martin@ezuce.com>
I see some very confused people on this list who get befuddled by
unfamiliar terms.

SDP is irrelevant. People asking for new API (me included) as well as
existing API authors (at least Cullen) are saying that SDP should not be
used to control WebRTC. Everything should be controlled via constraints. I
do not disagree. My point is, if we have constraints to control everything,
and we add ability to see what constraints are supported, and the current
values of constraints, why do we need SDP? If everything is exposed, why do
we need this blob? Why not remove this and get rid of extra standardization
burden and extra dependencies on other standard groups?

I think there is a consensus that RTP (DTLS-SRTP and potentially SDES-SRTP)
will be used for media. There is no reason to change this now. Changing it
will not make API simpler. RTP is fairly light weight and well suited for
real time media. Something better can be invented in the future but RTP
will work great for now.

Bigger issue is offer/answer. It is a really awkward API. No SIP phone or
other SIP device implements all of its functionality internally via offer
answer. Offer/answer is exposed to the network, but user interface works
through a separate API. With WebRTC we created something unique where local
interactions with the device needs to go through something which is a
network API. And this does not take into account that offer/answer has
multiple different variations on how it can be implemented and still be
compliant. Or the fact that other negotiation schemes exist which are not
offer/answer. Or that offer/answer was a dirty hack to begin with to adapt
multicast session announcements to peer connection negotiation.
Offer/answer tends to combine multiple unrelated things (transport
parameters and media parameters) into a single negotiation unit. It
introduces state machine makes things asynchronous when they should not
have to. Bottom line, we took something which was barely working and used
for a purposes it was not intended to being with. Fixing this will not make
things more complex or produce more complicated applications then current
API.  Hopefully it will clean up the confusion and provides a better path
to new features such as bundle.
Roman Shpount
Received on Friday, 5 July 2013 23:47:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC