Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

Peter Dunkley <peter.dunkley@crocodilertc.net> Sun, 16 February 2014 21:17 UTC

Return-Path: <peter.dunkley@crocodilertc.net>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EFF1A02D3 for <dispatch@ietfa.amsl.com>; Sun, 16 Feb 2014 13:17:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvaRLSlpE1yQ for <dispatch@ietfa.amsl.com>; Sun, 16 Feb 2014 13:17:37 -0800 (PST)
Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A2E781A02C1 for <dispatch@ietf.org>; Sun, 16 Feb 2014 13:17:37 -0800 (PST)
Received: by mail-vc0-f180.google.com with SMTP id ks9so10668318vcb.25 for <dispatch@ietf.org>; Sun, 16 Feb 2014 13:17:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HXrpONcsVGaBk8/ndk0ivqfH53HmAh+TVqBvqeue5ws=; b=NIQOT113fLURnHR8JaUULbAfsp22+4BQKDCVL2mC3C0juXiNEFJv1vszteOsyHdshy 8AZpaWVKPRW+X6LhxX5ZpmoPimMsEE6Bw/9dj704WY/s2NnSYtqIna8McNwS7rhp/2Re /wEhp3Jhy0iBWayhkfOb2UdY0h2IsCeR/PNKA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HXrpONcsVGaBk8/ndk0ivqfH53HmAh+TVqBvqeue5ws=; b=c/i1lk3e0JfGFJF9QDipepD7wyI2EyImWIt6BskFI8lSH2zM5NeFHGA3wqUf1LYh2C h1RasNHuR3ILI05cV1B2TbCHbhRqrEN2+QKv2CnrHCK0r6b/RCOgBOiaxDMQgA+91TSq 3Cy7PKg8WYIWv2ZnIGZ8aKi9TuZ4161LTV6wtffpGJHC6wtSVa4pcJytGa5he6ZFsePM mlCJ9EXCUgK62Q0UHdSmB21yaF3i/M+Kl/h5UMzI6Ujxs0OlXhjU+jgiSpBCZZzR8hFP 0YQnBjb3NCw+4HfY8xB8wpbnp7zX7A3PmI680o47wznpb4HeiuLXPCcf+PxtX6fVGRB4 W3mg==
X-Gm-Message-State: ALoCoQn8OFNXPmkG8b6/qePAmF48j4EbR0F1LTIDtD98E3DIlXB/PbfFD9ybuDOcnlK3oL6nAUhG
MIME-Version: 1.0
X-Received: by 10.220.247.68 with SMTP id mb4mr626046vcb.37.1392585455121; Sun, 16 Feb 2014 13:17:35 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Sun, 16 Feb 2014 13:17:34 -0800 (PST)
In-Reply-To: <E0DBCEC4-5380-4899-B837-8121DA368854@iii.ca>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <CAHBDyN4tSRO_nYy7_-V4xfmDbF0ZeLJ24_fEOQ1p9Z2BvJyinQ@mail.gmail.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <CAHBDyN7hySvbiJYnvRXDQ2ZS_FYFDMaODXBDRarE6DhRwC=fHQ@mail.gmail.com> <CA+ag07bPBHzODTWGKFrKE00nO_wiMgRv2GEwUpGCiH25-Xf2Cw@mail.gmail.com> <CAEqTk6Reb=29kxeOUyPxAnhkRGqORHRoUchz5=hE4UNMggDnag@mail.gmail.com> <52FD36A3.1020606@gmail.com> <CAEqTk6R1bEG2=fr70zLXLC2MxC11b7ekHqZP4S8L_0s+v83DDw@mail.gmail.com> <E0DBCEC4-5380-4899-B837-8121DA368854@iii.ca>
Date: Sun, 16 Feb 2014 21:17:34 +0000
Message-ID: <CAEqTk6SuyC=q66p5_Z+26mP-Sq9NLnN9=8=J8Di85fGN7LvsYQ@mail.gmail.com>
From: Peter Dunkley <peter.dunkley@crocodilertc.net>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: multipart/alternative; boundary=089e0122aa5c5f4d7704f28c9158
Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/UoNwUTMzP_-fayc18w0mJj38hiY
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Feb 2014 21:17:39 -0000

I suppose you could have each peer implementing both the WebSocket client
and server so that they can both send and handle WebSocket handshakes, but
this isn't going to work particularly well when there are NAT devices in
between.  It certainly won't work for peers that are implemented using
Javascript and run in-browser at the moment as the browsers (as far as I
know) only implement the WebSocket client.

An MSRP relay that is a WebSocket can be used for NAT traversal (in the
same way that an ordinary MSRP relay can be) and that is the focus of this
draft.  In the 3GPP world MSRP is B2B'd through an SBC like device and in
that case the peer (which is not a client) could be a WebSocket server -
this is something that Christer may be providing language for in the draft.

Regards,

Peter


On 14 February 2014 21:42, Cullen Jennings <fluffy@iii.ca> wrote:

>
> On Feb 14, 2014, at 8:24 AM, Peter Dunkley <peter.dunkley@crocodilertc.net>
> wrote:
>
> > Because WebSockets is an asynchronous protocol two MSRP peers (that are
> clients) cannot use MSRP over WebSockets.
>
> Just sort of curios, why can't this work?
>
>
>


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd