I have been wondering whats the interest might be for USSD applications here in .ke specifically applications not tied to an operator. A case point here might be M-order http://nairobi2011.ipo48.com/M-order by Hilda, etal. Do you think a service like this might benefit from a nationwide/globally accessible USSD interface like via +254 799 353535 number? I have not seen this in kenya before but i have thought about it for sometime now. People, what do you think? -- -erastus +254733725373 Nairobi Kenya
hehe i guess USSD interest here = zero/zilch/nada/0 On Wed, Jul 13, 2011 at 2:04 PM, gisho <gichuhie@gmail.com> wrote:
I have been wondering whats the interest might be for USSD applications here in .ke specifically applications not tied to an operator. A case point here might be M-order http://nairobi2011.ipo48.com/M-order by Hilda, etal. Do you think a service like this might benefit from a nationwide/globally accessible USSD interface like via +254 799 353535 number? I have not seen this in kenya before but i have thought about it for sometime now. People, what do you think?
-- -erastus +254733725373 Nairobi Kenya
Probably your question was not that clear: USSD - does not appeal to many people dude to its limited usability/functionality. Peopld do prefer apps, with USSD used to target all devices. I also think people tend to associate USSD with expensive service charges, hence only use what they can absolutely trust. On 14 July 2011 10:09, gisho <gichuhie@gmail.com> wrote:
hehe i guess USSD interest here = zero/zilch/nada/0
On Wed, Jul 13, 2011 at 2:04 PM, gisho <gichuhie@gmail.com> wrote:
I have been wondering whats the interest might be for USSD applications here in .ke specifically applications not tied to an operator. A case point here might be M-order http://nairobi2011.ipo48.com/M-order by Hilda, etal. Do you think a service like this might benefit from a nationwide/globally accessible USSD interface like via +254 799 353535 number? I have not seen this in kenya before but i have thought about it for sometime now. People, what do you think?
-- -erastus +254733725373 Nairobi Kenya
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
-- with Regards: blog.denniskioko.com <http://www.denniskioko.com/>
Thanks, I think the usability depends on 'what needs to be achieved'. when you want a cheap speedy answer anywhere within GSM vicinity, USSD comes in handy. anyway, am in it with ussdtweet.co.ke. Just thinking of what other 'nice' applications i can do with a global USSD interface On Thu, Jul 14, 2011 at 11:30 AM, Dennis Kioko <dmbuvi@gmail.com> wrote:
Probably your question was not that clear:
USSD - does not appeal to many people dude to its limited usability/functionality. Peopld do prefer apps, with USSD used to target all devices. I also think people tend to associate USSD with expensive service charges, hence only use what they can absolutely trust.
On 14 July 2011 10:09, gisho <gichuhie@gmail.com> wrote:
hehe i guess USSD interest here = zero/zilch/nada/0
On Wed, Jul 13, 2011 at 2:04 PM, gisho <gichuhie@gmail.com> wrote:
I have been wondering whats the interest might be for USSD applications here in .ke specifically applications not tied to an operator. A case point here might be M-order http://nairobi2011.ipo48.com/M-order by Hilda, etal. Do you think a service like this might benefit from a nationwide/globally accessible USSD interface like via +254 799 353535 number? I have not seen this in kenya before but i have thought about it for sometime now. People, what do you think?
-- -erastus +254733725373 Nairobi Kenya
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
-- with Regards:
blog.denniskioko.com <http://www.denniskioko.com/>
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
Personally, I prefer USSD, its like the Chrome OS for phones, no installation :) On Thu, Jul 14, 2011 at 12:08 PM, gisho <gichuhie@gmail.com> wrote:
Thanks,
I think the usability depends on 'what needs to be achieved'. when you want a cheap speedy answer anywhere within GSM vicinity, USSD comes in handy. anyway, am in it with ussdtweet.co.ke. Just thinking of what other 'nice' applications i can do with a global USSD interface
On Thu, Jul 14, 2011 at 11:30 AM, Dennis Kioko <dmbuvi@gmail.com> wrote:
Probably your question was not that clear:
USSD - does not appeal to many people dude to its limited usability/functionality. Peopld do prefer apps, with USSD used to target all devices. I also think people tend to associate USSD with expensive service charges, hence only use what they can absolutely trust.
On 14 July 2011 10:09, gisho <gichuhie@gmail.com> wrote:
hehe i guess USSD interest here = zero/zilch/nada/0
On Wed, Jul 13, 2011 at 2:04 PM, gisho <gichuhie@gmail.com> wrote:
I have been wondering whats the interest might be for USSD applications here in .ke specifically applications not tied to an operator. A case point here might be M-order http://nairobi2011.ipo48.com/M-order by Hilda, etal. Do you think a service like this might benefit from a nationwide/globally accessible USSD interface like via +254 799 353535 number? I have not seen this in kenya before but i have thought about it for sometime now. People, what do you think?
-- -erastus +254733725373 Nairobi Kenya
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
-- with Regards:
blog.denniskioko.com <http://www.denniskioko.com/>
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
Me thoughts: (I just hope I get the clarity of thought to understand half of what I'll say/write next [?][?][?]) Refer to USSD spec doc 22.090 downloadable from http://webapp.etsi.org/key/queryform.asp *<Quote> 5.1.4 Allocation of service codes (to be noted by network operators) Service codes for use in control of Supplementary Services are standardized by international agreement, so must not be used by PLMNs unless authorized, except for those codes allocated for PLMN use. If the message is of the format: 1, 2 or 3 digits from the set (*, #), followed by NN(N), where N=0-9, optionally followed by "* and any number of any characters", and terminating in # SEND: </Quote>* 1. USSD protocol imposes limitatations on input format & length ----> A hitch in getting a unique global USSD code that points to your service. This means that you've got tough luck in fronting "+254 799 353535" as your USSD service universal access code. This leaves you with the regular *yyy# scenario. 2. With only the *yyy# scenario at your disposal, Imagine the hustle in getting all mobile operators to agree to reserve that yyy code for you! Well one may argue that USSD short code re-usability can be enforced by extending that to *yyy*zzzzzzzzz# line of thinking; but heck! Some operator has to effect some changes somewhere. 3. With 1 & 2 above done & dusted there's the commercial aspect. How do the operators who channel the USSD traffic to your app benefit from this whole thing? Who takes care of charging for the access (Not service); them? You? <------Not even your worst enemy should wish you this. In Short. You have to engage the Mobile operators one on one to achieve this. Unless there's an angle that I have refused to see here. :) Tony.
True, it depends on the Mobile Service Provider On Thu, Jul 14, 2011 at 1:17 PM, Tony Likhanga <tlikhanga@gmail.com> wrote:
Me thoughts: (I just hope I get the clarity of thought to understand half of what I'll say/write next [?][?][?])
Refer to USSD spec doc 22.090 downloadable from http://webapp.etsi.org/key/queryform.asp
*<Quote>
5.1.4 Allocation of service codes (to be noted by network operators) Service codes for use in control of Supplementary Services are standardized by international agreement, so must not be used by PLMNs unless authorized, except for those codes allocated for PLMN use. If the message is of the format: 1, 2 or 3 digits from the set (*, #), followed by NN(N), where N=0-9, optionally followed by "* and any number of any characters", and terminating in # SEND:
</Quote>*
1. USSD protocol imposes limitatations on input format & length ----> A hitch in getting a unique global USSD code that points to your service. This means that you've got tough luck in fronting "+254 799 353535" as your USSD service universal access code. This leaves you with the regular *yyy# scenario.
2. With only the *yyy# scenario at your disposal, Imagine the hustle in getting all mobile operators to agree to reserve that yyy code for you! Well one may argue that USSD short code re-usability can be enforced by extending that to *yyy*zzzzzzzzz# line of thinking; but heck! Some operator has to effect some changes somewhere.
3. With 1 & 2 above done & dusted there's the commercial aspect. How do the operators who channel the USSD traffic to your app benefit from this whole thing? Who takes care of charging for the access (Not service); them? You? <------Not even your worst enemy should wish you this.
In Short. You have to engage the Mobile operators one on one to achieve this. Unless there's an angle that I have refused to see here. :)
Tony.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
@Tony, yeah i get you let me give a little illustration of a service called call2service (C2S) or SMS2Service _____________ ____________ ______________ | Ad save 30% | | | | welcome to xyz| | 0733 xxx xxx | --> | disconnect | --> | reply with: | --->Normal USSD dialog proceeds | call toll free | | call | | 1> enroll | |____________| |__________ | | 2> feedback | | _____________ | user calls a number user is not the call handler sends back on the advert charged an SMS or USSD MAP request well, if you want to see how am testing ussdtweet.co.ke send your number to me offlist On Thu, Jul 14, 2011 at 1:21 PM, Paul Kevin <paultitude@gmail.com> wrote:
True, it depends on the Mobile Service Provider
On Thu, Jul 14, 2011 at 1:17 PM, Tony Likhanga <tlikhanga@gmail.com>wrote:
Me thoughts: (I just hope I get the clarity of thought to understand half of what I'll say/write next [?][?][?])
Refer to USSD spec doc 22.090 downloadable from http://webapp.etsi.org/key/queryform.asp
*<Quote>
5.1.4 Allocation of service codes (to be noted by network operators) Service codes for use in control of Supplementary Services are standardized by international agreement, so must not be used by PLMNs unless authorized, except for those codes allocated for PLMN use. If the message is of the format: 1, 2 or 3 digits from the set (*, #), followed by NN(N), where N=0-9, optionally followed by "* and any number of any characters", and terminating in # SEND:
</Quote>*
1. USSD protocol imposes limitatations on input format & length ----> A hitch in getting a unique global USSD code that points to your service. This means that you've got tough luck in fronting "+254 799 353535" as your USSD service universal access code. This leaves you with the regular *yyy# scenario.
2. With only the *yyy# scenario at your disposal, Imagine the hustle in getting all mobile operators to agree to reserve that yyy code for you! Well one may argue that USSD short code re-usability can be enforced by extending that to *yyy*zzzzzzzzz# line of thinking; but heck! Some operator has to effect some changes somewhere.
3. With 1 & 2 above done & dusted there's the commercial aspect. How do the operators who channel the USSD traffic to your app benefit from this whole thing? Who takes care of charging for the access (Not service); them? You? <------Not even your worst enemy should wish you this.
In Short. You have to engage the Mobile operators one on one to achieve this. Unless there's an angle that I have refused to see here. :)
Tony.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
and thats how you can run global USSD applications from your bedroom. maybe it'll take time to catch up but who knows the things you can do On Thu, Jul 14, 2011 at 2:53 PM, gisho <gichuhie@gmail.com> wrote:
@Tony, yeah i get you
let me give a little illustration of a service called call2service (C2S) or SMS2Service
_____________ ____________ ______________ | Ad save 30% | | | | welcome to xyz|
| 0733 xxx xxx | --> | disconnect | --> | reply with: | --->Normal USSD dialog proceeds | call toll free | | call | | 1> enroll | |____________| |__________ | | 2> feedback | | _____________ | user calls a number user is not the call handler sends back
on the advert charged an SMS or USSD MAP request
well, if you want to see how am testing ussdtweet.co.ke send your number to me offlist
On Thu, Jul 14, 2011 at 1:21 PM, Paul Kevin <paultitude@gmail.com> wrote:
True, it depends on the Mobile Service Provider
On Thu, Jul 14, 2011 at 1:17 PM, Tony Likhanga <tlikhanga@gmail.com>wrote:
Me thoughts: (I just hope I get the clarity of thought to understand half of what I'll say/write next [?][?][?])
Refer to USSD spec doc 22.090 downloadable from http://webapp.etsi.org/key/queryform.asp
*<Quote>
5.1.4 Allocation of service codes (to be noted by network operators) Service codes for use in control of Supplementary Services are standardized by international agreement, so must not be used by PLMNs unless authorized, except for those codes allocated for PLMN use. If the message is of the format: 1, 2 or 3 digits from the set (*, #), followed by NN(N), where N=0-9, optionally followed by "* and any number of any characters", and terminating in # SEND:
</Quote>*
1. USSD protocol imposes limitatations on input format & length ----> A hitch in getting a unique global USSD code that points to your service. This means that you've got tough luck in fronting "+254 799 353535" as your USSD service universal access code. This leaves you with the regular *yyy# scenario.
2. With only the *yyy# scenario at your disposal, Imagine the hustle in getting all mobile operators to agree to reserve that yyy code for you! Well one may argue that USSD short code re-usability can be enforced by extending that to *yyy*zzzzzzzzz# line of thinking; but heck! Some operator has to effect some changes somewhere.
3. With 1 & 2 above done & dusted there's the commercial aspect. How do the operators who channel the USSD traffic to your app benefit from this whole thing? Who takes care of charging for the access (Not service); them? You? <------Not even your worst enemy should wish you this.
In Short. You have to engage the Mobile operators one on one to achieve this. Unless there's an angle that I have refused to see here. :)
Tony.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
Aha, I now get the drift of your implementation. A voice call is involved; so yes, the number is accessible from anywhere. I had asummed that the initial access was via a USSD short code. Here's my new framework understanding of the idea 1. Voice call brings in required parameters of the targeted end user. 2. App, captures what it needs from the call details & disconnects the call. 3. An "application originating" (sort of NI USSD dialogue) USSD menu is fired to the end user. Hmmm, I must have encountered something in those lines during those days when mig33 used to offer free calls (credit) I've sent u my numbers off-list. Tony.
exactly thats wot happens. it should be fast enough to look like normal USSD On Thu, Jul 14, 2011 at 3:58 PM, Tony Likhanga <tlikhanga@gmail.com> wrote:
Aha, I now get the drift of your implementation. A voice call is involved; so yes, the number is accessible from anywhere. I had asummed that the initial access was via a USSD short code.
Here's my new framework understanding of the idea
1. Voice call brings in required parameters of the targeted end user. 2. App, captures what it needs from the call details & disconnects the call. 3. An "application originating" (sort of NI USSD dialogue) USSD menu is fired to the end user.
Hmmm, I must have encountered something in those lines during those days when mig33 used to offer free calls (credit)
I've sent u my numbers off-list.
Tony.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
*2011/7/14 gisho <gichuhie@gmail.com> *
*exactly thats wot happens. it should be fast enough to look like normal USSD*
From experience; USSD NI (Network Initiated) dialogues differ from their MO (Mobile Originating) counterparts in that the former come with the annoying "Spurious" displays to the handset. i.e In between the requests & responses, there are definite pauses (Handset goes completely blank).
The MO dialogues have better user experience. Most handsets will show some "processing" indicator etc. Would be nice to see if you hacked that bit :)
Another point of interest: If the flows truly utilize the USSD capability of a mobile network, there is a timer on the HLR that determines the maximum duration of any USSD session. This timer is typically set to 60 seconds, though this can be stretched to a system maximum of 120 seconds. It will also interest me to see if this impose any limitation to the workings of your app. (Think of slow end users) Tony.
USSD being synchronous, it makes a lot of sense to impose the timeout per request trip. this way you can play with it for even 10 mins as long as you make a trip within a minute. this is how many USSDGW works. for example the *100# for safcom. For slow end users, get them to use SMS until they fasten up otherwise adding more time would affect the network performance dramatically On Thu, Jul 14, 2011 at 10:55 PM, Tony Likhanga <tlikhanga@gmail.com> wrote:
Another point of interest:
If the flows truly utilize the USSD capability of a mobile network, there is a timer on the HLR that determines the maximum duration of any USSD session. This timer is typically set to 60 seconds, though this can be stretched to a system maximum of 120 seconds. It will also interest me to see if this impose any limitation to the workings of your app. (Think of slow end users)
Tony.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
the app is using OAuth so i do not store any passwords (which is not even recommended by Twitter) so feel free to sign in On Thu, Jul 14, 2011 at 3:58 PM, Tony Likhanga <tlikhanga@gmail.com> wrote:
Aha, I now get the drift of your implementation. A voice call is involved; so yes, the number is accessible from anywhere. I had asummed that the initial access was via a USSD short code.
Here's my new framework understanding of the idea
1. Voice call brings in required parameters of the targeted end user. 2. App, captures what it needs from the call details & disconnects the call. 3. An "application originating" (sort of NI USSD dialogue) USSD menu is fired to the end user.
Hmmm, I must have encountered something in those lines during those days when mig33 used to offer free calls (credit)
I've sent u my numbers off-list.
Tony.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
I still dont see how this will work internationally? A user initiated USSD request follows USER----->MSC/VLR------>HLR------>USSD GW------->APPLICATION Network initiated follows reverse. In both cases, how will the USSDGW contact the foreign HLR ? ./bernard On Thu, Jul 14, 2011 at 3:58 PM, Tony Likhanga <tlikhanga@gmail.com> wrote:
Aha, I now get the drift of your implementation. A voice call is involved; so yes, the number is accessible from anywhere. I had asummed that the initial access was via a USSD short code.
Here's my new framework understanding of the idea
1. Voice call brings in required parameters of the targeted end user. 2. App, captures what it needs from the call details & disconnects the call. 3. An "application originating" (sort of NI USSD dialogue) USSD menu is fired to the end user.
Hmmm, I must have encountered something in those lines during those days when mig33 used to offer free calls (credit)
I've sent u my numbers off-list.
Tony.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
i would draw it this way A user initiated USSD request follows USER----->MSC/HLR------>VLR------>USSD GW------->APPLICATION though i stand to be corrected, everything is settled by HLR just like how USSD works when roaming On Thu, Jul 14, 2011 at 4:45 PM, Bernard Mwagiru <bmwagiru@gmail.com> wrote:
I still dont see how this will work internationally? A user initiated USSD request follows USER----->MSC/VLR------>HLR------>USSD GW------->APPLICATION
Network initiated follows reverse. In both cases, how will the USSDGW contact the foreign HLR ?
./bernard
On Thu, Jul 14, 2011 at 3:58 PM, Tony Likhanga <tlikhanga@gmail.com>wrote:
Aha, I now get the drift of your implementation. A voice call is involved; so yes, the number is accessible from anywhere. I had asummed that the initial access was via a USSD short code.
Here's my new framework understanding of the idea
1. Voice call brings in required parameters of the targeted end user. 2. App, captures what it needs from the call details & disconnects the call. 3. An "application originating" (sort of NI USSD dialogue) USSD menu is fired to the end user.
Hmmm, I must have encountered something in those lines during those days when mig33 used to offer free calls (credit)
I've sent u my numbers off-list.
Tony.
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
_______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24&t=94 ------------ Other services @ http://my.co.ke
participants (5)
-
Bernard Mwagiru -
Dennis Kioko -
gisho -
Paul Kevin -
Tony Likhanga