Re: [rtcweb] Making progress on the signaling discussion (NB: Action items enclosed!)

[Roman Shpount <[e-mail]>]

As far as I can see from this discussion there are several different items
for consensus:

1. The API level: I think most of the people on the list agree that API
should deal with media streams and media stream descriptions, i.e. should be
as low level as possible without implementing actual RTP. There are few
people here who argue for a higher level API that would allow to setup
connection using some sort of higher level signalling protocol which will
deal with individual stream setup in a manner transparent to a developer,
but from what a lot of people on the list (including me) believe this can be
implemented in JavaScript and does not need to be standardized.

2. API Semantics: I would say that API should be complete enough to
implement everything that is currently supported by Offer/Answer and SIP
signalling. It does not have to be offer/answer and can allow for new
negotiation scenarios, but all the current scenarios, including forking,
remote target SDP updates should be supported. I think RTC should provide a
framework that would allow to implement all the current VoIP offer/answer
negotiation flows. I don't think that we can ignore some of those flows even
though some of the people on the list argue against it saying that this
flows are specific for PSTN, or caused by SIP design flaw, or some other
corner case of exiting offer/answer model.

3. Signaling Offer and Answer Format: Some people argue for direct use of
SDP. Others argue for using JavaScript object or set of API methods to
define the same. The main argument for using JavaScipt object/API methods
would be that it will make it easier to manipulate session description from
JavaScript. The main argument for using SDP is simpler interoperability with
existing VoIP solutions. I would strongly argue for JavaScipt object/API
primarily based on the fact that SDP is not enough to fully define the media
parameters. Typically all the non-negotiated media stream parameters in VoIP
solutions are defined from device configuration. We will need an API convey
those preferences to RTC implementation which means a set of custom APIs on
top of SDP. If we are doing custom APIs for media, we might as well make one
that covers all the features.

This being said, I would also argue that we need to have an API that can be
used with new codecs implemented by the browser without explicitly extending
the JavaScript signaling code. The current proposed API assumes that
JavaScript code understands the meaning of all the codec parameters to
negotiate them on behalf of the user. If new codec is added, JavaScript
would need to be updated to correctly select the parameters for new codec.
We should provide a programming model where it is possible to delegate the
codec selection and codec parameter negotiation to the RTC API while still
allowing to do this negotiation from JavaScript.

P.S. I do find the current API proposal a bit deficient due to its inability
to support forking, asymmetric codec selection, and delegating codec
negotiation to the RTC implementation.
_____________
Roman Shpount