Re: Push Email
Yes, The thing is that as the tinymail developer, I can't really anticipate on things like this until they get decided and are known to me. Well, that's not really true. I can, and have, anticipated 'the unknown' in the design of tinymail. I frequently tell people Change is among us, well this again proves it definitely *IS*. I anticipated in that the design flexible on how you implement the observable's part of the game. That can be SyncML but, as you now can see, also IMAP IDLE on the same thread and using the same connection as your normal IMAP one. Who knows tomorrow we will all get mail notification through some obscure bits in the TCP/IP headers of the GPRS connection? And who knows will we someday have to look at the VPI + VCI of ATM cells to know from which provider the messages came? Whether or not it's possible, ATM isn't used for phones, or whether it's a good solution is not really the point. Well, not for tinymail. That's an implementation detail for tinymail. The design that will cope with the event, which is the well known observer pattern, will deal with it once the observable is implemented. If you need a Click kernel module for that, to feed certain bits to the application layer, then that's great. I hope to make that message very clear in clarity ;). The IMAP IDLE support is not a demo, no, but it's also not a statement: I'm not sticking to 'just' IMAP IDLE. Tinymail could and 'will' cope with other Push E-Mail notification methods. It's designed to do so. And it will. So ... basically .. ( and forgive me for my direct to the point style of discussion. I don't mean anything anti-empathic with it :-p ) : Please develop me the method for notifying your phones about messages over the networks that will be used, give me the technical details, and let's implement a libtinymail-openmoko platform specific library that deals with this. Does that sound good? 3..2..1 Go! :-) On Wed, 2007-02-07 at 04:05 +, Graham Auld wrote: Looks fab, good work with tinymail! Sadly I think the issue with OpenMoko/Neo - or any other mobile handset for that matter - is that in order for any of these direct delivery methods to work you have to notify the handset. This means either maintaining an open TCP link over GPRS (or Bluetooth or wifi or a usb cable but they don't count as I'm referring to on the road only connected via phone network use) thereby allowing a channel over which the mail server may send a notification of new mail or send the mail. The real problems with this IMHO being power and comms blocking. Have your phone connected all day via GPRS and I suspect it will use a fair bit more power than not being connected. Also I'm given to understand that the GSM module in the Neo is only capable of GPRS OR a phone call, so things get disturbed each time a phonecall is made/recived. Only other way I see of mail delivery without polling is to have some notification method. Now with something like the Neo it is quite feasable to have a mailsever plugin/addon/write new mailserver from scratch... That could send a specially formatted sms to my number when it had a mail for me (probably also based on the importance of that message determined by a little ruleset, router/server status reports and mailing lists aren't usually urgent - a new job offer or 'meet in the pub in 5 mins' may be a little more criticle). The phone could be programmed to intercept such incomming SMS' and rather than play a cheesy tone and let you read it, the phone could connect up, download your mail and then alert you that there's something worth reading! Ideally of course I could just run postfix (ok maybe something slightly lighter) on my phone and my network provider could make mymobilenumber.gprs.vodafone.co.uk point to my handset :D Now I havn't /actually/ asked vodafone yet but I've got this sneaking suspicion that even if I do make it past 20 levels of callcenter pleb/customer services to anyone vaguely technical they'd still not be too keen... I know someone's floated the idea of hidden/control SMS' on the list before, under the guise of phone security and other things emaily too. It does strike me as a nice idea(TM) however to define some format or paramater of text that could by default be passed to an script handler in openmoko rather than displayed as a text message. Perhaps the first 3 characters could be a sequence of non-printables, 0x05 0x07 0x17 any custom message stuff 0x04 perhaps; ASCII - Enquiry,bell,end transmission block,any custom message stuff (with EOT escaped!),end of transmission Anyone for or against some such control message standard/quasi-standard? I know there is a paramater in SMS' to indicate a flash message, I don't know if there are any other paramters that are 'spare' that could be used to indicate a control message, perhaps my scheme is flawed if there are restrictions on the character set/data that can be transmitted in an
RE: T-Mobile finagling advice?
If you are in the UK, Tescos do a cheap pay as you go SIM; http://www.tesco.com/mobilenetwork/shop/?page=simcards Maybe WalMart do the same in the US? Al - Email sent from www.ntlworld.com Virus-checked using McAfee(R) Software Visit www.ntlworld.com/security for more information ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Ogg Vorbis Chips for Neo3000? :-)
Hi, Thought http://hardware.slashdot.org/hardware/07/02/06/1931244.shtml was interesting - it would be cool to have an OGG decoder onboard a future Neo for iPhone style music-player/phone hybrid functionality in the free software context :-) -- Regards, Dave ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Ogg Vorbis Chips for Neo3000? :-)
On ke, 2007-02-07 at 10:58 +, Dave Crossland wrote: Thought http://hardware.slashdot.org/hardware/07/02/06/1931244.shtml was interesting - it would be cool to have an OGG decoder onboard a future Neo for iPhone style music-player/phone hybrid functionality in the free software context :-) A nice piece of equipment, to be sure, and good to have those around. Still, I doubt it would be worth the cost and space to put it on an (n-gen) Neo; it has a powerful enough general purpose processor, and while the battery would likely last somewhat longer playing with that chip, a music decoder chip wouldn't add any new functionality. (Now, if they'd make a _Theora_ decoder chip... ;P ) -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Ogg Vorbis Chips for Neo3000? :-)
On 11:58:27 2007-02-07 Dave Crossland [EMAIL PROTECTED] wrote: Hi, Thought http://hardware.slashdot.org/hardware/07/02/06/1931244.shtml was interesting - it would be cool to have an OGG decoder onboard a future Neo for iPhone style music-player/phone hybrid functionality in the free software context :-) Wouldn't the existing hardware be capable of doing that already. Don't see a point in adding an extra chip for it. [OT] Dave you probably missed a personal email from me ;) -- Andraž ruskie Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Hacker FAQ: http://www.plethora.net/%7eseebs/faqs/hacker.html Be sure brain is in gear before engaging mouth. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Missed call communication protocol
Hi all, In keeping with moving the control advantage away from the network operators, and to the users, I wonder what you think of this suggestion: When you use a SIP server, like Openser.org , you can set the CLI (Calling line identifier) to any value you like when you send the call on to a PSTN gateway. That means the 'from' number you see on your mobile screen when I call you from a SIP proxy can be any numeric value I like. (most PSTN termination gateways will require a valid e164 number http://www.answers.com/topic/e-164). So I can send a call to my openmoko number, using a CLI set to +10 followed by 13 arbitrary numbers, which should satisfy the e164 requirement . No real phone numbers start with +10 , so I could program my openmoko to reject any calls arriving with a CLI starting with +10, and to process the next 13 numbers of the CLI as a message, hiding this call from the missed calls list. As far as I know there is no networks charge for a rejected call from a mobile, and initiating a call from the openmoko to a number that always returns a 'busy' would also be free of charge. This gives us a free up/down communication channel that can take a payload of 13 numbers in each packet. This could be used for: * Push email notification. * Presence. Like the 'online' indicator in a chat app that shows your status. This is the next big area carriers are looking to charge us for, with their new IM platforms. It can also be used in the routing logic of your own SIP proxy/PBX, for instance: Forward calls to mobile unless GSM presence is 'meeting' in that case send calling number by SMS, if SMS presence is 'available', and forward calls to secretary. * Ultra Short Message Service (SMSes that use a phrase-book on both sender and receiver, so you send the number that identifies a pre-formatted message i.e.: 112='Please call home when you're free'). * Trigger predefined macros (shell scripts) on the phone, like Send GPS coords by SMS. * Sync applications, like 'mark meeting14 as postponed', or New updates available, do you want to sync now? etc Unless our list lawyers shoot this idea down from the start, we could start thinking about the best way to define a missed-call protocol. I'm thinking of using 4 of the numbers as a identifying pincode, then a 3 digit action identifier, and use the next 6 digits as payload depending on what action was selected . For instance update our presence info from the Openmoko to a server: Call server: +122334455 send CLI +101234999100100 That is: +1 = Required valid international code 0 = protocol identifier that never occurs in real calls. 1234= pincode to identify the caller, and assign access rights. (Many different servers could send MCP (missed call protocol) messages to the same phone, a bit like the bluetooth pincode/identifier) 999 = matches 'update presence information' 1 = GSM available. 0 = GPRS offline 0 = Bluetooth offline 1 = SMS available 0 = reserved 0 = reserved. What do you think? Richard. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
RE: Push Email
Hey, sorry I didn't mean to knock what you're doing with tinymail, heck I support it. It just happened to be today when I decided to chime in on the push/talk to a phone from outside discussion. Graham -Original Message- From: Philip Van Hoof [mailto:[EMAIL PROTECTED] Sent: 07 February 2007 09:30 To: Graham Auld Cc: community@lists.openmoko.org; [EMAIL PROTECTED] Subject: Re: Push Email Yes, The thing is that as the tinymail developer, I can't really anticipate on things like this until they get decided and are known to me. Well, that's not really true. I can, and have, anticipated 'the unknown' in the design of tinymail. I frequently tell people Change is among us, well this again proves it definitely *IS*. I anticipated in that the design flexible on how you implement the observable's part of the game. That can be SyncML but, as you now can see, also IMAP IDLE on the same thread and using the same connection as your normal IMAP one. Who knows tomorrow we will all get mail notification through some obscure bits in the TCP/IP headers of the GPRS connection? And who knows will we someday have to look at the VPI + VCI of ATM cells to know from which provider the messages came? Whether or not it's possible, ATM isn't used for phones, or whether it's a good solution is not really the point. Well, not for tinymail. That's an implementation detail for tinymail. The design that will cope with the event, which is the well known observer pattern, will deal with it once the observable is implemented. If you need a Click kernel module for that, to feed certain bits to the application layer, then that's great. I hope to make that message very clear in clarity ;). The IMAP IDLE support is not a demo, no, but it's also not a statement: I'm not sticking to 'just' IMAP IDLE. Tinymail could and 'will' cope with other Push E-Mail notification methods. It's designed to do so. And it will. So ... basically .. ( and forgive me for my direct to the point style of discussion. I don't mean anything anti-empathic with it :-p ) : Please develop me the method for notifying your phones about messages over the networks that will be used, give me the technical details, and let's implement a libtinymail-openmoko platform specific library that deals with this. Does that sound good? 3..2..1 Go! :-) On Wed, 2007-02-07 at 04:05 +, Graham Auld wrote: Looks fab, good work with tinymail! Sadly I think the issue with OpenMoko/Neo - or any other mobile handset for that matter - is that in order for any of these direct delivery methods to work you have to notify the handset. This means either maintaining an open TCP link over GPRS (or Bluetooth or wifi or a usb cable but they don't count as I'm referring to on the road only connected via phone network use) thereby allowing a channel over which the mail server may send a notification of new mail or send the mail. The real problems with this IMHO being power and comms blocking. Have your phone connected all day via GPRS and I suspect it will use a fair bit more power than not being connected. Also I'm given to understand that the GSM module in the Neo is only capable of GPRS OR a phone call, so things get disturbed each time a phonecall is made/recived. Only other way I see of mail delivery without polling is to have some notification method. Now with something like the Neo it is quite feasable to have a mailsever plugin/addon/write new mailserver from scratch... That could send a specially formatted sms to my number when it had a mail for me (probably also based on the importance of that message determined by a little ruleset, router/server status reports and mailing lists aren't usually urgent - a new job offer or 'meet in the pub in 5 mins' may be a little more criticle). The phone could be programmed to intercept such incomming SMS' and rather than play a cheesy tone and let you read it, the phone could connect up, download your mail and then alert you that there's something worth reading! Ideally of course I could just run postfix (ok maybe something slightly lighter) on my phone and my network provider could make mymobilenumber.gprs.vodafone.co.uk point to my handset :D Now I havn't /actually/ asked vodafone yet but I've got this sneaking suspicion that even if I do make it past 20 levels of callcenter pleb/customer services to anyone vaguely technical they'd still not be too keen... I know someone's floated the idea of hidden/control SMS' on the list before, under the guise of phone security and other things emaily too. It does strike me as a nice idea(TM) however to define some format or paramater of text that could by default be passed to an script handler in openmoko rather than displayed as a text message. Perhaps the first 3 characters could be a sequence of non-printables, 0x05 0x07 0x17 any custom message stuff 0x04 perhaps; ASCII - Enquiry,bell,end transmission block,any
RE: Missed call communication protocol
I like it, sounds good, I'm all for free-as-in-beer ways to talk to my free-as-in-speech phone :) G -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Bennett Sent: 07 February 2007 11:17 To: community@lists.openmoko.org Subject: Missed call communication protocol Hi all, In keeping with moving the control advantage away from the network operators, and to the users, I wonder what you think of this suggestion: When you use a SIP server, like Openser.org , you can set the CLI (Calling line identifier) to any value you like when you send the call on to a PSTN gateway. That means the 'from' number you see on your mobile screen when I call you from a SIP proxy can be any numeric value I like. (most PSTN termination gateways will require a valid e164 number http://www.answers.com/topic/e-164). So I can send a call to my openmoko number, using a CLI set to +10 followed by 13 arbitrary numbers, which should satisfy the e164 requirement . No real phone numbers start with +10 , so I could program my openmoko to reject any calls arriving with a CLI starting with +10, and to process the next 13 numbers of the CLI as a message, hiding this call from the missed calls list. As far as I know there is no networks charge for a rejected call from a mobile, and initiating a call from the openmoko to a number that always returns a 'busy' would also be free of charge. This gives us a free up/down communication channel that can take a payload of 13 numbers in each packet. This could be used for: * Push email notification. * Presence. Like the 'online' indicator in a chat app that shows your status. This is the next big area carriers are looking to charge us for, with their new IM platforms. It can also be used in the routing logic of your own SIP proxy/PBX, for instance: Forward calls to mobile unless GSM presence is 'meeting' in that case send calling number by SMS, if SMS presence is 'available', and forward calls to secretary. * Ultra Short Message Service (SMSes that use a phrase-book on both sender and receiver, so you send the number that identifies a pre-formatted message i.e.: 112='Please call home when you're free'). * Trigger predefined macros (shell scripts) on the phone, like Send GPS coords by SMS. * Sync applications, like 'mark meeting14 as postponed', or New updates available, do you want to sync now? etc Unless our list lawyers shoot this idea down from the start, we could start thinking about the best way to define a missed-call protocol. I'm thinking of using 4 of the numbers as a identifying pincode, then a 3 digit action identifier, and use the next 6 digits as payload depending on what action was selected . For instance update our presence info from the Openmoko to a server: Call server: +122334455 send CLI +101234999100100 That is: +1 = Required valid international code 0 = protocol identifier that never occurs in real calls. 1234= pincode to identify the caller, and assign access rights. (Many different servers could send MCP (missed call protocol) messages to the same phone, a bit like the bluetooth pincode/identifier) 999 = matches 'update presence information' 1 = GSM available. 0 = GPRS offline 0 = Bluetooth offline 1 = SMS available 0 = reserved 0 = reserved. What do you think? Richard. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
RE: Push Email
On Wed, 2007-02-07 at 11:29 +, Graham Auld wrote: Hey, sorry I didn't mean to knock what you're doing with tinymail, heck I support it. It just happened to be today when I decided to chime in on the push/talk to a phone from outside discussion. Oh no, I didn't intent to meant hat you knocked what I'm doing with tinymail :) Sorry. I'm not very good at putting the right tone in E-mails :-). My mistake. -Original Message- From: Philip Van Hoof [mailto:[EMAIL PROTECTED] Sent: 07 February 2007 09:30 To: Graham Auld Cc: community@lists.openmoko.org; [EMAIL PROTECTED] Subject: Re: Push Email Yes, The thing is that as the tinymail developer, I can't really anticipate on things like this until they get decided and are known to me. Well, that's not really true. I can, and have, anticipated 'the unknown' in the design of tinymail. I frequently tell people Change is among us, well this again proves it definitely *IS*. I anticipated in that the design flexible on how you implement the observable's part of the game. That can be SyncML but, as you now can see, also IMAP IDLE on the same thread and using the same connection as your normal IMAP one. Who knows tomorrow we will all get mail notification through some obscure bits in the TCP/IP headers of the GPRS connection? And who knows will we someday have to look at the VPI + VCI of ATM cells to know from which provider the messages came? Whether or not it's possible, ATM isn't used for phones, or whether it's a good solution is not really the point. Well, not for tinymail. That's an implementation detail for tinymail. The design that will cope with the event, which is the well known observer pattern, will deal with it once the observable is implemented. If you need a Click kernel module for that, to feed certain bits to the application layer, then that's great. I hope to make that message very clear in clarity ;). The IMAP IDLE support is not a demo, no, but it's also not a statement: I'm not sticking to 'just' IMAP IDLE. Tinymail could and 'will' cope with other Push E-Mail notification methods. It's designed to do so. And it will. So ... basically .. ( and forgive me for my direct to the point style of discussion. I don't mean anything anti-empathic with it :-p ) : Please develop me the method for notifying your phones about messages over the networks that will be used, give me the technical details, and let's implement a libtinymail-openmoko platform specific library that deals with this. Does that sound good? 3..2..1 Go! :-) On Wed, 2007-02-07 at 04:05 +, Graham Auld wrote: Looks fab, good work with tinymail! Sadly I think the issue with OpenMoko/Neo - or any other mobile handset for that matter - is that in order for any of these direct delivery methods to work you have to notify the handset. This means either maintaining an open TCP link over GPRS (or Bluetooth or wifi or a usb cable but they don't count as I'm referring to on the road only connected via phone network use) thereby allowing a channel over which the mail server may send a notification of new mail or send the mail. The real problems with this IMHO being power and comms blocking. Have your phone connected all day via GPRS and I suspect it will use a fair bit more power than not being connected. Also I'm given to understand that the GSM module in the Neo is only capable of GPRS OR a phone call, so things get disturbed each time a phonecall is made/recived. Only other way I see of mail delivery without polling is to have some notification method. Now with something like the Neo it is quite feasable to have a mailsever plugin/addon/write new mailserver from scratch... That could send a specially formatted sms to my number when it had a mail for me (probably also based on the importance of that message determined by a little ruleset, router/server status reports and mailing lists aren't usually urgent - a new job offer or 'meet in the pub in 5 mins' may be a little more criticle). The phone could be programmed to intercept such incomming SMS' and rather than play a cheesy tone and let you read it, the phone could connect up, download your mail and then alert you that there's something worth reading! Ideally of course I could just run postfix (ok maybe something slightly lighter) on my phone and my network provider could make mymobilenumber.gprs.vodafone.co.uk point to my handset :D Now I havn't /actually/ asked vodafone yet but I've got this sneaking suspicion that even if I do make it past 20 levels of callcenter pleb/customer services to anyone vaguely technical they'd still not be too keen... I know someone's floated the idea of hidden/control SMS' on the list before, under the guise of phone security and other things emaily too. It does strike me as a nice idea(TM) however to define some format
Re: Push Email
Hello, Simple curiosity: what's the data link used by blackberries for notification? It can't be gprs or sms... A GSM extension ? Florent ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Missed call communication protocol
On Wednesday 07 February 2007 12:16:33 Richard Bennett wrote: Hi all, In keeping with moving the control advantage away from the network operators, and to the users, I wonder what you think of this suggestion: When you use a SIP server, like Openser.org , you can set the CLI (Calling line identifier) to any value you like when you send the call on to a PSTN gateway. That means the 'from' number you see on your mobile screen when I call you from a SIP proxy can be any numeric value I like. (most PSTN termination gateways will require a valid e164 number http://www.answers.com/topic/e-164). So I can send a call to my openmoko number, using a CLI set to +10 followed by 13 arbitrary numbers, which should satisfy the e164 requirement . No real phone numbers start with +10 , so I could program my openmoko to reject any calls arriving with a CLI starting with +10, and to process the next 13 numbers of the CLI as a message, hiding this call from the missed calls list. As far as I know there is no networks charge for a rejected call from a mobile, and initiating a call from the openmoko to a number that always returns a 'busy' would also be free of charge. This gives us a free up/down communication channel that can take a payload of 13 numbers in each packet. This could be used for: * Push email notification. * Presence. Like the 'online' indicator in a chat app that shows your status. This is the next big area carriers are looking to charge us for, with their new IM platforms. It can also be used in the routing logic of your own SIP proxy/PBX, for instance: Forward calls to mobile unless GSM presence is 'meeting' in that case send calling number by SMS, if SMS presence is 'available', and forward calls to secretary. * Ultra Short Message Service (SMSes that use a phrase-book on both sender and receiver, so you send the number that identifies a pre-formatted message i.e.: 112='Please call home when you're free'). * Trigger predefined macros (shell scripts) on the phone, like Send GPS coords by SMS. * Sync applications, like 'mark meeting14 as postponed', or New updates available, do you want to sync now? etc Unless our list lawyers shoot this idea down from the start, we could start thinking about the best way to define a missed-call protocol. I'm thinking of using 4 of the numbers as a identifying pincode, then a 3 digit action identifier, and use the next 6 digits as payload depending on what action was selected . For instance update our presence info from the Openmoko to a server: Call server: +122334455 send CLI +101234999100100 That is: +1= Required valid international code 0 = protocol identifier that never occurs in real calls. 1234= pincode to identify the caller, and assign access rights. (Many different servers could send MCP (missed call protocol) messages to the same phone, a bit like the bluetooth pincode/identifier) 999 = matches 'update presence information' 1 = GSM available. 0 = GPRS offline 0 = Bluetooth offline 1 = SMS available 0 = reserved 0 = reserved. What do you think? If this works I vote for it (for as long as it will work ...) However receiving SMS is also free no ? couldn't you use that ? Richard. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Missed call communication protocol
If this works I vote for it (for as long as it will work ...) However receiving SMS is also free no ? couldn't you use that ? Well, it may be free in your country, but not in mine :) No, the only free-of-charge thing is the signalization protocol... ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Missed call communication protocol
I like it too, but technically, it's a hidden channel (illegal...) ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Missed call communication protocol
wim delvaux wrote: On Wednesday 07 February 2007 12:16:33 Richard Bennett wrote: As far as I know there is no networks charge for a rejected call from a mobile, and initiating a call from the openmoko to a number that always returns a 'busy' would also be free of charge. This gives us a free up/down communication channel that can take a payload of 13 numbers in each packet. ... What do you think? If this works I vote for it (for as long as it will work ...) However receiving SMS is also free no ? couldn't you use that ? Sending an SMS is not free (at least not here in Australia). Both initiating, and receiving, a missed call is free (as in beer) in Australia. -- Rod ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Missed call communication protocol
On Wednesday 07 February 2007 13:42, Florent THIERY wrote: I like it too, but technically, it's a hidden channel (illegal...) Hi, I wonder if it is illegal, it is used quite a lot allready: Callback has been used for years to circumvent collecting charges: ring a number that returns a 'busy' signal, the system then calls back the CLI it detected. Ringback is used widely by carriers: Call someone who's number is busy, the carrier will offer to connect you when the other party is free, using the CLI they detected from your failed call. Progress messages: Carriers will routinely playback audio messages without actually opening the line, like 'The person you are trying to call is out of reach...' . Missed Call display on a mobile. By displaying the message 'you have 4 missed calls', and then making it possible to ring these people back mobiles are already using MCP in a limited way. As far as I see there is nothing illegal going on. When SMSses were first introduced they were free too, it was only later carriers started charging for them. Carriers could also start charging for missed calls, if people started using MCP in a big way, but by that time openmoko will have wifi ;o) Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Missed call communication protocol
On Wednesday 07 February 2007 12:26, wim delvaux wrote: If this works I vote for it (for as long as it will work ...) However receiving SMS is also free no ? couldn't you use that ? You usually pay to send SMSses. Of course some calling plans entitle you to X free speech minutes, and X free SMSses, but at the end of the day you are still paying for them. If we keep the protocol light enough that it can function by using the Missed Call feature, then we can use the same protocol to do lightweight messaging over GPRS, Bluetooth, Wifi or SMS, whatever transport mode happens to be available, falling back on the Missed Call feature if nothing else is available. In cases where SMS is free to send and receive , or you have unlimited GPRS, you could configure openmoko to use those channels for sending its MCP messages. Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Missed call communication protocol
Hi there While you can choose your callerID when using a sip server, it may not stay the way you set it once it passes through the PSTN gateway. I tried playing with CallerID stuff some time back here in South Africa and our PSTN provider will only allow you to set your caller ID to a number that is assigned to the line you are using. If you are lucky enough to have a PRI line then you start with around 100 numbers. Sorry to throw a spanner in the works but I'm not sure that this will work here. It may work in other countries. I think I heard about it working in the US. -- Rodney Arne Karlsen LPIC-2, Linux+ Product Development Engineer Walters Systems Telephone: +27 31 571 1500 Facsimile: +27 31 571 1519 MSN Messenger: [EMAIL PROTECTED] Website: http://www.ws.co.za Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's relativity. - Albert Einstein ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
RE: T-Mobile finagling advice?
On Wed, 2007-02-07 at 10:05 +, [EMAIL PROTECTED] wrote: If you are in the UK, Tescos do a cheap pay as you go SIM; http://www.tesco.com/mobilenetwork/shop/?page=simcards Maybe WalMart do the same in the US? There are various pay-as-you-go services in the US. $20 (10UKP) will buy you a GSM cellphone and 60 minutes of talk time (With no ID or credit card required btw for fellow privacy freaks) :-D The one that I have does use a SIMcard and they roam onto some GSM network which it doesn't identify. My guess is certainly cingular since its the only GSM network available in my area[0]. Regards, Red ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: T-Mobile finagling advice?
Tmobile has a fairly acurate street by street coverage map on their web site. On 2/6/07, Ben Burdette [EMAIL PROTECTED] wrote: So, I'm thinking seriously about getting a neo1973 when they become available. I called the local T Mobile office and asked them whether I could borrow a phone to see how the signal strength is where I live. They said I could get a 14 day trial with a free phone and just take it back when that is over. My question is, has anyone been through this process before, what's the best way to find out how the service is? I don't know anyone that has a t mobile phone (maybe that should tell me something). And the other thing is, how would I get the neo1973 onto the t mobile network? would I have to get their cheapest phone and then remove the sim card to use in the neo1973? Is it possible to get the sim card without buying a t mobile phone? I'm sure I could find out more by calling T Mobile, but I'm betting there's a lot of expertise in this area on this list. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: T-Mobile finagling advice?
If you are in the UK, Tescos do a cheap pay as you go SIM; http://www.tesco.com/mobilenetwork/shop/?page=simcards Maybe WalMart do the same in the US? There are various pay-as-you-go services in the US. $20 (10UKP) will buy you a GSM cellphone and 60 minutes of talk time (With no ID or credit card required btw for fellow privacy freaks) :-D The one that I have does use a SIMcard and they roam onto some GSM network which it doesn't identify. My guess is certainly cingular since its the only GSM network available in my area[0]. Regards, Red Good info; I think that's what I'll do to evaluate service. I like the idea of pay as you go better than a monthly plan anyway. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
RE: T-Mobile finagling advice?
Redvers Davies writes: The one that I have does use a SIMcard and they roam onto some GSM network which it doesn't identify. My guess is certainly cingular since its the only GSM network available in my area[0]. I'm curious -- which one do you use? Were you able to get just a sim card from them, or did they insist on giving you a phone? ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
RE: T-Mobile finagling advice?
On Wed, 2007-02-07 at 08:41 -0700, Joe Pfeiffer wrote: I'm curious -- which one do you use? Were you able to get just a sim card from them, or did they insist on giving you a phone? They insisted on giving you the phone and looking at it you would need to keep the phone in order to maintain your account since addition on minutes etc is all done via the phone interface. I don't know for sure if it will work in a phone other than theirs. However, I have that phone and my treo 650 in the car. At lunchtime (approx 1 hour) I'll try throwing that SIM into my treo and see if it flies. Regards, Red ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: T-Mobile finagling advice?
On Tue, Feb 06, 2007 at 06:25:30PM -0700, Ben Burdette wrote: So, I'm thinking seriously about getting a neo1973 when they become available. I called the local T Mobile office and asked them whether I could borrow a phone to see how the signal strength is where I live. They said I could get a 14 day trial with a free phone and just take it back when that is over. That would probably be the best way to test a phone, as even their street- by-street coverage maps aren't 100% accurate (But to be fair, ther street map of my house shows I have less signal than I actually do). This is, of course if you live in the US. I don't know if their coverage map works in Europe. My question is, has anyone been through this process before, what's the best way to find out how the service is? I don't know anyone that has a t mobile phone (maybe that should tell me something). And the other thing is, how would I get the neo1973 onto the t mobile network? would I have to get their cheapest phone and then remove the sim card to use in the neo1973? Is it possible to get the sim card without buying a t mobile phone? I know that you can go to t-mobile.com and click the Coverage link in the bar at the top, then punch in your address and it should show you. Other than that, just trying to get a T-Mo phone and try it. Like you said earlier, you can try it for 14 days. As for the getting a Neo on the T-Mo network, that will be easy for basic things and harder for others. Currently, I use a non-T-Mo phone on my T-mo account, and when my girlfriend joined up, she got the same phone from eBay and we got the SIM card from the local T-Mo store. Technically, she got their free phone and they just gave us the card out of it. It didn't cost us anything. I'm sure I could find out more by calling T Mobile, but I'm betting there's a lot of expertise in this area on this list. Also, another thing to consider is that Cingular (The New ATT) uses GSM networks for mobile phones as well, so if T-Mo isn't cutting it for you, and if Cingular is in your area, you can look into them as well. -KW ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: T-Mobile finagling advice?
On Wed, 7 Feb 2007, Mark McClellan wrote: On 2/6/07, Ben Burdette [EMAIL PROTECTED] wrote: So, I'm thinking seriously about getting a neo1973 when they become available. I called the local T Mobile office and asked them whether I could borrow a phone to see how the signal strength is where I live. They said I could get a 14 day trial with a free phone and just take it back when that is over. My question is, has anyone been through this process before, what's the best way to find out how the service is? I don't know anyone that has a t mobile phone (maybe that should tell me something). And the other thing is, how would I get the neo1973 onto the t mobile network? would I have to get their cheapest phone and then remove the sim card to use in the neo1973? Is it possible to get the sim card without buying a t mobile phone? I'm sure I could find out more by calling T Mobile, but I'm betting there's a lot of expertise in this area on this list. Ben, A few years ago I posed the same question to a T-Mobile sales guy. He handed me a working demo phone to take around for a few days. I took it back the next day and signed up. I wouldn't get the cheapest phone they offer. Remember the first edition of the OpenMoko device is geared for developers. You may still need a true 'production' quality phone until 4Q '07. Mark Remember too that service performance will depend on your phone radio and antenna hardware, and not just the provider's network. But it's a good first step. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Push Email
On Wed, 2007-02-07 at 10:30 +0100, Philip Van Hoof wrote: Yes, The thing is that as the tinymail developer, I can't really anticipate on things like this until they get decided and are known to me. Well, that's not really true. I can, and have, anticipated 'the unknown' in the design of tinymail. I frequently tell people Change is among us, well this again proves it definitely *IS*. I anticipated in that the design flexible on how you implement the observable's part of the game. That can be SyncML but, as you now can see, also IMAP IDLE on the same thread and using the same connection as your normal IMAP one. Who knows tomorrow we will all get mail notification through some obscure bits in the TCP/IP headers of the GPRS connection? And who knows will we someday have to look at the VPI + VCI of ATM cells to know from which provider the messages came? Whether or not it's possible, ATM isn't used for phones, or whether it's a good solution is not really the point. Well, not for tinymail. That's an implementation detail for tinymail. The design that will cope with the event, which is the well known observer pattern, will deal with it once the observable is implemented. If you need a Click kernel module for that, to feed certain bits to the application layer, then that's great. I hope to make that message very clear in clarity ;). The IMAP IDLE support is not a demo, no, but it's also not a statement: I'm not sticking to 'just' IMAP IDLE. Tinymail could and 'will' cope with other Push E-Mail notification methods. It's designed to do so. And it will. So ... basically .. ( and forgive me for my direct to the point style of discussion. I don't mean anything anti-empathic with it :-p ) : Please develop me the method for notifying your phones about messages over the networks that will be used, give me the technical details, and let's implement a libtinymail-openmoko platform specific library that deals with this. Does that sound good? 3..2..1 Go! :-) Philip, this rapid implementation is excellent. Could an official openmoko dev. enlighten this situation a bit more :) Mickey? Thanks! Jon snip / -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
