Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling

Iñaki Baz Castillo <ibc@aliax.net> Mon, 17 October 2011 23:45 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7227A21F8509 for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 16:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.302
X-Spam-Level:
X-Spam-Status: No, score=-3.302 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHPSKOo1+1cs for <rtcweb@ietfa.amsl.com>; Mon, 17 Oct 2011 16:45:53 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2B0F21F8505 for <rtcweb@ietf.org>; Mon, 17 Oct 2011 16:45:53 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so23498vcb.31 for <rtcweb@ietf.org>; Mon, 17 Oct 2011 16:45:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.73.166 with SMTP id m6mr26955vdv.18.1318895153038; Mon, 17 Oct 2011 16:45:53 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Mon, 17 Oct 2011 16:45:52 -0700 (PDT)
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159959@sonusinmail02.sonusnet.com>
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <2E239D6FCD033C4BAF15F386A979BF51159957@sonusinmail02.sonusnet.com> <CALiegfnGfpWooceicAbLQ35oVDUZC6+d=903qSKkxW952i-8pw@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF51159959@sonusinmail02.sonusnet.com>
Date: Tue, 18 Oct 2011 01:45:52 +0200
Message-ID: <CALiegf=eyfOt9ekHkGHKJjdeaEkkTt-dFg5vpPfpcg81SYd=tA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Oct 2011 23:45:54 -0000

2011/10/18 Ravindran Parthasarathi <pravindran@sonusnet.com>;:
> Inaki,
>
> Heaven sake, Please reply with original text. You always cut the text in reply so badly that I have to repeat what I have said in the original mail again in the reply. Your cutting practice leads to circular discussion and let us try to avoid it.

Mail threads exist to avoid reading again an entire previous mail. I
cut the exact text for which I'm replying my mail, this is the correct
behavior.

In the same way you could use a nice mail client so you would get the
previous text beggining with ">" (and you don't need to add your
strange <snip> </snip> symbols). Just as a suggestion.


> Original mail statement is as follows:
> <snip>
> I'm seeing your proposal as SDP offer/answer over websocket
> </snip>
>
> Hope this clarify what I meant.

No. SDP ofer/answer over WebSocket is NOT enough. How do you tell the
server/proxy *who* you want to call or where your SDP invitation must
be sent? For that you need something else, something more than just a
SDP exchange, right?

So you also need a *signaling protocol*, and that can be SIP (SIP over
WebSocket is signaling + SDP exchange), or XMPP+Jingle, or any custom
JSON based signaling protocol. I don't want to mandate a specific
signaling protocol, but you do.

What you propose in *every* your mails is that such signaling protocol
(which defines the format of messages sent on-the-wire) MUST be a
RTCweb standard built-in every webv browser. And that has nothing to
do with the ROAP draft which just defines a message exchange between
the JavaScript client (the "overkill" as you said in other mail) and
the RTCweb stack within the browser for handling *media* sessions.


> Also, Please see bullet 2 in sec 6 of draft-partha-rtcweb-signaling-00 to get the whole picture.

----------------------------
6.  Possible RTCWeb signaling protocols

   The following Signaling protocols will qualify for becoming standard
   RTCWeb signaling protocol

   2.  Websocket with SDP offer/answer
-----------------------------

Do I need to explain again that WebSocket is not a signaling protocol
by itself so you need to define a WebSocket subprotocol on top of it?
Do you understand that sending a SDP to the remote peer is not enough?
Probably you want to tell the remote peer "who you are".

In the other side, I don't care whether your proposed "default
signaling protocol for RTCweb" is based on WebSocket or whatever. That
does not make me happy. Nobody else seems to be in favour of defining
and *mandating* a default signaling protocol. Just you.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>;