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

[Christer Holmberg <[e-mail]>]

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