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

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sat, 6 Aug 2011 18:49:11 +0530

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.
 
Thanks
Partha

---

From: Sohel Khan <[email-masked]>
Date: Sat, 6 Aug 2011 09:15:00 -0700 (PDT)

This can be one of the architectures/use cases.
Note that it will be nice to have different architectures/use cases to incubate innovation.
 
Regards,
Sohel Khan

________________________________
From: Parthasarathi R (partr) <[email-masked]>
To: [email-masked]
Sent: Saturday, August 6, 2011 9:19 AM
Subject: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver

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:

(Javascript)
             
|

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.
 
Thanks
Partha
           
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Matthew Kaufman <[email-masked]>
Date: Sat, 06 Aug 2011 09:36:28 -0700

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 
> I'm not very sure whether this usecase is same as sec 4.3.1 as there 
> is no protocol architecture shown:

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 7 Aug 2011 00:19:50 +0200

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: [email-masked] [[email-masked]] On Behalf Of Matthew Kaufman [[email-masked]]
Sent: Saturday, August 06, 2011 7:36 PM
To: Parthasarathi R (partr)
Cc: [email-masked]
Subject: Re: [rtcweb] Usecase & architecture: Browser application with separate webserver & voipserver

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:

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

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 8 Aug 2011 08:16:10 +0530

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:[email-masked]] 
> Sent: Sunday, August 07, 2011 3:50 AM
> To: Matthew Kaufman; Parthasarathi R (partr)
> Cc: [email-masked]
> 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.
> 
> From: [email-masked] [[email-masked]] On 
> Behalf Of Matthew Kaufman [[email-masked]]
> Subject: Re: [rtcweb] Usecase & architecture: Browser 
> application with separate webserver & voipserver
> 
> 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:
> 
> 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 
> 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
>