RE: Telephony API draft: disconnect reason

Zoltan,

Thanks for the explanations. Focusing on managing the user interaction and what the user wants/needs to know about call state is a good approach. I didn't mean to distract the discussion, just to suggest considering mapping to the underlying signaling systems / APIs as a way to verify implementability. But we will get there soon enough I guess, and it's probably OK that not every API feature works on every network.

Thanks,
Bryan Sullivan


From: Kis, Zoltan [mailto:zoltan.kis@intel.com]
Sent: Wednesday, November 07, 2012 12:26 AM
To: SULLIVAN, BRYAN L
Cc: Jonas Sicking; Vicamo Yang; Yoshi Huang; Shian-Yow Wu; Hsin-Yi Tsai; EDUARDO FULLEA CARRERA; public-sysapps@w3.org; JOSE MANUEL CANTERA FONSECA
Subject: Re: Telephony API draft: disconnect reason

On Wed, Nov 7, 2012 at 1:36 AM, SULLIVAN, BRYAN L <bs3131@att.com<mailto: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