- From: Kis, Zoltan <zoltan.kis@intel.com>
- Date: Fri, 2 Nov 2012 14:10:07 +0200
- 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 http://www.cs.utexas.edu/users/vin/Classes/CS386M-Fall04/Readings/ss7.pdf [2] http://www.etsi.org/deliver/etsi_gts/02/0278/05.04.00_60/gsmts_0278v050400p.pdf http://www.eventhelix.com/RealtimeMantra/Telecom/GSM_Originating_Call_Flow.pdf http://en.wikipedia.org/wiki/GSM_services [3] http://git.kernel.org/?p=network/ofono/ofono.git;a=blob;f=doc/voicecall-api.txt Best regards, Zoltan
Received on Friday, 2 November 2012 12:10:41 UTC