Re: Telephony API draft

OK, this whole conversation is future talk, not about the current spec, but
if we got into it, I answer.

On Wed, Oct 24, 2012 at 5:39 PM, Mounir Lamouri <mounir@lamouri.fr> wrote:

> On 10/24/2012 02:27 PM, Göran Eriksson wrote:
> > Hi
> >
> > Perhaps a stupid question but may I ask about the assumptions around the
> implementation of the API: do You assume it to be directly tied to the
> telephony stack on the modem- be that a CS Telephony stack or an IMS based-
> or will there be a layer beneath allowing the user/ developer to pick
> underlying provider, similar to the approach in some Android API's?
>
> In my opinion, this API should only take care of the hardware telephony
> stack.


At the current version of the proposal, this is happening indeed, that's
what we agreed.

However, the question is very relevant, since we are not in the 90's any
more and IMS, RCS, VoLTE do raise issues. Our focus in this API development
is all kinds of dialers that may add value compared to the basic ones. So
they will need exactly these sort of features the question was about.

You probably know that e.g. VoLTE is SIP with (often proprietary) 3GPP
extensions working together with CS telephony, and it's knocking on the
door. We need to cover at least the domain selection use case. With RCS
there will be other inter-domain use cases.

I would like to have an API which can handle these, especially if it
doesn't take many changes.
But that is future development anyway.


> Open protocols like XMPP or SIP or closed ones like Google Voice
> or Skype can be implemented without a full API on top.


Of course we can, and will have dedicated VoIP APIs. I am pretty sure there
will be JS bindings to Skype and others, even for full frameworks like
Telepathy, which can handle both CS and VoIP too. We could also have JS
bindings to full CS telephony middleware like oFono.
However, in any case we will need a standard API to control calls and
manage policy between the VoIP calls and CS calls, and middleware for
handling audio and video policy. All these calls can have specific
properties characteristic to their kind, but the common things could be
managed by the API we are working on.

Note that the Telephony API is not a full API either, not even for the CS
telephony stack. The subset what we define for telephony is also enough for
controlling VoIP calls, and to implement local policies like "should
incoming CS calls put on hold SIP calls" etc. There are also enterprise
VoIP networks with handover from CS calls when you enter the enterprise
zone. All these use cases would be easy to cover by a minimal extension of
the current Telephony API.
I understand the wish to not overengineer the API, if we can get a lot of
use cases covered for minimal change, and it would still continue to work
in a simple way with the old use cases.

Besides, we are not targeting generic app or game developers, but ones who
will write dialers (including operators), so they will know about
telephony... This is a system API, so let us design it with keeping that in
mind.


> If we allow the
> Web Platform to create and use TCP/UDP raw sockets, there is no reasons
> why a Javascript library couldn't implement a wrapper around SIP and
> XMPP.


And that will or could look much like the Telephony API. There are some
protocol state differences, and connectivity/service setup differences, but
we use UI interaction states for calls in the current API rather than
protocol states, and the API focuses on controlling the calls, not on
service initialization.

I have worked with all these protocols, and also on products that manage
all of the above using the same API for the common things. In my experience
this approach is clearly simpler and covers use cases and corner cases
better.

I agree there will be products which won't care about this level of
integration at their targeted use cases. But the API should be designed so
that it does not decide this instead of its users.

Anyway, let the code speak: we will see how much we can get for what
changes in the specifications.


> Requesting this to be in the Web Platform just increase to cost
> for any new comer to comply with the Web Standards and will uselessly
> bloat it.
>
>
Not at all bloat it, and not uselessly: this is rude generalization without
knowing the proposal. For platforms which don't support e.g. VoIP, will
just support CS telephony, and they need to implement minimal extra
functionality for telling which telephony services they support (may be
just one).

I propose that we move on with approving the current version of the
Telephony API, and wait with this discussion until you see the proposed
changes.

Regards,
Zoltan