- From: Cullen Jennings <fluffy@iii.ca>
- Date: Thu, 25 Jul 2013 12:02:55 -0600
- To: Iņaki Baz Castillo <ibc@aliax.net>
- Cc: public-webrtc@w3.org
On Jul 20, 2013, at 8:12 AM, Iņaki Baz Castillo <ibc@aliax.net> wrote: > 2013/7/20 Iņaki Baz Castillo <ibc@aliax.net>: >> 2013/7/20 Cullen Jennings <fluffy@iii.ca>: >>> It's not true when a browser from one vendor running an application from a scone vendor needs to talk to video conferencing system from a third vendor. >> >> In the WWW, the servide provider provides both the server side (in >> this case the Web and the video conference server) and the client side >> (the JS). Your concern is good for a SIP phone but not for a browser >> nor for a JS custom application controlled and designed by the >> provider. > > Cullen, could you please give your opinion about what I've said above? > I also would like to know what happens if the video conference server > uses Jingle or any future RTC protocol (which uses RTP but no SDP for > media sig). > > Thanks a lot. I understand what you are saying might be right for your use cases but I think there is a big group of developers that have a different need. Several of the companies with WebRTC products today are doing things like building gateways to say a call center. The JS and web app would be developed by one company to display an advertisement on a web page and brand the user experience the way the web page want while at the same time the gateway would be a developed by a separate company and just purchased. There is a bunch of gateways like this from various vendors being shown at trade shows already and they are working fine with firefox and chrome. Very few service providers also manufacture video conferring servers. So if you consider a video conferencing service, they are probably getting the video MCU from a different place than who developed the web service.
Received on Thursday, 25 July 2013 18:03:20 UTC