Re: Telephony API draft: disconnect reason

On Fri, Nov 2, 2012 at 5:10 AM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
> 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.

I thought that most phones did display UI indicating to the user that
the number is busy while playing the busy sound coming from the
network.

How do they implement this if GSM doesn't indicate to the terminal
that the call was busy?

You say that in the busy case "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". What does "Call Forward
Busy number" mean? And can this be detected in the terminal?

/ Jonas

Received on Tuesday, 6 November 2012 20:07:51 UTC