From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Thread-Topic: [rtcweb] Current state of signaling discussion
Thread-Index: AQHMjdS59USwkyocF0KQH5G/+0/FIA==
Date: Tue, 18 Oct 2011 20:30:08 +0000
Message-ID: <E7E0C331-9943-444F-9D42-782DAD6A7FF3@acmepacket.com>
References: <4E9D773A.4010705@ericsson.com>
In-Reply-To: <4E9D773A.4010705@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <B015ADFC1420A84499AF2228CCD3C6B5@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Current state of signaling discussion
Precedence: list

Dear Chairs,
I have a question of clarification on your request for "signaling" proposal=
s/drafts.
Which *type* of "signaling" do you mean?  What purpose/problem-solution are=
 these candidate drafts meant to address?

In the email below, you indicate draft-jennings-rtcweb-signaling is one of =
the drafts that provides a solution, but as far as I can tell it is not a s=
ession signaling protocol; it is just a protocol for SDP offer/answer.  It =
is not a sufficient solution for sessions, and it admits that within its ow=
n text.  It would not, for example, let one write a RTCWeb-based communicat=
ion application in "20 lines of code".

So are you only talking about how to handle media-plane setup between two B=
rowsers? (ie codec negotiation, ICE, etc.)  OR do you mean the whole sheban=
g?

There have been a lot emails floating around the past few days so if I've m=
issed the relevant clarification please excuse the question. (but direct me=
 to the answer :)

-hadriel


On Oct 18, 2011, at 8:55 AM, Magnus Westerlund wrote:

> WG,
>=20
> 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.
>=20
> 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.
>=20
> a) RTCWeb Offer/Answer Protocol (ROAP)
> https://datatracker.ietf.org/doc/draft-jennings-rtcweb-signaling/
>=20
> b) RTCWeb standard signaling protocol
> https://datatracker.ietf.org/doc/draft-partha-rtcweb-signaling/
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> In addition to signaling proposals the WG have received two other I-Ds.
>=20
> 1) Real-Time Web Communication Simplified Interconnection
> https://datatracker.ietf.org/doc/draft-beck-rtcweb-alt-ic/
>=20
> Which I interpret as a discussion piece around the federation and
> interconnect usages.
>=20
> 2) WebSocket Transport for Session Initiation Protocol (SIP)
> https://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/
>=20
> 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.
>=20
> There has been lively discussion around these documents which I hope
> continues but it does need to come to some conclusions.
>=20
> Cheers
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> F=E4r=F6gatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>=20
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb