RE: TPAC f2f: start building agenda

> From: Harald Alvestrand [mailto:harald@alvestrand.no] 
>
> Since this meeting is of the WEBRTC WG, I think the main thing we want to say is what functions we want the SDP negotiation to accomplish, and how
> we think SDP requirements for negotiation get reflected at the API level.
>
> The fact that we've got a large overlap of participation with RTCWEB means that we should at least be able to have an informed discussion of this
> topic, but the actual SDP syntax and semantics issues need to be dealt with in the IETF, I think.


That's certainly one opinion, but this is exactly the "meta issue" that is "the open SDP issue". With the decision to continue to pursue a JSEP-based approach rather than an API that offers direct manipulation of the relevant objects (http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html), the working group has committed itself to defining a web browser JavaScript API that manipulates the objects and system state by passing strings that the spec calls "SDP".

It is unrealistic to expect that browser vendors will in fact correctly implement every possible variation on what "SDP" could mean. As an example, the current Google Chrome beta, which "supports the PeerConnection API" (http://blog.chromium.org/2012/10/supporting-new-media-experiences-on-web.html), appears to suffer from severe indigestion when perfectly formed SDP that includes an "e=" line is passed as either a revised offer or an answer to setLocalDescription.

But on a more realistic note, there will be even more subtle restrictions on what is and is not allowed to be passed as an "SDP" string to the setLocalDescription and setRemoteDescription APIs. This calls for a W3C specification (or reference) as to *exactly* what is and is not allowed, *and* a W3C specification as to how errors will be handled and reported. Is disallowed content in the "SDP" string to be ignored? Should it fire a "Syntax Error on Line 6" event? Should "silent ignore" vs "require correctness" be an optional flag?  Similar questions arise for what a browser implementor should return for createOffer and createAnswer.

Nearly all of the above are API issues, not wire protocol issues, and so *even if* the document describing the restricted subset of "SDP" that is to be allowed becomes an action for the IETF WG, there are unresolved open issues for W3C. And since the "SDP" is an API surface, and not a wire protocol, it is not clear to me that even that document belongs in the IETF WG as a deliverable.

We need time at the meeting to at least answer *where* these issues will be resolved. At the present time the specification is too incomplete to implement in an interoperable way from the specification alone, and neither working group has a milestone date set by which adequate clarification should be expected.

Matthew Kaufman

Received on Wednesday, 17 October 2012 21:38:41 UTC