Re: SMSC Modules (Was: Kannel Swisscom)
Hi list, this thread leads us to a discussion I had yesterday with Alexander from Centrium (and also Harrie Hazewinkel, who is hopefully still subscribed to the list :) We need to design a clean module API interface (which is already there in some extended sense) and allows to plug them in via dynamical loading of shared objects. In that way you would only load the SMSC module types you need and we may offer template, bare-bone source for new ones to follow. Has anyone checked the approach Harrie did for it? It's available on the web site at http://www.kannel.org/module_api/ Please do have a look and let's get started with this. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 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
RE: SMSC Modules (Was: Kannel Swisscom)
Nicholas Rahn wrote: iServer is a proprietary Swisscom SMSC. It abstracts multiple EMI/UCP connections with a proprietary HTTP/socket interface in order to provide billing, throughput, etc. There is currently no way to use kannel to connect to it. You could, however, write a new kannel smsc module to do it. :-) Nick Is there anyone willing to share his Swisscom iServer smsc module? If not, I'll have to write one soon. Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
SMSC Modules (Was: Kannel Swisscom)
Talking about SMSC modules. Where would one start, writing a new one?
Which source files have to be altered... And what are the requirements that
a module should have?
Is there any documentation?
-- Rene
- Original Message -
From: Nicholas Rahn [EMAIL PROTECTED]
To: Illimar Reinbusch [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, February 25, 2003 3:10 PM
Subject: RE: Kannel Swisscom
iServer is a proprietary Swisscom SMSC. It abstracts multiple EMI/UCP
connections with a proprietary HTTP/socket interface in order to provide
billing, throughput, etc. There is currently no way to use kannel to
connect to it.
You could, however, write a new kannel smsc module to do it. :-)
Nick
On Tue, 2003-02-25 at 14:13, Illimar Reinbusch wrote:
Hi
They have their own iServer, and it uses socket interface.
I belive its developed by them or specially for them.
Example connection:
Data in:
{originator 0792358735}\nVIEW\n
Data out:
{exitCode 0}{charge 0}{billtext 9123 eInfo VIEW}\nANSWER TEXT\n
Is it EMI/UCP interface or specially designed interface?
Illimar
Swisscom has a standard interface which is called EMI/UCP and
kannel works perfectly with it. The only special thing they do
is that you have several parallel connections to get higher
throughput. Just define multiple EMI/UCP smsc connections in
Kannel and make sure they share the same name (to let DLR's work
properly)
and you're done.
If you refer to the premium rate SMS interface, then this is
their own HTTP based crap which for sure is
not supported. It also lacks some SMS features like UDH.
Andreas Fink
Global Networks Switzerland AG
Re: SMSC Modules (Was: Kannel Swisscom)
At 04:20 PM 2/25/03 +0100, Rene Kluwen wrote: Talking about SMSC modules. Where would one start, writing a new one? Which source files have to be altered... gw/smscconn.c: to add an entry for your new smsc module gwlib/cfg.def: if u need special config params for that connection then u need to write your module. Start, mmm look at the smpp module or the emi2 module. And what are the requirements that a module should have? Well, it should meet the requirements of your upstream provider, it should meet the requirements as in smscconn_p.h and it should be nice and well behaved ;-) Is there any documentation? Start with smscconn_p.h nisan
Re: [PATCH] smsc modules directory
Hi Harrie and everyone I saw that smsc.c was moved to the smsc module directory (which I don't think is write - as this is just the API implementation, not a module in itself), but the smsc.h file was left in the gw directory. you have to decide were to put these two files, but they should be together (oh, I'm a hopeless romantic ;-) -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Today is the tomorrow you worried about yesterday.
Re: [PATCH] smsc modules directory
--On Sunday, August 11, 2002 12:20 PM +0300 Oded Arbel [EMAIL PROTECTED] wrote: Hi Harrie and everyone I saw that smsc.c was moved to the smsc module directory (which I don't think is write - as this is just the API implementation, not a module in itself), but the smsc.h file was left in the gw directory. you have to decide were to put these two files, but they should be together Maybe you are correct. I was in doubt to move the smsc.c file and smsc.h. I did move the smsc.c, since it was used under the smscconn API. Then smsc_wrapper is also moved and I consider that one as an API and a module. It is an API for the old smsc module, but it is a module since it is used from within the smscconn API. I believe this is also due to some legacy and if wanted the wrapper could be complete vapourized if the old smsc module would be ported to the smscconn API. One can argue many ways, but that is also due to the many ways various layes and APIs are made. The include file I left up there, actually incorrect. This counts even so for the smsc_p.h include file. I move them under the smsc directory. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ --- Author of MOD-SNMP, enabling SNMP management to the Apache server.
RE: additional modules
-Original Message- From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 21, 2002 7:21 PM To: Oded Arbel; dev-kannel Subject: RE: additional modules HI Oded, --On Sunday, May 19, 2002 8:45 AM +0200 Oded Arbel [EMAIL PROTECTED] wrote: It's easy to add a new SMSC module using the current API. all you need to do is write a new C file for your module, supply the necessary callbacks and register it in smscconn_p.h and smscconn.c. see the recently submitted smsc_cgw.c for a good example. I see what you mean. I was actually thinking of a more modular approach for the main functionality via which no other part/C-code needs to be changed in order to add this extra module. Correct me if I am wrong but with the smsc.c file one still needs to adapt this file in order to have an extra module. No - that is not correct, changing the smsc.c file is the _old_ API, which is not used for newer modules. new modules should be written for the SMSCConn API and need fewer changes in the Kannel source codes. Perhaps, I did not explain my thoughts so well, but I want to start additional threads without patching the core code. Just wondering who on this list provides additional products around Kannel by patching the core?? I would for SNMP. I agree that a run time linking API for modules would be nice, and allow companies to distribure binary modules that were developed to support proprietry standards, among other things. and while this is not high priority in the to do list of any current Kannel developer, in the spirit of open source you are more then welcome to contribute the code to do that to the Kannel development effort :-) AFAIK no one around supplies additional modules for Kannel that are not part of the Kannel distrebution. My company at least have several modules developed in house that are not part of the distrebution, and were developed by adding entries to the relevant source files. Currently, the 'bearerbox' process spawns of 6 threads and I (as part of a prototype) have to spawn an extra thread for the SNMP agent in order to provide near-realtime statistics of the complete WAP gateway. As for an API, I see only a need for start_thread and stop_thread so far, but m aybe there would be more, like a data parameter. Followed by that maybe additional configuration APIs, since each module has potentially an additional private configuration part. I hope this explain it better. You are not speaking of SMSC modules (which I though you were talking about at first). as such, deaper patching of the code is required. What you need is a much more general API for run-time linking of shared objects, and is much harder to do then previously discussed options, such as an API for SMSC modules or an API for sms-service modules. maybe designing one is in order. Now more a point of implementation. I believe there are 2 things important. The end-goal and a smooth transition in which all the time the gateway can work. The transition can be done quick and rigurous or step by step (just slower). I think the step by step approach is preferred, since every one can check and keep doing there own parts of development as well test it all. Therefore, I also believe we should agree on some way forward in which we first make all calls to various module are threads equal (The smsc.c call are already that way). That also is more internals and thus less influencial for external module development. If you are planning on a redesign of the entire infrastructure of Kannel, please supply detailed design ideas if you want meaningful responses. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. Businesses may come and go, but religion will last forever, for in no other endeavor does the consumer blame himself for product failure.
RE: additional modules
It's easy to add a new SMSC module using the current API. all you need to do is write a new C file for your module, supply the necessary callbacks and register it in smscconn_p.h and smscconn.c. see the recently submitted smsc_cgw.c for a good example. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. An eye for an eye and a tooth for a tooth leaves us blind and toothless. -Original Message- From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 15, 2002 1:58 PM To: dev-kannel Subject: additional modules HI all, I have a question regarding adding extra (new) modules to Kannel. Is there a way to do this without changing the core code?? Am I correct that I cannot make use of some API, but need to change/add lines of code in the existing code before I can make for instance an additional thread with new functionality?? regards, Harrie Internet Management Consulting tel: +39-3474932300 / +31-625357135 mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
Re: loadable modules ?
Or have a simple just-text smsbox and aditional smsbox modules to OTA, NSM, EMS, etc ;) - Original Message - From: Bernino Lind [EMAIL PROTECTED] To: Stipe Tolj [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, February 22, 2002 7:53 AM Subject: RE: loadable modules ? Dear developers, Hope you enjoy your friday! If a such plan is underway, please have in mind to make the freeze of the CVS to have a stable branch. Im very thrilled to see this project moving into the module direction. This way I think we should consider to generalize the concept of modules and have well defined description of how to add/write a module to bearerbox with a generalist touch that modules should be capable of instanciating eachother in various ways. In this way a very fantastic complicated loadbalancing or routing would be possible, or some crazy horse might add an on the fly python interpreter as a module or...whatever. Looking at the increasing number of apache modules it seems like human creativity does not stop just because C programmers always make programs that leak memory ;-) I really appreciate this direction, -- med venlig hilsen / Best Regards Bernino Lind +45 7021 0050 catpipe Systems ApS - www.catpipe.net Best done *BSD solutions -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stipe Tolj Sent: 21. februar 2002 20:10 Cc: [EMAIL PROTECTED] Subject: Re: loadable modules ? Oded Arbel wrote: I think that would be very nice feature, and I see several things I can do with it. another revolutionary idea - wouldn't it be nice to load the smsc modules as dynamic libraries ? that way we don't need to build smsc modules that we're not going to use... yep, that brings us to 2 API architectures we should think about: 1) module API to load-on-the-fly smsc modules (smpp, emi2, at2, etc.) 2) module API to load-on-the-fly sms-services (so that there is no need to SIGHUP smsbox for processing) 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
Re: AT* Modules (Was: Re: Oded's AT2 patch)
On 23 February 2002, Bruno David Rodrigues wrote: Now that at2 is stable, could we remove the old at module and then include Matt's patch to at2 ? That was Oded's patch AT2 ... it was derived from my original patch to the AT module. Do old AT module have something that at2 doesn't have ? IMHO we should have a good at module, not several different ones... - Original Message - From: Matthew Flax [EMAIL PROTECTED] To: gatewayZgalore [EMAIL PROTECTED] Sent: Thursday, February 21, 2002 9:04 AM Subject: Oded's AT2 patch Here are my thoughts This patch uses similar workings to my original work. The better thing about AT2 vs. AT is that it has private memory which allows no modifications outside this file, as well as the other advanages of this phase2 thing ! Before the patch is applied, we need a clean patch. The one submitted fails to patch after doing it by hand I have found the following : Currently this works quite well. I have only been able to replicate tests for SMSs which already reside in SIM memory b4 bearerbox startup. It manages to read and delete from memory A OK. From its operation I can see that it would work for SMSs which land in memory during operation. I am quite confident that this patch will improve AT2. I can also suggest leaving AT2 intact and creating AT3. I just wonder wether people would patch AT3 with the same changes they make to AT2 ? If we do choose to create AT3, then I must encourage maintainers of the AT* modules to port patches to AT3 as well as AT2 and vice versa. -- Matt For electronic musicians ... Vector Bass : http://mffmvectorbass.sourceforge.net/ For developers ... TimeScale Audio Mod : http://mffmtimescale.sourceforge.net/ Multimedia Time Code : http://mffmtimecode.sourceforge.net/ 3D Audio Library : http://mffm3daudiolib.sourceforge.net/ -- Matt For electronic musicians ... Vector Bass : http://mffmvectorbass.sourceforge.net/ For developers ... TimeScale Audio Mod : http://mffmtimescale.sourceforge.net/ Multimedia Time Code : http://mffmtimecode.sourceforge.net/ 3D Audio Library : http://mffm3daudiolib.sourceforge.net/
Re: loadable modules ?
Stipe Tolj wrote: Alexei Pashkovsky wrote: I think idea of having the listening http interface inside bearerbox instead of running two executables could be usefull too. Obviously this should be configurable .. that's not how Lars designed it. SO I guess this leeds up here to a religious battle, I wouldn't like to get to. I do not think that this battle is religious. Bearerbox is a bottleneck, so it should be as simple as possible (it is rather complex rigth now). Allthough one smsbox is enough in most cases, sometimes you need more. Aarno
Re: loadable modules ?
Seems like there is some interest in sms service types as loadable modules
so I'm submitting my implementation.
Also included are two sample modules. They are very simple and lack proper
logging and error handling.
As has been mentioned, the loadable module interface has to be carefully
designed with generallity in mind.
The current one feels a bit crude and might need some further refinement.
One way of deriving a good interface could be taking a look at what is
needed to make all current sms service types into loadable libraries.
Note: loading libraries into smsbox requires smsbox to be linked with
-rdynamic.
/Dennis
Dennis Malmström
Erda Technology AB
S:t Larsgatan 12, 582 24 Linköping, Sweden
http://www.erda.se
mail: [EMAIL PROTECTED]
phone: +46 (0)13 377218
gsm: +46 (0)706483090
Index: gw/smsbox.c
===
RCS file: /home/cvs/gateway/gw/smsbox.c,v
retrieving revision 1.170
diff -u -r1.170 smsbox.c
--- gw/smsbox.c 2002/02/07 22:16:35 1.170
+++ gw/smsbox.c 2002/02/22 12:18:57
@@ -6,6 +6,7 @@
#include unistd.h
#include signal.h
#include string.h
+#include dlfcn.h
#include gwlib/gwlib.h
@@ -58,9 +59,21 @@
static Numhash *black_list;
static List *smsbox_requests = NULL;
+static List *loaded_modules = NULL;
int charset_processing (Octstr *charset, Octstr *text, int coding);
+
+
+typedef Octstr* loadable_doit( Msg* msg, Octstr* pattern );
+
+typedef struct {
+Octstr* name;
+void* handle;
+loadable_doit* doit;
+} Module;
+
+
/***
* Communication with the bearerbox.
*/
@@ -655,6 +668,87 @@
}
break;
+case TRANSTYPE_CALL_LOADABLE_MODULE:
+{
+Module* module = NULL;
+Octstr* moduleName = urltrans_name(trans); /* What is the purpose of
+name? Is this use appropriate? */
+
+debug(sms.module, 0, calling module '%s', octstr_get_cstr( moduleName
+) );
+
+ /* is module already loaded? */
+if ( loaded_modules == NULL ) {
+loaded_modules = list_create();
+} else {
+int I = list_len( loaded_modules );
+int i = 0;
+
+for ( i = 0; i I; i++ ) {
+Module* x = (Module*) list_get( loaded_modules, i );
+
+if ( ! octstr_compare( x-name, moduleName ) ) {
+module = x;
+break;
+}
+}
+}
+
+ /* If not, load it */
+if ( module == NULL ) {
+void *moduleHandle = NULL;
+loadable_doit* doit;
+
+debug(sms.module, 0, loading module '%s', octstr_get_cstr(
+moduleName ) );
+
+ /* load module */
+{
+Octstr* fileName = octstr_duplicate( moduleName );
+octstr_append_cstr( fileName, .so );
+moduleHandle = dlopen( octstr_get_cstr( fileName ), RTLD_NOW );
+octstr_destroy( fileName );
+
+ if ( ! moduleHandle ) {
+error(0, dlopen failed: %s, dlerror() );
+*result = NULL;
+octstr_destroy(pattern);
+goto error;
+}
+}
+
+ /* look up symbol */
+{
+const char* errmsg = NULL;
+doit = dlsym( moduleHandle, octstr_get_cstr( moduleName ) );
+errmsg = dlerror();
+
+if ( errmsg ) {
+error(0, dlsym failed: %s, errmsg );
+*result = NULL;
+octstr_destroy(pattern);
+goto error;
+}
+
+if ( ! doit ) { /* we cant't call NULL */
+error(0, dlsym returned NULL );
+*result = NULL;
+octstr_destroy(pattern);
+goto error;
+}
+}
+
+ /* keep track of this module */
+module = (Module*) gw_malloc( sizeof( Module ) );
+module-name = octstr_duplicate( moduleName );
+module-handle = moduleHandle;
+module-doit = doit;
+list_insert( loaded_modules, 0, module );
+}
+
+ /* call module */
+*result = (*module-doit)( msg, pattern );
+octstr_destroy(pattern);
+}
+break;
+
case TRANSTYPE_GET_URL:
request_headers = http_create_empty_headers();
http_header_add(request_headers, User-Agent, Kannel VERSION);
@@ -2105,8 +2199,30 @@
octstr_destroy(reply_couldnotrepresent
Re: loadable modules ?
On Fri, 22 Feb 2002, Stipe Tolj wrote: Alexei Pashkovsky wrote: I think idea of having the listening http interface inside bearerbox instead of running two executables could be usefull too. Obviously this should be configurable .. that's not how Lars designed it. No, but he has also said that the entire architecture should be re-thinked now when more the exact 'goal' is better known (ref: a conversation with him a few minutes ago) - similar reason why I did merge smsbox and bearerbox last summer, but which was a bit too drastic modification to the main project. As a sidenote, old Kannel had an option of having thread smsbox, i.e. instead of sending messages to seperate executable they were handled inside bearerbox. When the message queue/flow system was redesigned, I was too lazy to re-write that thread version... (althought actually it was so simple that instead of callin some write_to_box function the message was just put directly to receive queue...) So, it should be quite simple to re-implement 'thread' smsbox even if a separate smsbox is kept... (but I still feel that the advantages gained from that is far less than the extra problems caused, especially with DLR's etc... Kannel is anyway faster than normal HTTP servers or SMS center connections.. and that protocol between bearerbox and smsbox is not that faster than HTTP protocol...) PS: Loadable modules: a great idea -- kalle marjola
loadable modules ?
Hi I've implemented a sms service type that loads and calls a library dynamically (using dlopen). The configuration would look something like: group = sms-service keyword = default name = mod # name of function called, append .so to get filename(Is it ok to use the name property this way? What is the intended purpose of name?) load = this string is passed to the library function %p %P %a # passed to function mod omit-empty = 1 The library call protocol is: Octstr* func( Msg* msg, Octstr* pattern ); /* return reply text, msg == NULL - library is about to be unloaded. */ where func is the name specified in the sms-service group. The purpose is to offer a way of extending kannel functionallity without changing kannel source code. It can be considered a plugin architecture for sms service types. It is usefull for sms service types that benefit from reusing resources having the same lifetime as the process that use it (in my example, a mySQL connection). Currently the implementation is a bit hacky and needs cleaning and packaging before I can submit it. My question is: should I bother? Is there a need/want for this kind of thing? /Dennis Dennis Malmström Erda Technology AB S:t Larsgatan 12, 582 24 Linköping, Sweden http://www.erda.se mail: [EMAIL PROTECTED] phone: +46 (0)13 377218 gsm: +46 (0)706483090
RE: loadable modules ?
I think that would be very nice feature, and I see several things I can do with it. another revolutionary idea - wouldn't it be nice to load the smsc modules as dynamic libraries ? that way we don't need to build smsc modules that we're not going to use... Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- If they wrote error messages in Haiku ? Yesterday it worked Today it is not working Windows is like that -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 21, 2002 3:07 PM To: [EMAIL PROTECTED] Subject: loadable modules ? Hi I've implemented a sms service type that loads and calls a library dynamically (using dlopen). The configuration would look something like: group = sms-service keyword = default name = mod # name of function called, append .so to get filename (Is it ok to use the name property this way? What is the intended purpose of name?) load = this string is passed to the library function %p %P %a # passed to function mod omit-empty = 1 The library call protocol is: Octstr* func( Msg* msg, Octstr* pattern ); /* return reply text, msg == NULL - library is about to be unloaded. */ where func is the name specified in the sms-service group. The purpose is to offer a way of extending kannel functionallity without changing kannel source code. It can be considered a plugin architecture for sms service types. It is usefull for sms service types that benefit from reusing resources having the same lifetime as the process that use it (in my example, a mySQL connection). Currently the implementation is a bit hacky and needs cleaning and packaging before I can submit it. My question is: should I bother? Is there a need/want for this kind of thing? /Dennis Dennis Malmström Erda Technology AB S:t Larsgatan 12, 582 24 Linköping, Sweden http://www.erda.se mail: [EMAIL PROTECTED] phone: +46 (0)13 377218 gsm: +46 (0)706483090
Re: loadable modules ?
[EMAIL PROTECTED] wrote: My question is: should I bother? Is there a need/want for this kind of thing? I'm definitly interested in seen this. 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
Re: loadable modules ?
Oded Arbel wrote: I think that would be very nice feature, and I see several things I can do with it. another revolutionary idea - wouldn't it be nice to load the smsc modules as dynamic libraries ? that way we don't need to build smsc modules that we're not going to use... yep, that brings us to 2 API architectures we should think about: 1) module API to load-on-the-fly smsc modules (smpp, emi2, at2, etc.) 2) module API to load-on-the-fly sms-services (so that there is no need to SIGHUP smsbox for processing) 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
Re: loadable modules ?
I think idea of having the listening http interface inside bearerbox instead of running two executables could be usefull too. Obviously this should be configurable .. - Original Message - From: Nisan Bloch [EMAIL PROTECTED] To: Stipe Tolj [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, February 21, 2002 1:08 PM Subject: Re: loadable modules ? At 08:09 PM 2/21/02 +0100, Stipe Tolj wrote: Oded Arbel wrote: yep, that brings us to 2 API architectures we should think about: 1) module API to load-on-the-fly smsc modules (smpp, emi2, at2, etc.) 2) module API to load-on-the-fly sms-services (so that there is no need to SIGHUP smsbox for processing) it might also be worth looking at splitting smsbox: 1. interface - at moment HTTP 2. processing bearerbox connections. this way we would have an smsbox api and could bolt other frontends onto it. eg our applications or even something like SMPP. nisan 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
RE: About AT modules and buffering through SIM memory again
-Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Subject: Re: About AT modules and buffering through SIM memory again From my side, as long as basic functionality is not harmed and stability is improved, please submit and we will review it. Ok, here's the m-Wise version of Matthew Flex's SIM buffering - it's a patch against smsc_at2.c and I tried to stay away from touching anything not inside an #ifdef. there are a few places where I couldn't help myself ( ;- ), but most is pretty self explanatory, except in one case : I had to change at2_wait_modem_command to return the number of messages received and processed during the call, and I found no other easy way to do it, w/o rewriting major functionality or submitting to ugly non-procedural programming style. Oh, also the timestamp patches are applied with a bit of a change - I used a swap_nibbles helper function as suggested by Richard Braakman. Cheers Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- A low level language is one whose programs require attention to the irrelevant.
RE: About AT modules and buffering through SIM memory again
Did I just forgot to attach the patch ? yes I did :-) Sorry Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- Boris: In addition to our summer and winter estate, he owned a valuable piece of land. True, it was a small piece, but he carried it with him wherever he went. -- from 'Love and Death' -Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Subject: Re: About AT modules and buffering through SIM memory again From my side, as long as basic functionality is not harmed and stability is improved, please submit and we will review it. Ok, here's the m-Wise version of Matthew Flex's SIM buffering - it's a patch against smsc_at2.c and I tried to stay away from touching anything not inside an #ifdef. there are a few places where I couldn't help myself ( ;- ), but most is pretty self explanatory, except in one case : I had to change at2_wait_modem_command to return the number of messages received and processed during the call, and I found no other easy way to do it, w/o rewriting major functionality or submitting to ugly non-procedural programming style. Oh, also the timestamp patches are applied with a bit of a change - I used a swap_nibbles helper function as suggested by Richard Braakman. Cheers Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- A low level language is one whose programs require attention to the irrelevant. smsc_at2.patch Description: smsc_at2.patch
About AT modules and buffering through SIM memory again
Hi list. Sorry to raise an old issue again, but I think I have some new information which may (or may not) be interesting about Mathew Flex's patch for buffering through SIM memory. I have ported Mathew Flex's patch to the AT2 module, but also changed the way that buffering happens - in my current implementation, the TA isn't set to store messages in SIM memory, but instead setup everything normally, and just polls the SIM memory once in a while to see if any messages have landed there (and then harvest them). the benefits of not abusing SIM memory are obvious (I hope) and also very little of the normal functionality is overridden. I've tested this for the last month, and it seems to be working great on our wavecom modems. the reason I refrained from submitting a patch to the list is that some modems (namely the Siemens M20) don't really like what I'm doing - i.e., after the first call to check on memory status, the behavior of the modem automatically changes to store any incoming message in the SIM memory. I've tried what ever I can do to fix or circumvent this problem (for example, by re-setting CNMI after each memory check), but to no avail. So why am I posting this to the list ? since I gave up on getting broken modems to work, I still think that this patch may interest Kannel developers because a) its enabled by a compile time define - a simple switch to the configure script can enable or disable this behavior, so people who don't want that can simply not set the compile option. b) even with the polling behavior enabled, and with a broken modem, no messages will be lost - SMs will simply be stored in the SIM memory until pulled out by Kannel. it will be slower though (unless you want to poll faster, which I tried to avoid, but can be set by a compile time option too, if you like. c) it does do wonders to the reliability of the at2 module. But, before submitting the changes, I would like to know how the people of the list view this issue. do you think it's worth the effort or the approach all wrong, or what ? Cheers Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- Politicians should read science fiction, not westerns and detective stories. -- Arthur C Clarke
Re: About AT modules and buffering through SIM memory again
Yes - this is most definatly the way to go. Originaly this concept was exactly what AT3 was going to be. On 11 February 2002, Stipe Tolj wrote: Oded Arbel wrote: So why am I posting this to the list ? since I gave up on getting broken modems to work, I still think that this patch may interest Kannel developers because a) its enabled by a compile time define - a simple switch to the configure script can enable or disable this behavior, so people who don't want that can simply not set the compile option. that's the way to go in this case, IMO. b) even with the polling behavior enabled, and with a broken modem, no messages will be lost - SMs will simply be stored in the SIM memory until pulled out by Kannel. it will be slower though (unless you want to poll faster, which I tried to avoid, but can be set by a compile time option too, if you like. we *may* include a case switching for this depending on the device. Since we know in at2 which device we have (like the uname for GSM modems :)) and we may gather information about which versions are broken towards this behaviour, this may be if then'ed or at least issuing a warning towards the user. c) it does do wonders to the reliability of the at2 module. But, before submitting the changes, I would like to know how the people of the list view this issue. do you think it's worth the effort or the approach all wrong, or what ? From my side, as long as basic functionality is not harmed and stability is improved, please submit and we will review it. 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 -- Matt For electronic musicians ... Vector Bass : http://mffmvectorbass.sourceforge.net/ For developers ... TimeScale Audio Mod : http://mffmtimescale.sourceforge.net/ Multimedia Time Code : http://mffmtimecode.sourceforge.net/ 3D Audio Library : http://mffm3daudiolib.sourceforge.net/
At modules in sourceforge
Hi Matthew, Downloaded sourceforge version. It has two at modules. Does at2 contain your fixes enabling two simultaneous MO messages ? Is there a newer version somewhere? Aarno
Re: At modules
All of our devices are Siemens M20T firmware 5.4 Regarding the speed : the measurement was altered since kannel counted same message many times while it could not delete it from sim. don't hurry with the update, I already found some minor bugs. There's one strange thing when new AT cannot delete a mesage from SIM, it reads it again and again. The position cursor is mismatched. Log : 2001-11-13 19:14:57 [21] DEBUG: AT: Command: AT+CMGD=12001-11-13 19:14:57 [21] DEBUG: Read from modem: '+CMS ERROR: 321'2001-11-13 19:14:57 [21] DEBUG: deleteing index at mem index : 1 Ah - are you using a Siemens M20T with firmware revision 4.2 or earlier ? If so, then I think this is a geniune bug in the firmware. I have a note from Siemens saying that error 321 when attempting to delete a message from the SIM is a confirmed defect in the firmware. Also, why do you think AT3 is so much faster than AT and AT2 ? I had thought that the radio link capacity limited the throughput to 1 message every 5 - 7 seconds ?
At modules
Hi all, since we still had some troubles with recent AT2 module, I have tried the new AT module made by Matthew. The kannel I got from his page was installed in production machine. I was amazed by performance, it was really nice to discover that siemens could actually be this fast! The speed is greatly improved, and I didn't speak about stability yet. I think the new AT is way better than the previous one and if you compare stability+productivity, than better than AT2 too, though I really like the changes Andreas made to AT2. Look at this line to understand : 6 AT: /dev/usb/ttyUSB6 (online 218s, rcvd 155, sent 0, failed 0, queued 0 msgs) This is fantastic. The previous At module's best result was 1 sms per 5 sec. I think we should change the AT in CVS with this one. Extremely recommended.
Re: At modules
Howdy, The previous At module's best result was 1 sms per 5 sec. I think we should change the AT in CVS with this one. Extremely recommended. Great, I'd love to. Now if someone could just submit a properly formatted patch for review...it might get applied. Feeling keen, Alexei? See ya, Nick
Re: At modules
Hi all, don't hurry with the update, I already found some minor bugs. There's one strange thing when new AT cannot delete a mesage from SIM, it reads it again and again. The position cursor is mismatched. Log : 2001-11-13 19:14:56 [15] DEBUG: Read from modem: 'OK'2001-11-13 19:14:56 [15] DEBUG: AT: Command: AT+CMGR=62001-11-13 19:14:57 [9] DEBUG: AT: Command: AT+CPMS="SM"2001-11-13 19:14:57 [7] DEBUG: AT: Command: AT+CPMS="SM"2001-11-13 19:14:57 [11] DEBUG: AT: Command: AT+CPMS="SM"2001-11-13 19:14:57 [21] DEBUG: Read from modem: '+CMGR: 1,,240791449737019037200C9144876171453110'2001-11-13 19:14:57 [21] DEBUG: Read from modem: '+CMGR: 1,,240791449737019037200C91448761714531104100840005CCFCF83D07 OK'2001-11-13 19:14:57 [21] DEBUG: AT: Command: AT+CMGD=12001-11-13 19:14:57 [21] DEBUG: Read from modem: '+CMS ERROR: 321'2001-11-13 19:14:57 [21] DEBUG: deleteing index at mem index : 1 2001-11-13 19:14:57 [21] DEBUG: smscconn (AT: /dev/usb/ttyUSB7): new message received2001-11-13 19:14:57 [21] DEBUG: AT: Command: AT+CPMS="SM"2001-11-13 19:14:57 [6] DEBUG: boxc_sender: sent message to 127.0.0.12001-11-13 19:14:57 [5] DEBUG: boxc_receiver: got ack2001-11-13 19:14:57 [15] DEBUG: Read from modem: 'OK'2001-11-13 19:14:57 [15] DEBUG: AT: Command: AT+CMGR=72001-11-13 19:14:57 [19] DEBUG: AT: Command: AT+CPMS="SM"2001-11-13 19:14:57 [21] DEBUG: AT: Command: AT+CMGR=12001-11-13 19:14:58 [13] DEBUG: AT: Command: AT+CPMS="SM"2001-11-13 19:14:58 [15] DEBUG: Read from modem: 'OK'2001-11-13 19:14:58 [15] DEBUG: AT: Command: AT+CMGR=82001-11-13 19:14:58 [21] DEBUG: Read from modem: '+CMGR: 1,,240791449737019037200C9144876171453110'2001-11-13 19:14:58 [21] DEBUG: Read from modem: '+CMGR: 1,,240791449737019037200C91448761714531104100840005CCFCF83D07 OK'2001-11-13 19:14:58 [21] DEBUG: AT: Command: AT+CMGD=12001-11-13 19:14:58 [17] DEBUG: AT: Command: AT+CPMS="SM"2001-11-13 19:14:58 [21] DEBUG: Read from modem: '+CMS ERROR: 321'2001-11-13 19:14:58 [21] DEBUG: deleteing index at mem index : 1 2001-11-13 19:14:58 [21] DEBUG: smscconn (AT: /dev/usb/ttyUSB7): new message received2001-11-13 19:14:58 [21] DEBUG: AT: Command: AT+CPMS="SM"2001-11-13 19:14:58 [6] DEBUG: boxc_sender: sent message to 127.0.0.12001-11-13 19:14:58 [5] DEBUG: boxc_receiver: got ack2001-11-13 19:14:59 [21] DEBUG: AT: Command: AT+CMGR=12001-11-13 19:14:59 [15] DEBUG: Read from modem: 'OK'2001-11-13 19:14:59 [15] DEBUG: AT: Command: AT+CMGR=9 - Original Message - From: "Nick Clarey" [EMAIL PROTECTED] To: "Alexei Pashkovsky" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 8:17 PM Subject: Re: At modules Howdy, The previous At module's best result was 1 sms per 5 sec. I think we should change the AT in CVS with this one. Extremely recommended. Great, I'd love to. Now if someone could just submit a properly formatted patch for review...it might get applied. Feeling keen, Alexei? See ya, Nick
