Re: Telephony API draft: disconnect reason

On Tue, Nov 6, 2012 at 10:06 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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?
>
>
Phones indeed show if the number *was* busy (if call waiting service was
not enabled).  During my time spent with telephony, I have seen "busy" only
as a disconnect reason, and never as a call state. To be safe I checked
with a few people and they said the same. As described above, the network
keeps the right to handle and try to fix the "busy" situation. There is no
client interaction with the network on what are the user options when the
remote party is busy. The network owns it during the call. Developers can
fix it after the call. Therefore there should be no "busy" call state.
Also, there should not be an "error" call state either.

Best regards,
Zoltan