RE: USSD interface for ModemManager

2010-03-14 Thread Herriot, Nicholas, VF-Group
It's network and service dependant.
So for UK, Holland, Greece, Egypt there are retry schedules for
services. (Other Networks may have different Nodes from different
vendors so I'm not 100% sure.) We defined a table on the HLR and MLR to
control those schedules. The schedules are non linear and asymmetric.
E.g. 0min, 30min, 1hr, 4hr and another may be 5min, 35min, 65min,
4hr+5min etc..

This means that if a VLR were to fall over then suddenly comes back up
you don't start firing off millions of MWD to all subs on that node.

I take your point and nice idea. My thoughts are what USSD will and are
being used for. Very much a way of building services that pass through
or over the core network. Meaning that the logic is really part of the
service. We are building our PAYT features into the betavine client now
for 4 of our networks. We have no plans to persist state or start
receiving lost messages to infer state. All too complex!!! :-)  So
if the modem manager core was to spit out lost messages our client would
just bin them and start from a known state.

I know of no USSD service that is network initiated, but I don't know
them all! India is the country that use this service most for obvious
reasons. I'll make some enquires next week on some example services used
in India utilising USSD and post a link here for anyone interested to
read on the betavine web site.

Hope this helps, kind regards Nicholas.

 

-Original Message-
From: Dan Williams [mailto:d...@redhat.com] 
Sent: 11 March 2010 23:25
To: Herriot, Nicholas, VF-Group
Cc: networkmanager-list@gnome.org
Subject: Re: USSD interface for ModemManager

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 

v0.7.998: doesn't see ra0

2010-03-14 Thread Colin Brace

Hi all,

First, I'd like to report that NM works really well with my mobile broadband
USB stick (a Huawei, from Vodafone).

Second, I have Fedora 12 installed on an Asus Eee PC 1101HA, with the Ralink
RT3090 wireless chipset.

A driver for this chipset isn't in the kernel yet, so I downloaded the
source from Ralink, compiled and installed it under kernel 2.6.32.9-70. It
loads on boot time, works fine from the command line (ifconfig ra0...
iwconfig... dhclient...).

However, I can't get NM to see it. 

If I go RMB -- Edit connections, the device is listed under Wireless, with
the corresponding MAC address (NM knows it is there!). Yet it never gets
listed in the applet menu under Wireless Network.

I've asked about this in various forums but haven't got a single lead. I am
hoping that someone here might have an idea.

Thanks for all the great work.


-
  Colin Brace
  Amsterdam
  http://lim.nl
-- 
View this message in context: 
http://old.nabble.com/v0.7.998%3A-doesn%27t-see-ra0-tp27898890p27898890.html
Sent from the Gnome - NetworkManager mailing list archive at Nabble.com.

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list