Re: Missed call communication protocol
Le mercredi 07 février 2007 à 16:08 +0200, Rodney Arne Karlsen a écrit : 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. I'll second that for switzerland. When you subscribe for a E1 channel or direct VoIP trunk, you cannot send full e.164 number, but only the last digits that stick in the range of number the telco gave (rent ?) to you. There are some supplemental services, like Special Arrangement (SA), that let you send full numbers, without controlling from the telco side if you stay in your range (in fact, your real number still sent on the network, but a supplemental field is added with the number you want to show). Now, for law enforcement, you are *NOT* allowed to change your clip on the network. To solve this issue, I see 2 directions : 1/ Ask for a SS7 trunk, to get more powerfull abilities (cell localisation, supplemental services, direct access to radio, ...) but telco will charge you for that, and a big access fee :( Also you need a SS7 endpoint. 2/ For ISDN network (Q.931 signaling), use of the UserInfo field, on the signaling session (yes, you can send some byte when the phone is ringing, without charge) Probably for all European countries this will be the same. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Missed call communication protocol
On Thursday 08 February 2007 09:01, Alexandre Ghisoli wrote: 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. I'll second that for switzerland. When you subscribe for a E1 channel or direct VoIP trunk, you cannot send full e.164 number, but only the last digits that stick in the range of number the telco gave (rent ?) to you. Now that you mention it I have noticed that sometimes to during testing, but not always. Now, for law enforcement, you are *NOT* allowed to change your clip on the network. Ok, if that is the case then using the CLI won't fly beyond skunkworks anyway. 2/ For ISDN network (Q.931 signaling), use of the UserInfo field, on the signaling session (yes, you can send some byte when the phone is ringing, without charge) Ok... Are you sure you don't mean the 'Display' field in the ISDN SETUP message? I can't find references to a UserInfo field in q931. http://www.cotse.com/CIE/Topics/126.htm Apparently the Q.931 protocol limits the maximum length of the Display Field information element to 44 octets, that should mean one can use 44 characters for a message without opening the line, which would be fine. It seems that GSM should support the full range of ISDN messages, http://kbs.cs.tu-berlin.de/~jutta/gsm/js-intro.html so I'm wondering, why is no one using this for enhanced caller-ID, or similar applications. Where's the catch? Richard. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
RE: Missed call communication protocol
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 08 February 2007 05:34 To: Graham Auld Cc: community@lists.openmoko.org Subject: RE: Missed call communication protocol On Wed, 7 Feb 2007, Graham Auld wrote: I like it, sounds good, I'm all for free-as-in-beer ways to talk to my free-as-in-speech phone :) Nice turn of phrase. I think there's a t-shirt in there, or perhaps an OpenMoko project tagline: free-as-in-beer software for your free-as-in-speech phone M If only things like that would earn me a free-as-in-beer neo (roll eyes) I want a neo, like yesterday G ___ 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
Le jeudi 08 février 2007 à 11:16 +0100, Richard Bennett a écrit : 2/ For ISDN network (Q.931 signaling), use of the UserInfo field, on the signaling session (yes, you can send some byte when the phone is ringing, without charge) Ok... Are you sure you don't mean the 'Display' field in the ISDN SETUP message? I can't find references to a UserInfo field in q931. http://www.cotse.com/CIE/Topics/126.htm Yes, this is the DISPLAY (sorry for the confusion, INFORMATION is a message itself). Apparently the Q.931 protocol limits the maximum length of the Display Field information element to 44 octets, that should mean one can use 44 characters for a message without opening the line, which would be fine. ITU spec say 2 bytes minimum, up to 34 or 82 bytes, depending of the network (should be national specific ?) It seems that GSM should support the full range of ISDN messages, http://kbs.cs.tu-berlin.de/~jutta/gsm/js-intro.html so I'm wondering, why is no one using this for enhanced caller-ID, or similar applications. Where's the catch? I was working on a project, maybe 15 years ago, where we developped a modem to transfer data : 1/ during setup, for free 2/ during the blanks of a conversation (approx 80% of the time, because only one speaks at time, so you got a free 64kbps channel :)) This takes not very long until telco notice the D channel trafic, and since then, they charge for alerting, even if no answer (maybe 10% of unanswered call) to cover this trafic costs. Not sure about now, if this still a used (i'm not working anymore on low level communications). So, second part was to cut additional messages (SETUP DISPLAY) between network (aka roaming or international call). This need a more deeper test, but IMOO, this *could* be working on some networks, and probably not on some other. Now, about GSM networks and Gateways, I really dont know if this is a 1:1 passtrough .. --Alexandre ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Missed call communication protocol
On Thursday 08 February 2007 16:20, Jonathon Suggs wrote: Telcos are not going to let this type of thing happen. I'm all for being able to do things for 'free as in beer' with my 'free as in speech' phone...BUT if we start abusing some features/protocols then they will notice/retaliate. True, using the altered CLI to pass messages could be regarded as abuse, but using the q931 Display field for passing information is a legitimate use of the protocol. That said, this has been a great thread with some very good concepts and outside the box thinking. However, the underlying concept of what we are doing/proposing *IS WRONG* no matter how you look at it. We are trying to effectively use something that does cost money (air time) and instead of paying for it, manipulate it so that we get benefit and pay nothing in return. Just because a resource has not been monetized by the telcos yet, doesn't mean it 'IS WRONG' by definition, it just means nobody saw a business case in charging for it yet. When I started using SMS there was no charge for it, the telco's didn't think people would want to to pay for such a crippled service. In this day of disruptive technologies it is sometimes not clear what is abuse, and what is progress. Is it good or bad that Google decide they have the right to scan whole libraries of books without having permission from the authors? some call it progress, others theft. Is Skype good or bad? Don't they abuse a shared network originally meant for sharing data by sending voice over it without paying? This is also has potential for giving OpenMoko and open phones in general a bad name/press. Headlines reading renegade phones undermine network, higher charges for everyone coming with some baseless statistics about how much it cost them to effectively ban this activity. That's true, but it might also make it clear that there is a need for a cheap lightweight signaling mechanism. If you attended a VON you will notice mobile carriers are full of 'leveraging added value services' IMS is supposed to be the holy grail. In reality they are having trouble getting much beyond MMS, wallpapers and ringtones. They just don't have the imagination to find services that will allow them to recoup on their 3G investments. Now if, instead of treating their customers like dumb terminals, they start to realize that given the correct tools the customers will find their own products, and be happy to pay for them, as long as the point of entry is kept low enough... They need to supply a lightweight signaling protocol, access to their IMS infrastructure through an API, and the ability to prick holes in their walled garden, similar to the way we use firewalls. Sure it sounds radical, but everyone is doing it on the internet, why not in telecom? This would allow really powerfull tools to be built, things the telco's could never imagine, similar to what people are doing with Googlemaps, or Openmoko/Neo for that matter. I administer racks and racks of servers, and never thought I would use a third-party web-service. I like doing things myself, being in controll. Nevertheless I have ended up being an Amazon Webservices customer. Why? because they offer radically new ways of working with a very low initial cost. (I'm talking about EC2 and S3). With a project in its infancy we need to make friends not enemies. We especially don't need to (unnecessarily) piss off the people that control the communication links...as without them (love or hate them) we can't really do anything. With a product like Neo, and a platform like Openmoko we'll be breaking down a whole lot more doors than just this one. Telco's can be afraid of this, and most will be, but if there are any radical thinkers amongst them, like the people behind the Neo, they will recognize that this is an opportunity to use the community to help develop their products for them, and see that offering low-cost tools to allow a flourishing community to thrive will cost them a lot less than old-school RD departments sitting on their hands coming up with overpriced stale offerings. (Why is there still no presence indicator for SMS, no buddy-lists, no re-use of existing online profiles, no server-backup of your contacts, no online access to your SMSes, no online access to your voice-mail, or voice-mail to email forwarding, no multi-number accounts with online presence indicators for work/home and optional location information (Yes he has arrived in London, but is currently in meeting until 2pm) , why isn't all that integrated in the existing business tools?) The list goes on and on. I think it was brought up before that the underlying messaging protocol should be pluggable/interchangeable. That sounds like a good way to proceed. Being able to specify if you should get notifications via SMS or a persistent GPRS connection or even possibly through an out-of-band signaling method like what is being
Re: Missed call communication protocol
On Thursday 08 February 2007 15:06, Alexandre Ghisoli wrote: I was working on a project, maybe 15 years ago, where we developped a modem to transfer data : 1/ during setup, for free 2/ during the blanks of a conversation (approx 80% of the time, because only one speaks at time, so you got a free 64kbps channel :)) This takes not very long until telco notice the D channel trafic, and since then, they charge for alerting, even if no answer (maybe 10% of unanswered call) to cover this trafic costs. I can't say I have ever seen these costs mentioned anywhere for wholesale termination, but they might be mentioned in the TC, and only applied if they detect a strangely high percentage of bad calls. Actually, I would be quite happy if they opened-up this mechanism, and did charge something (like 10% of the CPM) for it for those end-users who wanted the service. it would allow seeing extended user identification for people not yet in your contacts book, and quick saving of contacts without typing their names. (amongst a whole range of other uses) So, second part was to cut additional messages (SETUP DISPLAY) between network (aka roaming or international call). This need a more deeper test, but IMOO, this *could* be working on some networks, and probably not on some other. Now, about GSM networks and Gateways, I really dont know if this is a 1:1 passtrough .. I think some testing would be usefull, although I it will probably not work reliably across networks... I still have a 4E1 Didgium board lying around somewhere begging for something usefull to be done with it... Richard ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
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: 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
