Re: [PATCH, rfc] Handle network-initiated ussd requests.

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

Hi Andrew,

> Hi,
> 
> On 15 February 2010 18:03, Denis Kenzior <denkenz@gmail.com> wrote:
> >>       } else {
> >>               ofono_error("Received an unsolicited USSD, ignoring for
> >> now..."); DBG("USSD is: status: %d, %s", status, str);
> >>
> >> +             if (ussd->driver->respond_not_supported)
> >> +                     ussd->driver->respond_not_supported(ussd,
> >> +                                     ussd_not_supported_callback,
> >> NULL); +
> >>               return;
> >
> > There's no reason for this else clause to exist now.  The above else if
> > condition is handling this case too.  Just look carefully at ussd driver
> > for AT command modems, we always call back first, then issue ussd_notify.
> >  This is the case for both modems with and without cancel support.
> 
> This is true but we might also get a request when we're in
> USSD_STATE_USER_ACTION and then by my reading we should reply that the
> user is busy i.e. send a cancel, what do you think?  I left the clause
> in the patch but removed the unneeded "ussd->pending" check.

In everything I've researched I understood that there can't be two concurrent 
ussd sessions.  The only things that can happen during USSD_STATE_USER_ACTION:
- Network sends a timed out notification or terminates the ussd action
- someone else actually responds to the USSD (other local client has 
responded)

I think we should simply ignore the re-entrant case (which USSD operation are 
you canceling? First or second?) until we're told otherwise.  However, we 
_should_ handle the network termination / other local client has responded 
cases.

Also, it might be a good idea to have a State property that shows the current 
USSD request state.

Regards,
-Denis