W3C home > Mailing lists > Public > public-sysapps@w3.org > November 2012

Re: Telephony API draft: disconnect reason

From: Kis, Zoltan <zoltan.kis@intel.com>
Date: Thu, 1 Nov 2012 17:12:09 +0200
Message-ID: <CANrNqUcWWtpTph=xWnT3FxRKQWuLdRzmT1cemXHbeA0XGgoO4g@mail.gmail.com>
Cc: "public-sysapps@w3.org" <public-sysapps@w3.org>, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>

On Fri, Oct 19, 2012 at 1:50 PM, EDUARDO FULLEA CARRERA <efc@tid.es> wrote:
> I have uploaded an initial draft of the Telephony API [1], which has been jointly prepared by Zoltan Kis, Jose M. Cantera and myself, who are willing to act as co-editors of this spec.
> Looking forward to your feedback.
> [1] http://sysapps.github.com/sysapps/proposals/Telephony/Telephony.html

I noticed that we may need to remove the "busy" state, which is not
really the state of the call (which has to be "disconnected"), but
rather it tells the reason for being disconnected. If the telephony
modem can determine the reason for disconnect, it will update the call
object with it. I expect this could be done when the "disconnected"
event is triggered, with the "error" attribute set to the disconnect
reason as DOMString, for instance as laconic as oFono does ("local",
"remote", "network"), or with more verbose "busy", "unreachable",
"network-unreachable", "rejected", "barred", "no-sim", "bad-number",
"no-answer" etc. codes, depending on the telephony modem and telephony
network in question.
Note that e.g. oFono has a separate signal for disconnect reason,
emitted just before the "disconnected" state is set (if the reason is
See also http://www.spinics.net/lists/linux-bluetooth/msg24785.html .

The question is how do we want to handle disconnect reason in this API:
1) bound with the disconnect event, which will find the "error"
attribute set with the call disconnect reason.
2) separately with a disconnectreason event, which will find the
"error" attribute set the same way as above.

In either case, the applications will likely save this data to call
history and may even offer a case-by-case resolution (e.g. redial,
answer with SMS, try dialing the contacts' other phone numbers etc).
In either case "disconnected" is the last event that should happen to
a call object (worth mentioning in the spec), and the policy above and
eventual call object recycling can be triggered by it. Therefore, I's
prefer the simpler option 1). In that case we just need to remove the
"busy" state and add text description of the above to the disconnect

Please comment.

Best regards,
Received on Thursday, 1 November 2012 15:12:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:10 UTC