Re: Telephony API draft: disconnect reason

Hi all,

I am inclined to removing the 'busy' state per my experience in 
telephony implementation and Zoltan's comments. We will hear busy tone 
from the carrier but there is no signal for 'busy' state transition 
accompanying that voice tone from the carrier. The call state remains 
until user hangs it up, the call is redirected/forwarded, or the carrier 
releases it. "Busy" information can be obtained by querying the carrier 
about the fail cause of the last call, but at the moment, the call has 
been already released at an earlier time. I think it would be great that 
user is notified 'busy' state as soon as user hears the busy tone. 
Unfortunately, the network doesn't support that per my understanding. 
So, IMHO removing busy state but providing a reason seems appropriate.

Best regards,
Hsinyi

On 2012?11?07? 16:25, Kis, Zoltan wrote:
> 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

-- 
Hsin-Yi Tsai ???
Mozilla Taiwan
T: +886-2-87861100 ext:312
htsai@mozilla.com