Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver

Matthew Kaufman <matthew.kaufman@skype.net> Tue, 06 September 2011 03:36 UTC

Return-Path: <matthew.kaufman@skype.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 04E8C21F841A for <rtcweb@ietfa.amsl.com>; Mon, 5 Sep 2011 20:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.723
X-Spam-Level:
X-Spam-Status: No, score=-4.723 tagged_above=-999 required=5 tests=[AWL=1.875, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 q-zy4nBpsjBl for <rtcweb@ietfa.amsl.com>; Mon, 5 Sep 2011 20:36:30 -0700 (PDT)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9D59321F8443 for <rtcweb@ietf.org>; Mon, 5 Sep 2011 20:36:26 -0700 (PDT)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id B16177FC; Tue, 6 Sep 2011 05:38:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to: content-type; s=mx; bh=Zltpt0Yu3SRtnS5eLCtu0KG1vHo=; b=hCu4H0EJH wWpQxnOhrxPW3zO//D63GRZRBdmgOlqRVPziwGKnsIkTHmfUQFu/YNkcmqJwl1uE FQUGzT0c0w3XOGO3vz3roXTnLqrH0zG+IFxfkgj0JSSk1sgdMl+xPf9POzNmUs1Z hnpe0Xv8ZY+BzEx9TQdzlwpDA8rKAtcGsc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :mime-version:to:cc:subject:references:in-reply-to:content-type; q=dns; s=mx; b=EVOPKqneiPmbLvawFS63ukbm+dUU/hdpRR+uUYa+puMR61BX NhzKq0Bnub978j/jZ9XoZCVld6ZWOiUZwBlE+HABDoYIw5QeCpyyR4nKh4zOIZmm Fp2RN32osfFSY/XxnQk0BVHNvDusBq6j8oECOCBb35Zo5yyLdXD76aNmX9A=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id AF61C7F6; Tue, 6 Sep 2011 05:38:08 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 888C93507345; Tue, 6 Sep 2011 05:38:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ2LRSgNnohT; Tue, 6 Sep 2011 05:38:07 +0200 (CEST)
Received: from [10.10.155.2] (unknown [198.202.199.254]) by zimbra.skype.net (Postfix) with ESMTPSA id 7A0183507061; Tue, 6 Sep 2011 05:38:06 +0200 (CEST)
Message-ID: <4E659576.1000301@skype.net>
Date: Mon, 05 Sep 2011 20:37:26 -0700
From: Matthew Kaufman <matthew.kaufman@skype.net>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
References: <CAM_kxqci51=BnUFe-67Qs4eCxtGY50HDsRPrLjYULnBZJoH0Ow@mail.gmail.com>, <2E239D6FCD033C4BAF15F386A979BF5106436F@sonusinmail02.sonusnet.com> <BLU152-W72696F07F16816B1B267593100@phx.gbl> <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51064707@sonusinmail02.sonusnet.com>
Content-Type: multipart/alternative; boundary="------------040105050203060104060003"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver
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: Tue, 06 Sep 2011 03:36:41 -0000

On 9/5/2011 12:16 PM, Ravindran Parthasarathi wrote:
>
> Bernard,
>
> Sorry for the delay reply.
>
> There is a huge difference between tunneling the protocol and 
> converting the protocol from one format to another. The tunneling 
> works well only in case the destination support the tunneled data 
> without negotiation. It will be bad assumption in case the standard 
> does not defined so.  For example,
>
> 1)Browser A supports Jingle (XMPP for real-time data) and encapsulates 
> the data in HTTP and send it to webserver1
>

That isn't how it works. Browser A supports WebRTC. Do you mean browser 
A is running Javascript that implements Jingle or something similar for 
its signaling (over HTTP and/or Websockets) to its associated web server?

> 2)RTCwebserver1 tunnel jingle data in SIP and sends it to RTCwebserver2
>

Federation between webserver1 and webserver2 is up to the operators of 
those sites. Presumably SIP is a good (but not only) choice for 
federation. Many sites won't have a desire or need to federate.

> 3)RTCwebserver2 does not support Jingle towards browser but it support 
> some other variant of HTTP based metadata to the browser.
>

Do you mean that webserver2 and its clients are running compatible code 
that exchanges signaling via a mechanism other than Jingle? That's fine, 
and up to the operator of that site.

> My question is how webserver2 do perform the interop correctly in case 
> Jingle is not mandated as metadata standard mechanism. Please let me 
> know your opinion here.
>

Every site that wishes to federate with others will need to choose a 
signaling protocol that is agreed between them.

> My understanding was that RTCwebserver1 may use some proprietary 
> mechanism (may be jingle) to communicate between browser and webserver 
> which will be converted into RFC 3261 SIP at webserver1 and forwarded 
> to RTCwebserver2. RTCWebserver2 converts back SIP to its own 
> proprietary metadata to communicate with browser. This mechanism works 
> well but still better mechanism exists.
>

That understanding appears to be correct. This is exactly the same as 
"Hotmail talks some proprietary protocol over HTTP between its 
HTML/Javascript client and its servers which is then converted to SMTP 
for sending to Gmail, where Gmail talks a different proprietary protocol 
over HTTP between its HTML/Javascript client and its servers." It 
appears to have resulted in some significant innovations in the email 
service space, while still allowing federation between domains using a 
standard protocol.

If you think this is a bad idea, provide an alternative we might discuss.

Matthew Kaufman