Re: [rtcweb] New language (was: ... WebRTC JS Object API Model) (UNCLASSIFIED)

["Roy, Radhika R CIV USARMY (US)" <[e-mail]>]

Classification: UNCLASSIFIED
Caveats: NONE

Yes, the problems with capability negotiations with SDP had been well-known
for the folks when H.323 (H.245) and SIP (SDP) were debated and when SIP RFC
3261 was created. Later on, SDP O/A RFC was created to help SDP to have some
negotiation capabilities. 

Again, SDP could not provide any mechanisms for setting up of the multipoint
conferencing call dynamically where media bridging is needed evolving from
the two party point-to-point call that does not need any media bridging.

Later on, it was felt impossible to modify SDP for multipoint conference
call dynamically. So, it was decided that let us define a conference focus
that is the central point is well known a priori to all and people will dial
to that conference focus to set up the centralized multipoint conference
call statically only in a star-like configuration. That is, we gave up the
setup of the distributed conference call with sa mesh like configuration
dynamically because of limitations of SDP signaling architecture.

Now, if we keep the option that makes the WebRTC API is not 'hardwired' to
SDP as the ONLY one as mandatory for media signaling protocol for media
negotiations, then it will open up a huge innovative opportunities for all
of us in the future to have much more richer multimedia conference
capabilities.

So, let us keep SDP as one of the many alternatives for negotiations for
signaling of media capabilities (as opposed to ONLY one as mandatory that
stops all future innovations knowing SDP's all those limitations - we cannot
block our future innovativeness for real-time multipoint multimedia
communications - future of real-time multimedia communications are yet to be
imagined through creativity of the future generations).

Best regards,
Radhika


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Martin Thomson
Sent: Monday, July 01, 2013 2:58 PM
To: Ted Hardie
Cc: [e-mail]
Subject: [rtcweb] New language (was: ... WebRTC JS Object API Model)

On 1 July 2013 11:17, Ted Hardie <[e-mail]> wrote:
> Honestly, I have read it and I don't see how you avoid mandating some 
> standard interface between the JS and browser.  That needn't be SDP, 
> but if it is causing the two sides to negotiate candidate transports 
> and emit RTP, it's going to be hard going to avoid it being SDPNG.

This is an important argument, but it's only correct up to a point.
And that is misleading.

SDP does a lot of things that an API can do in far simpler ways.  Take
BUNDLE, or the plan A/B/No question.  We all know what these need to do, but
we are encumbered by existing SDP - which is no single thing - in trying to
reach a conclusion.

Interconnectedness makes SDP hard.  Harder than it needs to be.  The main
advantages of a new form of expression come from its ability to isolate
problems. For instance, separating transport establishment was clearly a big
win for Jingle in terms of flexibility, simplicity, capabilities.

But those examples speak directly to your point.  A new "language"
might be unencumbered in a way that might make addressing these problems
easier, it might even be more capable, but it is still just a new way of
saying the same old thing.

Offer/answer is the problem.  It's a contrivance that can be chosen or
rejected depending on how you plan to interact with the API.  That embeds a
negotiation engine into the browser, along with all the machinery for how to
negotiate everything that SDP expresses.

Negotiation is an extra, a feature that the IETF decided to add to the API
to make it "easier to use".  That wouldn't be a problem if it weren't
mandatory, but it's the only way to do anything.  (In contrast, CU-RTC-Web
provides a negotiation feature, but it's an optional extra.)

So SDP truly becomes a problem when coupled to offer/answer.  The way that
features interact become a problem for standardization, not because they
interact with each other - interaction problems are what engineers are for -
but because they are negotiated.

And it's not the SDP negotiation that is the worst: it's the negotiation of
what it means.  We all know what it means, but I'm certain no two people
"know" SDP the same way.  That means another sort of negotiation.  And those
negotiations require that those engineers be sent to places like the IETF to
argue endlessly, or play at politics.

--Martin
_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb



Classification: UNCLASSIFIED
Caveats: NONE