- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 5 Jul 2013 16:02:35 -0700
- To: "piranna@gmail.com" <piranna@gmail.com>
- Cc: Emil Ivov <emcho@jitsi.org>, cowwoc <cowwoc@bbs.darktech.org>, Martin Steinmann <martin@ezuce.com>, tim panton <thp@westhawk.co.uk>, Yana Stamcheva <yana@jitsi.org>, Parthasarathi R <partha@parthasarathi.co.in>, Christer Holmberg <christer.holmberg@ericsson.com>, Iñaki Baz Castillo <ibc@aliax.net>, Robin Raymond <robin@hookflash.com>, Roman Shpount <roman@telurix.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, Ted Hardie <ted.ietf@gmail.com>, "public-webrtc_w3.org" <public-webrtc@w3.org>, Eric Rescorla <ekr@rtfm.com>
On 5 July 2013 15:42, piranna@gmail.com <piranna@gmail.com> wrote:
> Ideally to me (maybe utopic?) I would only need to set an
> ID/token/IP:port/whatever on one end and a config object defining how
> I want the connection, and don't need to worry anymore, just get an
> event when my previous connection request have been done, or when a
> new one is being received, no more. I don't know if the ones that
> propose to remove Offer/Answer are talking about doing this way, but
> it's my interpretation about how would be the solution.
I believe that some people have APIs as simple as:
PseudoPhoneDevice.call("sip:someguy@some.domain");
If that sort of API is what you want, then that is entirely possible
as long as you are willing to provide server resources to make it
happen. I've seen several examples where this is the case.
In isolation, at any single browser, that is not going to be feasible.
It depends too heavily on the (non-standardized) capabilities of the
server. Not to mention a reliance on TURN means that browser
developers would have to put up TURN servers at significant expense.
So the API you get from a browser will, necessarily, require a little
more effort in order to build an application.
Received on Friday, 5 July 2013 23:03:03 UTC