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

["Parthasarathi R (partr)" <[e-mail]>]

Matthew/Christer,

I asked this usecase for two reasons:

1) Whether any new authentication/security/privacy consideration has to
be taken into account in case separate server involved for real-time
traffic alone. The issues may be
 a) The single authentication will not work
 b) The same identity may not apply. 
I'm curious to know whether it will translate into new requirement in
browser or in API.

2) I understand that your proposal is to introduce new gateway (RTCWEB
to VoIP GW) for making the interop for every session even between two
RTCWeb servers /RTCWeb client to other existing VoIP clients. As your
proposal, I'm seeing IETF recommends two real-time protocol with
different solution for the same service depends upon application in the
system. For example, any solution developer has to consider the
following topology:

a) Desktop application interacts with VoIP server (use SIP)
        application <------->SIP server
b) Browser application interacts with VoIP server (use HTTP)
        browser<------>RTCweb server & SIP client (new GW)<------>SIP
server

New Gateway is outside the scope of RTCWeb and IETF which provides the
opportunity for innovative way of building gateways but may leads to
interop issue due to mapping between RTCWebserver & SIP client w.r.t
mid-call services. Also, I'm not seeing JavaScript API design as the
limiting factor for this choice. 

Could you please explain the strong reasons for browser *MUST NOT*
interop with any existing SIP entity or other VOIP entity directly.  	

Thanks
Partha

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]] 
> Sent: Sunday, August 07, 2011 3:50 AM
> To: Matthew Kaufman; Parthasarathi R (partr)
> Cc: [e-mail]
> Subject: RE: [rtcweb] Usecase & architecture: Browser 
> application with separate webserver & voipserver
> 
> Hi,
> 
> If I understand Matthew correctly, he is saing that, from the 
> browser's perspective, the VoIP server is acting as a web server.
> 
> I agree, and I don't see any new browser requirements derived 
> from that.
> 
> (There might be requirements on the VoIP server, but that is 
> outside the scope of RTCWEB).
> 
> Regards,
> 
> Christer
> 
> ________________________________
> From: [e-mail] [[e-mail]] On 
> Behalf Of Matthew Kaufman [[e-mail]]
> Sent: Saturday, August 06, 2011 7:36 PM
> To: Parthasarathi R (partr)
> Cc: [e-mail]
> Subject: Re: [rtcweb] Usecase & architecture: Browser 
> application with separate webserver & voipserver
> 
> On 8/6/2011 6:19 AM, Parthasarathi R (partr) wrote:
> Hi all,
> 
> browser application should have the mechanism by which it 
> interacts with voipserver directly instead of depend on the 
> webserver. This usecase provides the flexibility for the 
> webdeveloper to focus on the webdevelopment and use the 
> existing voipservers for voip services by just invoking the API.
> 
> I'm not very sure whether this usecase is same as sec 4.3.1 
> as there is no protocol architecture shown:
> 
>          browser--------webservers---web services
>          (Javascript)
>              |
>              ----------------voipservers-----VoIP entity (browser)
> 
> This architecture facilites for webdeveloper to choose the 
> different vendor for webservers & voipservers. It is possible 
> for webserver & voipserver co-located but not mandatory. This 
> architecture is slightly different from 
> draft-rosenberg-rtcweb-framework-00 fig 2 (Browser RTC 
> Trapezoid).  Please let me know your opinion on the same.
> 
> 
> My opinion is that as long as the "voipservers" use 
> HTTP-based signaling and RTCWEB-compatible VoIP, then that's 
> fine, and indistinguishable from other use cases. But if the 
> "voipservers" are existing SIP servers then no, I don't want 
> additional inflexible code in the browser that turns it into 
> a SIP phone.
> 
> Matthew Kaufman
>