Re: Telephony API draft: disconnect reason

Hello,

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
known).
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
steps.

Please comment.

Best regards,
Zoltan

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