"Andrea Viscovich" <[EMAIL PROTECTED]> provided me a patch for implementing a ring service for the at2 devices. Basical idea is to use the GSM AT commands to get notice of incoming calls to the GSM modem device -- yes! you can call them, but don't wonder if they don't reply :)) -- and activate some kind of logic behind that.
Andrea did this very hard-coded in gw/smsc_at2.c for a very special purpose and the way it is done there we will not be able to include it to cvs. I'll have to break things up a bit and make it more cleanly. Main intension is to introduce a new group called 'ring-service'. This is a single-group, due to the fact that you don't have keywords like in the 'sms-service' type to distinguish the logic, but -- yes, ofter you have the famous but -- you may distinguish by another criterial that is unique, like the caller's phonenumber itself. So here are the considerations that I would like to have some comments and discussion on: (i) group ring-service should be a single-group type. Hence any incoming call will be routed to the same URL/file, whatever, at least the same logic. The logic behind the HTTP request, i.e. Servlet or PHP script may distinguish by caller id and reply on a personalized basis. Such a single-group would look like this: smskannel.conf: [...] group = ring-service url = "http://host/uri?<param>" [...] with almost all fields that are used for the sms-service group. (ii) group ring-service should be a multi-group type, like sms-service. The keyword in sms-service group may be mapped to the caller's phonenumber here, using again routine facilities that are already available, like the unified-prefix things etc. The first group would be the default group if the caller id does not match with the other groups. Such a multi-group would look like this: smskannel.conf: [...] group = ring-service pattern = "4917;+49173;" url = "http://host/uri?<param>" [...] where pattern specifies search-patterns for the caller's phonenumber that are routed to this service. Pros and cons for ring-services IMHO: pro: pull-operation without "investment", which means you "call" the device and hence you don't need to pay for a SMS that initiates a service. pro: higher realtime closure, even while you "reply" by SMS you do initiate the service with a realtime mechanism, the call itself. (Think of the latency time an inbound SMS may take if the network is busy or blocked for SMS). con: we can not multiplex the incoming calls, so when user A calls the device an other user B may get a busy line signal. (This depends of course on the load of the system and the spread of request over time) con: are we still safe with incoming SMS messages when a ring-service is handled?! I don't know exactly, this should be investigated. At least it should work, since it works in real human usage environment too I guess?! Any comments welcome. Stipe [EMAIL PROTECTED] ------------------------------------------------------------------- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de ------------------------------------------------------------------- wapme.net - wherever you are
