Re: USSD interface for ModemManager

["Herriot, Nicholas, VF-Group" <Nicholas Herriot vodafone com>]

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.
2) don't action the request until it got a response.

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
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! ;-)

-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')"
> 
> 




------------------------------