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

[Matthew Kaufman <[e-mail]>]

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