Re: Telephony API draft: disconnect reason

On Wed, Nov 7, 2012 at 1:36 AM, SULLIVAN, BRYAN L <bs3131@att.com> wrote:

>  I would suggest that since our individual and anecdotal experience with
> call control and related state machines will result in various descriptions
> that could take some time to bring to consensus,  that to shortcut the
> process:
>

While you are definitely right (experts who read this conversation may
scratch their heads about what is going on here), -- I think Jonas'
questions were logical, and I answered based on my experience and after
checking the docs I referenced earlier. Of course I checked the standards,
but I may be still wrong. I think a more useful shortcut would be that if
there was a wrong opinion, please correct it. If they were right, tell it.
If you have an expert opinion, please share it.

> **
>
> **1)      **For each type of call, we reference and leverage the
> applicable standards, e.g. for GSM the 3GPP Stage 2 spec family for "TS
> 23.018 Basic call handling; Technical realization" [1] and for IMS "TS
> 23.228 IP Multimedia Subsystem (IMS); Stage 2" [2]
>
****
>
> **2)      **While recognizing that what is possible in terms of PLMN call
> state knowledge by clients is bounded by standards, seek also practical
> advice from experts on call control who are familiar with the APIs that
> chipset manufacturers expose to OS platforms: these are the same APIs that
> Web-based device vendors will need to use, and will further limit what is
> exposable through the API
>
When it comes to supporting a variety of modems, this job has been done
pretty well by e.g. the oFono community, and I already suggested looking at
their API design and call states handling (for cellular telephony). The
proposed API provides a superset of that, except the differences I wanted
to cure.

> ****
>
> **3)      **For Sysapps, seek explicit state machine proposals in SDL or
> state diagram form, which can abstract the above in a form suitable for
> modeling in Web IDL****
>
> **
>
I risk saying that in this API we did not seek either the union, nor
intersection of all state machines on all to-be-supported protocols (SS7,
CDMA, GSM, ...), but rather to manage user interaction states with the
calls that a dialer has to do. This stems from earlier lessons learned on
telephony API's. IMO we cannot mandate implementing a certain "web-sysapp"
call state machine which eventually cannot be fully supported by a given
telephony service. Dialer developers will have to know their services
anyway. The API has to be transparent to the protocol details, and still
cover the user interaction use cases of a dialer. This is not impossible
and there are many proofs for that.

To cut it short, I think the spec makes a pretty good proposal on call
states (although more could be added later, e.g. for initialization), and
not all states may be supported on all protocols. However, there were these
2 call states in the spec, which in my view did not fit by any means
("busy", "error") and I suggested removing them.

That said, I am open to be convinced, or corrected. So please take a side
:). Eduardo also promised to look into this later this week.


>  **
>
> Otherwise this is likely to be a long and complicated process of education
> and re-education, as people try to reverse-engineer how telephony works
> today.
>

Well, I am sorry if I gave that impression of trying to re-educate. But
arguments (right, or wrong) are unavoidable if we want to go somewhere.
Tell yours :).


> [1] http://www.3gpp.org/ftp/Specs/html-info/23018.htm****
>
> [2] http://www.3gpp.org/ftp/Specs/html-info/23228.htm****
>
> **
>

Thanks and best regards,
Zoltan