Re: [rtcweb] Current state of signaling discussion

[Iñaki Baz Castillo <[e-mail]>]

2011/10/18 Magnus Westerlund <[e-mail]>:
> This is an attempt of me as WG chair to try to summarize the state of
> the discussion as it was when I wrote this. As usual please speak up
> against any miss-characterization of the state from my side.
>
> The Chairs request for identifying who like to provide input for a
> signaling discussion two weeks and to follow up this with a Internet
> draft has resulted in that we now have two drafts.
>
> a) RTCWeb Offer/Answer Protocol (ROAP)
> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-signaling/
>
> b) RTCWeb standard signaling protocol
> https://datatracker.ietf.org/doc/draft-partha-rtcweb-signaling/
>
> We also have a third proposal that want to be included in the
> considerations:
> c) RTCWEB does not define any signaling behavior at all, instead W3C is
> tasked to develop an API that allows the application to establish the
> media session between peers.
>
> I have as WG chair requested that the proponents for C to produce a
> Internet draft that provides requirements on the API and its capability.
> This is to ensure that this proposal can be properly evaluated. So far
> no such contribution has occurred. Without a willingness from the
> proponents of this style of solution to contribute and evolve their
> thinking in such way that the other WG members can gain a better
> understanding of the implications of this solution I find it difficult
> for us include it in the up coming consensus call.
>
> We intended to have a phone conference on Friday to enable some direct
> discussion on the topic of signaling between the WG members. Details to
> follow. This is not an interim, only a possibility for the WG members to
> further their understanding in preparation for the decision.
>
> In addition to signaling proposals the WG have received two other I-Ds.
>
> 1) Real-Time Web Communication Simplified Interconnection
> https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/
>
> Which I interpret as a discussion piece around the federation and
> interconnect usages.
>
> 2) WebSocket Transport for Session Initiation Protocol (SIP)
> https://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/
>
> This is a demonstration that SIP could be implemented in Java script and
> be transported over web-socket to enable the cases where SIP want to be
> used between a browser instance and a SIP system and its user agents.
> This has some requirements on the API to either provide SDP in O/A style
> or something that enables the SIP stack to create SIP messages with SDP
> O/A messages.
>
> There has been lively discussion around these documents which I hope
> continues but it does need to come to some conclusions.


Hi Magnus. My concerns:

- I don't like option B (defining a default signaling protocol) as it
stops innovation (we will be limited and constrained to the
limitations of such protocol, and will depend on how good each browser
implements it). Upgrading the signaling stack would require a new
version of every browsers in the world. Unfeasible IMHO.

- Initially I advocated for option C, but such option is so flexible
that I cannot imagine how a draft can describe it. But a real example
of such a custom signaling protocol is present in
https://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/.

- I don't think that options C and A (ROAP) are mutually exclusive,
not at all. IMHO ROAP defines a communication between the JS code and
the browser RTCweb stack, just it. It does not define a signaling
protocol on-the-wire (but just gives some guidelines which are present
in any existing VoIP protocol). For example a JS code could use SIP
over WebSocket for the wire communication and generate ROAP "objects"
upon receipt of a INVITE/200 with SDP prior to talk with the browser
RTCweb stack.

- ROAP defines itself as a "protocol" because indeed it contains
states, so it's not an API (or it's more than just an API), but it
just covers the communication between the JS code and the browser
RTCweb stack, leaving the door open to any custom signaling protocol
on the wire. So IMHO this is the way to go.



About SDP or media info management there is an open debate about the
responsability (or not) of the JS code in doing such task. My opinion
is that, given that RTCweb is based on SDP:

- RTCweb should define a specific (JSON) format that includes SDP
information in some structured way. It does not need to be a SDP 1:1
mapping. Let's call it RTCweb.MediaInfo JSON object.

- Since interoperability with SIP and XMPP/Jingle is desired (is
not?), RTCweb JS API should include some helper functions:

  - RTCweb.parsePlainSDP(string)
      Receives as argument a string containing a plain SDP body and returns a
      RTCweb.MediaInfo object.

  - RTCweb.parseXmlSDP(string)
      Receives as argument a string containing a XML SDP body (Jingle)
and returns a
      RTCweb.MediaInfo object.

  - RTCweb.generatePlainSDP(mediaInfo)
      Receives as argument a RTCweb.MediaInfo object and generates a
plain SDP string.

  - RTCweb.generateXmlSDP(mediaInfo)
      Receives as argument a RTCweb.MediaInfo object and generates a
XML SDP string.

- Custom signaling protocols not using SIP or XMPP would not need such
helpers and could directly work with the MediaInfo JSON structure (by
also passing it verbatim on-the-wire).


So my proposal is using ROAP but, instead of inserting a plain SDP
string within the ROAP Offer and Answer structures, inserting a
RTCweb.MediaInfo JSON object. In this way, there is no need for the
JavaScript code for dealing with plain SDP's.


Regards.



-- 
Iñaki Baz Castillo
<[e-mail]>