RE: USSD interface for ModemManager
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
Re: USSD interface for ModemManager
On Wed, 2010-03-10 at 08:42 -0800, Marcel Holtmann wrote: Hi Dan, 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: snip 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? 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. Look, I don't go around telling people why they should be using NetworkManager instead of Connman or whatever. That would just make me a dick. Which is what you're being here. I am not talking about ConnMan here at all. So no idea why you are bringing this up. Bad analogy perhaps. I don't jump onto oFono lists and say hey, ModemManager supports CDMA, more devices, and has a simpler yet still flexible API! You should use go look at it instead!. Which is the objection I had. This is a list for development about NetworkManager and ModemManager and how to make them better. I have no problem with competition since that makes each project better. Besides, Pablo works on Wader, which is a connection manager itself. He doesn't work on ModemManager, we just happen to share an API. So I'm not sure what the relevance of directing him over to oFono is anyway. If you have something constructive to add to the conversation, please do. Otherwise don't post, or lets start a big ofono vs. ModemManager thread somewhere else. I have mentioned this before, at some point you need to start thinking from a telephony stack point of view. Especially once you start doing things like SMS and USSD. You have to treat your modem (even if it is a data card) like a phone. Ok, what exactly do you define as a telephony stack? Maybe I phrased my question not clearly enough, but the essential part is that you need a telephony stack. Which one, I don't care personally that much. Or maybe you actually have plans to turn ModemManager in a full telephony stack. Then forget that I ever mentioned oFono. But then again, I was not asking for USSD support in the first place. Just for fun you might wanna compare the AT init sequence of oFono with the one from ModemManager to see what is required. There are a lot of details in the SIM that will be needed even if you don't support voice calls. I think we'd already covered PLMN details in a separate thread, but I assume the other details you mean are phonebook and SMS bits? Is the reason oFono is using sim toolkit stuff for that functionality because it's more conformant than normal AT commands? Or something else? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
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 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
Re: USSD interface for ModemManager
2010/3/10 Pablo Martí Gamboa pma...@warp.es
2010/3/10 Dan Williams d...@redhat.com
On Tue, 2010-03-09 at 17:34 -0800, Dan Williams wrote:
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.
I tossed this into the MM introspection/ directory with my proposed
changes; keeping the changes or dropping them doesn't make a huge
difference to me, I just thought it was a slightly more robust way of
doing the API. Updated spec HTML attached for your review.
Looks good to me, thanks!
Hmm, seems I made up my mind too fast. There is one wart in the proposed API
Initiate/Reply doesn't return anything, it will set the
Network{Request,Notification} property which in turn will fire the
MmPropertiesChanged signal. I think that's a slightly cumbersome way of
getting the reply. IMHO both methods (Initiate and Reply) should return a
string. Our UI code has enough callbacks me thinks, having to listen for the
MmPropertiesChanged signal to get the response of an USSD command seems
wrong to me. MmPropertiesChanged is nice, but has a completely different use
case (a low level internal interaction might result on an important property
change -say Enabled- and the UI is notified)
Thoughts ?
Pablo
--
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
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c print '706d6172746940776172702e6573'.decode('hex')
--
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
Re: USSD interface for ModemManager
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
Re: USSD interface for ModemManager
Hi Dan, 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: snip 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? 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. Look, I don't go around telling people why they should be using NetworkManager instead of Connman or whatever. That would just make me a dick. Which is what you're being here. I am not talking about ConnMan here at all. So no idea why you are bringing this up. If you have something constructive to add to the conversation, please do. Otherwise don't post, or lets start a big ofono vs. ModemManager thread somewhere else. I have mentioned this before, at some point you need to start thinking from a telephony stack point of view. Especially once you start doing things like SMS and USSD. You have to treat your modem (even if it is a data card) like a phone. Maybe I phrased my question not clearly enough, but the essential part is that you need a telephony stack. Which one, I don't care personally that much. Or maybe you actually have plans to turn ModemManager in a full telephony stack. Then forget that I ever mentioned oFono. But then again, I was not asking for USSD support in the first place. Just for fun you might wanna compare the AT init sequence of oFono with the one from ModemManager to see what is required. There are a lot of details in the SIM that will be needed even if you don't support voice calls. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
USSD interface for ModemManager
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:
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)
Signal is emitted on a network-initiated USSD
request for which no response is needed.
RequestReceived(string message)
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/supplementaryservices-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
Re: USSD interface for ModemManager
Hi Pablo, 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: snip 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? 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. Regards Marcel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: USSD interface for ModemManager
On Tue, 2010-03-09 at 12:53 -0800, Marcel Holtmann wrote: Hi Pablo, 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: snip 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? 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. Look, I don't go around telling people why they should be using NetworkManager instead of Connman or whatever. That would just make me a dick. Which is what you're being here. If you have something constructive to add to the conversation, please do. Otherwise don't post, or lets start a big ofono vs. ModemManager thread somewhere else. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: USSD interface for ModemManager
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/supplementaryservices-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
