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: Fri, 2 Nov 2012 14:10:07 +0200
Message-ID: <CANrNqUfs=Fk0Fp8C_-VGjomYC68zrwtgPdCEoOWqUJnjYE0mmQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: EDUARDO FULLEA CARRERA <efc@tid.es>, "public-sysapps@w3.org" <public-sysapps@w3.org>, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
On Fri, Nov 2, 2012 at 5:29 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Nov 1, 2012 at 4:12 PM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
>> On Fri, Oct 19, 2012 at 1:50 PM, EDUARDO FULLEA CARRERA <efc@tid.es> wrote:
>>> 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.

Note this does not mean the caller phone will actually get that reason.

> I was under the impression that the phone briefly transitioned through
> a "busy" state. During this time, audio is coming from the network and
> is providing the sound of the busy signal. Only after having been in
> this state for a few seconds does the phone transition to a truly
> "disconnected" state.
> Or do phones "fake" the sound of the busy signal by simply playing a
> client-side audio file?

In SS7 [1], if the remote party cannot be connected, the call is
released and the network plays the busy tone. Call forwarding is
possible on busy.

In GSM [2], first the caller's phone is "dialing" a number (radio
channel request, allocation, call setup). Then the network sends "call
proceeding" signal and the call state becomes "connecting". Then the
call is switched from signaling to voice mode. The MSC will attempt to
route the call to the remote party. If it can be reached, the remote
end starts ringing, and the MSC signals the caller for "alerting". If
the remote party picks up, the call becomes "connected", acked by the
caller phone.
So on the success path, the state succession in a TelephonyCall object
is "dialing", "connecting", "alerting", "connected".
If the remote party is busy on another call, and call waiting service
is not used, then the call is redirected to a Call Forward Busy
number, and if it cannot be reached, then the call is redirected to a
Call Forward Not Reachable number. If the remote party is reachable
(phone rings) but the subscriber does not answer until a timeout, the
call is redirected to a Call Forward No Reply number. The latter two
can be set to the voice mail number. The state succession in a
TelephonyCall object is "dialing", "connecting", ... [ the network
provides in-band user interaction, i.e. sends the busy tone ], ...
"disconnected". The network will play the busy tone, but the call
state is not "busy", since there is no explicit signaling for this and
it cannot possibly tell the condition. The network still decides
whether it allows the call going on unchanged (i.e. until you hang
up), or continue the call with modified information (e.g.
redirection), or release the call.

In either case, at the JS object level the next state is
"disconnected" (or the call gets forwarded), and there will be no
"busy" state. oFono [3] doesn't use that state either, with a reason.

[1] http://www.ss7-training.net/sigtran-training/ch08lev1sec3.html
[2] http://www.etsi.org/deliver/etsi_gts/02/0278/05.04.00_60/gsmts_0278v050400p.pdf
[3] http://git.kernel.org/?p=network/ofono/ofono.git;a=blob;f=doc/voicecall-api.txt

Best regards,
Received on Friday, 2 November 2012 12:10:41 UTC

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