Re: USSD interface for ModemManager

[Dan Williams <dcbw redhat com>]

On Wed, 2010-03-10 at 13:23 +0100, Herriot, Nicholas, VF-Group wrote:
> Hi all,
> 
> 
> <stick_head_above_parapit>
> 
> Just thought I'd put Vodafone's views forward. 
> Pablo the API is fine, and I'm happy we mirror the ConnMan guys. I've
> been reading through their doc's and Ofono Stack.
> 
> There is no need to over-work the USSD API. If the network sends a USSD
> message which requires action and get's no response it will either:
> 1) stick it on a retry queue.

Any idea how often the network will retry?

> 2) don't action the request until it got a response.

Ok; though depending on how long before the network retries, the client
app may not get the request for at least the retry interval.  I'd still
rather have the client app be able to get that request immediately
though, that just seems nicer.

> Furthermore, if a client starts up and see's a buffered/cached USSD
> message saying that you have to respond to subscribed to that new data
> service how would the client know what it's for? For that use case to

These properties are for /network/-initiated requests, thus I assume
that the request from the network includes all necessary details?
Client-initiated requests would still use Initiate() of course.  Or does
the network initiate requests related to the client-initiated request?
That model would have problems...

> work the client would have to persist the state - but in our example the
> app crashed so did not get to persist anything!
> 
> -Message to Marcel-
> You are a very cheeky man! But very true! :-)
> 
> -Message to Dan-
> Chill out you are still the incumbent! ;-)

Competition is not a problem; it makes everyone better.

The problem is lack of focus on the technical issues under discussion,
instead sending mails the lists saying "hey, use my project! it's
awesome!".  This list is about development of NetworkManager and
ModemManager.  It's fine to reference some other project, even
"competing" ones, with respect to specific technical issues.

It is not OK to evangelize other projects. (e.g. "any reason why you are
not using oFono.")

Besides, I doubt Pablo is much interested in using oFono, since he works
on a different modem manager and thus oFono is "competing" with Wader in
the same way it "competes" with ModemManager.  Which shows some
misunderstanding on Marcel's part as to what the original USSD
discussion was actually about.

Good: "oFono developed an API for USSD already, perhaps you should take
a look at it to learn from the mistakes we made and the problems we
encountered"

Bad: "any reason why you are not using oFono. It is a full telephony
stack and does a lot more things in the background that are mandatory.
And you would not have to implement the whole USSD support all by
yourself.  Especially when we merge the integrated PPP support into
oFono, then it might be a nice alternative for you actually."

I think you can see the difference.

Dan

> -Message to all-
> Vodafone are using wader-core to deliver a packaged modem manager, which
> is why Pablo has been asking about USSD.
> The reason why Vodafone have pursued it's coarse of action in regards to
> building their own modem manager and not use NM or CM directly are:
> 1)- The open source community do not have the time and resources to
> deliver the functionality with the huge range of manufacturers dongles.
> We are extended a hand to ensure that our datacards will work on Linux.
> We think that it's best served by putting our time into the device -
> plugin and operator feature set into the betavine connection manger. We
> have no wish to control or dominate anybody's Network Manger, but do
> wish to ensure our datacards and services work.
> 
> To answer Marcel's question. We believe ConnMan is behind in areas of
> dongle support otherwise we would be using the USSD stack if possible
> (Why re-invent the wheel right!). We also are not sure how to
> incorporate our plugin modem architecture and many other features YET! -
> it would maybe take longer to do this than to add in USSD to wader-core.
> Our thoughts were to push forward with supporting Network Manager
> deliver a good modem manager experience till April time.
> 
> If anyone wants to take any of this off line and ask me more of
> Vodafone's plans please ping me. This flame war stuff between NM and CM
> has to stop! Not good for Linux. Not good for OS. Not good for the
> community! Not professional!
> 
> 
> Regards, Nicholas.
> 
> </stick_head_above_parapit>
> 
> 
> 
> 
> 
> On Tue, 2010-03-09 at 13:45 +0100, Pablo Mart? Gamboa wrote:
> > Hi Dan, Marcel and others,
> > 
> > 
> > we would like to extend the ModemManager API so that it can handle 
> > USSD commands. The USSD API of oFono [0] looks quite nice IMHO and I'd
> 
> > like to propose a similar API:
> 
> I'd actually change two things; this API (and by extension the ofono
> one) doesn't allow clients to respond to a USSD request that is pending
> when they start up.  Say your app sends the request, then crashes or
> something.  When it's crashed, the network sends the response.  Now your
> app can't get the response when it starts back up and handle it, it
> would have to cancel the USSD session and send the request again.
> 
> A more robust API would change the NotificationReceived and
> RequestReceived signals into properties instead, which can be queried
> when your app starts up.  See below...
> 
> I did add a org.freedesktop.DBus.Properties.MmPropertiesChanged signal
> to ModemManager a bit ago, mainly to support the
> org.freedesktop.ModemManager.Modem.Enabled property.  So we can
> certainly use that.
> 
> > 
> > USSD Interface
> > ===============
> > 
> > 
> > Service org.freedesktop.ModemManager
> > Interface         org.freedesktop.ModemManager.Modem.Gsm.Ussd
> > 
> > 
> > Methods string Initiate(string command)
> > 
> > 
> > Sends a USSD command string to the network initiating a session.  When
> 
> > the request is handled by the appropriate node of the network, the 
> > method returns the response or an appropriate error.  The network may 
> > be awaiting further response from the ME after returning from this 
> > method and no new command can be initiated until this one is cancelled
> 
> > or ended.
> > 
> > 
> > void Respond(string reply)
> > 
> > 
> > Send a response to the network either when it is awaiting further 
> > input after Initiate() was called or after a network-initiated 
> > request.
> > 
> > 
> > void Cancel()
> > 
> > 
> > Cancel an ongoing USSD session, mobile- or network-initiated.
> > 
> > 
> > Signals 
> >                 NotificationReceived(string message)
> 
> I would change this to a read-only "NetworkNotification" property, and
> then we can use the normal D-Bus properties API to get it, and the
> MmPropertiesChanged signal to notify when it changes.
> 
> > 
> > Signal is emitted on a network-initiated USSD request for which no 
> > response is needed.
> > 
> > 
> > RequestReceived(string message)
> 
> Same here, I'd suggest a read-only "NetworkRequest" property.
> 
> Obviously when there is no request from the network, these two
> properties would be empty strings.
> 
> Any thoughts on this?
> 
> Dan
> 
> 
> 
> > 
> > Signal is emitted on a network-initiated USSD request for which a 
> > response must be sent using the Respond method unless it is cancelled 
> > or the request is not supported.
> > 
> > 
> > Properties string State [readonly]
> > 
> > 
> > Reflects the state of current USSD session.  The values have the 
> > following meanings:
> > 
> > 
> > "idle" No active USSD session.
> > "active" A session is active between the network and the ME, the ME is
> 
> > waiting for a reply from the network.
> > "user-response" The network is waiting for the user's response, client
> 
> > must call Respond().
> > 
> > 
> > 
> > 
> > It is basically a copy of their API (they nailed it down) except for 
> > GetProperties and PropertiesChanged signal which are ConnMan-specific.
> > I haven't had a use-case yet for the "Respond" command (my USSD 
> > petitions are simple), but it needs to be there indeed for future 
> > uses. Thoughts?
> > 
> > 
> > [0] 
> > http://git.kernel.org/?p=network/ofono/ofono.git;a=blob_plain;f=doc/su
> > pplementaryservices-api.txt;hb=HEAD
> > 
> > --
> > Pablo Mart?
> > http://www.linkedin.com/in/pmarti || http://www.warp.es python -c 
> > "print '706d6172746940776172702e6573'.decode('hex')"
> > 
> > 
> 
> 
> 
> 
> ------------------------------
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list