Hi Marcel, 

> From: ofono-bounces(a)ofono.org 
> [mailto:ofono-bounces(a)ofono.org] On Behalf Of ext Marcel Holtmann

> > The isimodem driver will currently suppress changes in the
> > property value for short-lived suspended states caused by SMS
> > transmission or other signalling. It would also be possible
> > to do the suppression in the oFono core in a generic way.
> > Alternatively, all the state changes and their reasons could
> > also be exposed to oFono clients. However, my feeling is
> > that the information might not be available in a sufficiently
> > coherent way from the different modems. Anyway, I'm open to
> > suggestions.
> 
> we had a brief discussion about this some time ago. And I don't think
> that we can do anything than give the clients (UI and ConnMan) and
> indication that the suspend has happened right now. In 
> general it is too
> late anyway. Since making a voice call and sending a SMS are decisions
> by the end user. And he/she wants to execute them right now. So it is
> expected that GPRS gets suspended.

Yes, I agree, there's no sane way to provide pre-warning. A signal that
comes after the fact still has some potential uses, though:

- a hint for internet connection management to start looking for an
  alternative access, in case GPRS is not back shortly
- a signal for mobile-aware applications to adjust their behavior
- UI notification for the end user

> I do agree that we should not blindly tell the clients suspended if we
> now that it is a short lived situation like SMS. My personal 
> preference
> here would be that this is done inside oFono core and the 
> hardware just
> signals suspend (if it actually supports such notifications).
> 
> So how much work would it take to do the delay in the core?

Not that hard, I guess. We could define a suspend cause code that gets
notified to the core, based on which the core would either modify the
property immediately or start a guard timer. Perhaps something along
the lines of:

enum gprs_suspend_status {
	GPRS_SUSPENDED_DETACHED,
	GPRS_SUSPENDED_SIGNALLING,
	GPRS_SUSPENDED_CALL,
	GPRS_SUSPENDED_NO_COVERAGE,
	GPRS_SUSPENDED_UKNOWN_CAUSE,
	GPRS_AVAILABLE,
};

src/gprs.c:
void ofono_gprs_suspend_notify(struct ofono_gprs *gprs,
				enum gprs_suspend_status status)
{
	...
}

The cause code could also be exposed in the DBus interface.

> I know, that
> the ISI modem is more sophisticated protocol, but we do have AT modems
> that have a bit harder time gathering all the information.

AT modem drivers could use any subset of the above causes.
To allow opt-in implementation in the drivers, the core could
automatically change the status between GPRS_SUSPENDED_DETACHED
and GPRS_AVAILABLE based on attach/detach notifications.

I can redraft the patches to do this. I don't really have a clue
what kind of vendor extensions are available for this in AT modems,
though. Any examples would be helpful.

Br,

	MikaL