Re: [pntaw] New version of TURN over websockets draft

Oleg Moskalenko <mom040267@gmail.com> Fri, 20 September 2013 21:12 UTC

Return-Path: <mom040267@gmail.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5E121F9B28 for <pntaw@ietfa.amsl.com>; Fri, 20 Sep 2013 14:12:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 9r6ODunn8UO8 for <pntaw@ietfa.amsl.com>; Fri, 20 Sep 2013 14:12:21 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id E1C7A21F9A8C for <pntaw@ietf.org>; Fri, 20 Sep 2013 14:12:20 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id r10so854900pdi.0 for <pntaw@ietf.org>; Fri, 20 Sep 2013 14:12:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XwjZ2k6NYf2IxJ4BKwd9rYvbrjmQeL4yUu8/RsqIRos=; b=e+6mBPCKcPczYg9vDCTi/gBOt5/vlHYexp+hvT72xCQ/Dylq7pq+5pxo79thSCECBM 9VcCcaepQLvj0UdJxULQ8GbEvZcLmL6Rc3fpXbvJ4XWsFeu9OsoyPowJuay6JWRa1df8 CVyx/Saw/b2k8NsbpLRrqffR9WjOk8mHxOXFBNjpFM4aqs5hsK1+wwxHLzVdrKzlbhKD azT7fiFNXfOKBOqvWsf/EadjIuTheApBDS10ttxO+vceqgQS/43J8pOlGKTOLPMkGXSh CTEdO5GPaOzVa0DRJFGf4FWjBEW6Z5QWAstEhZaXHi55xOScmw1uGMFbxGmhj78nqoyH 2iTQ==
MIME-Version: 1.0
X-Received: by 10.68.9.3 with SMTP id v3mr10025624pba.84.1379711540544; Fri, 20 Sep 2013 14:12:20 -0700 (PDT)
Received: by 10.68.129.138 with HTTP; Fri, 20 Sep 2013 14:12:20 -0700 (PDT)
In-Reply-To: <523CB437.6000806@petit-huguenin.org>
References: <5232C18C.1030102@gmail.com> <523C8BDC.6050705@petit-huguenin.org> <CALDtMrKwygUqNWKcB81F+M7Y8wBmwZtTACeYChpJVvWKbXLTEw@mail.gmail.com> <523C9B03.2030002@petit-huguenin.org> <CALDtMrJBQQZP4bbkLh6OcZhmOGFrP5bAJ8BDr0AY1zKjPXChPw@mail.gmail.com> <523CAC92.2070102@petit-huguenin.org> <523CB114.20106@gmail.com> <523CB437.6000806@petit-huguenin.org>
Date: Fri, 20 Sep 2013 14:12:20 -0700
Message-ID: <CALDtMr+Fc3G-H--n7DuKPMzx-6fo_XweuYd=LxdjRp+tgB_3NQ@mail.gmail.com>
From: Oleg Moskalenko <mom040267@gmail.com>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
Content-Type: multipart/alternative; boundary=bcaec521623b444c2904e6d72065
X-Mailman-Approved-At: Fri, 20 Sep 2013 17:59:04 -0700
Cc: "pntaw@ietf.org" <pntaw@ietf.org>, Lorenzo Miniero <lorenzo@meetecho.com>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "Chenxin \(Xin\)" <hangzhou.chenxin@huawei.com>, Victor Pascual Avila <victor.pascual.avila@gmail.com>
Subject: Re: [pntaw] New version of TURN over websockets draft
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Sep 2013 21:12:22 -0000

RFC 6062 is not very important but I cannot say that it is not relevant.
For the purpose of the new proposal we do not make a distinction between
RFC 5766 and RFC 6062 - this new proposal is about a new TURN transport
(Websockets). This transport is supposed to work universally in all
accepted TURN RFCs. So it would be unnatural and illogical to remove RFC
6062 from the draft.




On Fri, Sep 20, 2013 at 1:46 PM, Marc Petit-Huguenin <
marc@petit-huguenin.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 09/20/2013 01:33 PM, Sergio Garcia Murillo wrote:
> > El 20/09/2013 22:14, Marc Petit-Huguenin escribió:
> >> On 09/20/2013 12:57 PM, Oleg Moskalenko wrote:
> >>> On Fri, Sep 20, 2013 at 11:59 AM, Marc Petit-Huguenin
> >>> <marc@petit-huguenin.org <mailto:marc@petit-huguenin.org>> wrote:
> >>>
> >>>
> >>> OK so I suggest to say in the draft that a new Websocket connection
> >>> will be created for each TCP peer, because that have an impact on
> >>> implementation design.
> >>>
> >>>
> >>> ... for RFC 6062 TURN TCP, of course. The key key words here are "TCP
> >>> peers" (as in RFC 6062, unlike "UDP peers" in RFC 5766). That may be
> >>> worth mentioning, indeed.
> >>>
> >>> This draft is mostly driven by the necessity of enhanced connectivity
> >>> of the clients (browsers) in WebRTC environment. So the question of
> >>> multiplicity of TCP / Websocket connections is not very important in
> >>> this context.
> >> If having TCP peers is not important, then remove RFC 6062 from this
> >> draft.
> >>
> >> Also, the draft does not explain the procedures related to SRV and NAPTR
> >> RRs:
> >>
> >> example.net. IN NAPTR 100 10 "" RELAY:turn.ws "" websocket.example.net.
> >>
> >> websocket.example.net. IN NAPTR 100 10 S RELAY:turn.ws ""
> >> _turn._ws.example.net.
> >>
> >> _turn._ws.example.net. IN SRV   0 0 80 a.example.net.
> >>
> >> a.example.net. IN A     192.0.2.1
> >>
> >>
> >
> > Hi Marc
> >
> > It was my error to keep the websocket support  for RFC 6062 in the draft
> > (against Oleg recommendations, by the way).  I agree with both of you
> that
> > it will be better to remove it from the draft, as it is causing most of
> > the discussions and will not provide anything to webrtc.
> >
> > Regarding the SRV and NAPTR RRs, for webrtc are not needed AFAIK, but we
> > could add it to the draft for completeness. Would you be willing to
> > collaborate in order to write that chapter?
>
> Sure, I'll send you a patch this week-end.
>
> >
> > Also, I would like to introduce in next draft version how HTTP
> > authentication/authorization (oAuth, cookies, etc) mechanisms could be
> used
> > in the TURN over websocekt connection on top of the standard TURN
> > authentication. That would remove the need for the current REST API fro
> > access to TURN services. If anyone would be willing to collaborate on
> this
> > (or any other subject) will be very welcome.
>
> I think that this is a very good idea to do that.  Not sure I'll have the
> time
> to help on the draft itself, but I certainly will try find the time to
> review it.
>
> - --
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org
> Blog: http://blog.marc.petit-huguenin.org
> Profile: http://www.linkedin.com/in/petithug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQIcBAEBCAAGBQJSPLQ0AAoJECnERZXWan7ExzgQALZo/mdZqeGH3IdRzIflKAa9
> TnpU7SF/L3hOdyizgw7ftpzG1FDHfXrS12APmBOAt7F7ec5Q7p4W2tscXebTeSO4
> uQ/gYb50ekbGkVOVWHwzPP7k3lMNe3FnNnycYO9JJc/qpF9XeBKNnCaVPKbjW74K
> dIX/i+YeCqjoY0E2YQNeCzq2uX18Ygeals6/C+XOyxO+31GQPWLcIXr3ME8LZnAS
> QwUmL3+6/17kDdfK0xhtXl4oB44rpDhUNAodaxr6FUY0SOvp5GqsKKxOESSA3ltn
> K6ZpWuRBVBuaPdaQDrNT0xbNHjiA6WKnyjKfd0/8F0xZe13Sd3WTR2r6S9+QWS44
> TM3y4er4P7ISc11p5HHMwN3xf7kxCwwRbU3lK7Rq0M5Nlw69QXA/D2HY1txioumW
> fBbtAVwhx9M88bj4/sqViV0LIDPo/h/OVrkYncD7aJgISSKApuZMAjYegC/iYufz
> C4M5dZRub6PHoljTSFAs72bGC+yyvStsJxnrYN8pPF33MHRfbNdBdLZOpJq0ynU/
> ku0arxu6LwNBedno/B77WvUPG/x2ilKDcfDgxHSwkm3e/sWggZgkR1E7R/cXyFNK
> cO172tJlQPGF68QRjj1y7ulQb60cAscn51LRo5iTH6Xd8LcGxun+jWa09opuBtNo
> eRxWcQ3hI897vUZUzWMO
> =KM9Z
> -----END PGP SIGNATURE-----
>