[PATCH] SMPP Optional params
Hi All
A small patch to get the values of the optional SMPP params.
Added: smpp_pdu_get_opt(SMPP_PDU *pdu, unsigned long opt_tag);
Nisan
--- ../cvs/gateway/gw/smsc/smpp_pdu.h Tue Mar 4 08:18:51 2003
+++ ../gateway-click/gw/smsc/smpp_pdu.h Tue Mar 4 07:49:10 2003
@@ -95,6 +95,7 @@
long smpp_pdu_read_len(Connection *conn);
Octstr *smpp_pdu_read_data(Connection *conn, long len);
+Octstr *smpp_pdu_get_opt(SMPP_PDU *pdu, unsigned long opt_tag);
#endif
--- ../cvs/gateway/gw/smsc/smpp_pdu.c Tue Mar 4 08:18:19 2003
+++ ../gateway-click/gw/smsc/smpp_pdu.c Tue Mar 4 07:48:22 2003
@@ -275,6 +275,50 @@
return pdu;
}
+Octstr *smpp_pdu_get_opt(SMPP_PDU *pdu, unsigned long opt_tag)
+{
+
+Octstr *ret=NULL;
+
+debug(sms.smpp, 0, SMPP PDU %p get_opt:, (void *) pdu);
+debug(sms.smpp, 0, type_name: %s, pdu-type_name);
+
+switch (pdu-type) {
+#define OPTIONAL_BEGIN(num_expected) \
+if (p-optional_parameters != NULL) { \
+Octstr *key = NULL, *tag_val = NULL;
+unsigned long id;
+#define TLV(tag_id, min_len, max_len) \
+id = tag_id; \
+if (opt_tag == id) \
+{ \
+key = octstr_create_from_data((char*)id, 2); \
+tag_val = dict_get(p-optional_parameters, key); \
+if (tag_val != NULL) \
+ret = octstr_duplicate(tag_val); \
+else \
+ret = NULL; \
+octstr_destroy(key); \
+}
+#define OPTIONAL_END \
+}
+#define INTEGER(name, octets)
+#define NULTERMINATED(name, max_octets)
+#define OCTETS(name, field_giving_octets)
+
+#define PDU(name, id, fields) \
+case id: { struct name *p = pdu-u.name; fields } break;
+#include smpp_pdu.def
+default:
+break;
+
+}
+
+debug(sms.smpp, 0, SMPP PDU get_opt ends.);
+return ret;
+
+}
+
void smpp_pdu_dump(SMPP_PDU *pdu)
{
[PATCH] Octstr additions
Hi All
Some additions to octstr.[ch]
/*
* Strip all occurence of char ch from start of Octstr
*/
void octstr_strip_char(Octstr *text, char ch);
/*
* Check if ostr is numeric
*/
int octstr_isnum(Octstr *ostr1);
/*
* Replace all occurences of needle with repl within haystack
*/
void octstr_replace(Octstr *haystack, Octstr *needle, Octstr *repl);
/*
* Symbolise hexstr - 78797a becomes %78%79%7a
*/
int octstr_symbolize(Octstr *ostr);
Nisan
--- ../cvs/gateway/gwlib/octstr.h Thu Sep 5 21:11:59 2002
+++ ../gateway-click/gwlib/octstr.h Sat Mar 1 00:07:32 2003
@@ -582,4 +582,25 @@
*/
int octstr_recode (Octstr *tocode, Octstr *fromcode, Octstr *orig);
+/*
+ * Strip all occurence of char ch from start of Octstr
+ */
+void octstr_strip_char(Octstr *text, char ch);
+
+/*
+ * Check if ostr is numeric
+ */
+int octstr_isnum(Octstr *ostr1);
+
+/*
+ * Replace all occurences of needle with repl within haystack
+ */
+
+void octstr_replace(Octstr *haystack, Octstr *needle, Octstr *repl);
+
+/*
+ * Symbolise hexstr - 78797a becomes %78%79%7a
+*/
+int octstr_symbolize(Octstr *ostr);
+
#endif
--- ../cvs/gateway/gwlib/octstr.c Wed Sep 25 16:05:51 2002
+++ ../gateway-click/gwlib/octstr.c Sat Mar 1 00:07:59 2003
@@ -2181,3 +2181,81 @@
return resultcode;
}
+
+void octstr_strip_char(Octstr *text, char ch)
+{
+int start = 0, end, len = 0;
+
+seems_valid(text);
+gw_assert(!text-immutable);
+
+/* Remove char from the beginning of the text */
+while ((ch == octstr_get_char(text, start))
+ start = octstr_len(text))
+start ++;
+
+if (start 0)
+octstr_delete(text, 0, start);
+
+
+seems_valid(text);
+}
+
+int octstr_isnum(Octstr *ostr1)
+{
+
+
+int start = 0;
+char c;
+
+seems_valid(ostr1);
+while (start octstr_len(ostr1))
+{
+c = octstr_get_char(ostr1, start);
+if (!isdigit(c) (c!='+'))
+return 0;
+start++;
+}
+return 1;
+
+}
+
+
+void octstr_replace(Octstr *haystack, Octstr *needle, Octstr *repl)
+{
+int p=-1;
+long len;
+
+len = octstr_len(needle);
+
+while ((p = octstr_search(haystack,needle,p+1)) != -1)
+{
+octstr_delete(haystack, p, len);
+octstr_insert(haystack, repl, p);
+}
+}
+
+// symbolise string, return 0 if empty, -1 on error or 1 on success
+int octstr_symbolize(Octstr *ostr)
+{
+long len, i;
+
+seems_valid(ostr);
+gw_assert(!ostr-immutable);
+
+if (ostr-len == 0)
+return 0;
+
+/* Check if it's in the right format */
+if (!octstr_check_range(ostr, 0, ostr-len, gw_isxdigit))
+return -1;
+
+len = ostr-len + (ostr-len/2);
+octstr_grow(ostr, ostr-len * 2);
+
+for (i=0;ilen;i+=3)
+octstr_insert_data(ostr, i, %, 1);
+
+return (1);
+}
+
Re: [RFC] smsc logging
At 11:29 AM 3/2/03 +0100, Stipe Tolj wrote: Hi list, anyone had the chance to check the patch?! I'm interested what other people think of it. I like!!... Done some basic testing and all looks good Busy rolling cvs into our version, so will be looking at the code in more depth, will let you know if there are any oddities.. nisan 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: [PATCH] admin http 'loglevel' command for bearerbox
Hi kewl +1 nisan At 12:03 PM 2/27/03 +0100, Angel Fradejas wrote: Hi all Find attached a patch to support an admin HTTP command to change the log level without restaring bearerbox. Example: http://localhost:13000/loglevel?password=xlevel=1 Please consider committing to cvs. 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
Re: [RFC] log-file, log-level per smsc group
Hi Stipe Yup.. I looked at the same and at the time decided it wasnt worth the time and effort. Our log files do tend to balloon quite rapidly, and its a real pain trying to trawl debug info out with many SMSC connections. SO this would be real handy, but would probabally require rewriting the log functions in gwlib and most likely we would have to include params to indicate which log file the debug, info, warning calls relate to. Nisan At 06:57 PM 2/27/03 +0100, you wrote: Hi list, I'm hacking arround the whole day trying to implement a way to log entries to smsc-id specific log-files, so that you have group = smsc ... log-file = /tmp/smsc-a.log log-level = 0 which is exclusive to the main bearerbox.log. So if you have log-file and log-level set all logging output will be passed there instread of the main file. This seems to be very tricky. Assistense is highly appriated :) 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: bug in smsc_smpp.c login failure
hi yeah.. great +1 nisan At 11:27 AM 2/27/03 +0100, Alexander Malysh wrote: Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-MIME-Autoconverted: from 8bit to quoted-printable by mail-in-01.piro.net id LAA28081 Hi, what about attached patch ? Am Donnerstag, 27. Februar 2003 10:30 schrieb Stipe Tolj: Alan McNatty wrote: On Thu, 2003-02-27 at 18:54, Nisan Bloch wrote: Hi At 03:46 PM 2/27/03 +1300, Alan McNatty wrote: Hello, found that if I type in the smpp password incorrectly kannel loops forever trying to reconnect. ie: -1 from me In the current form this path will not allow any retries for any sort of bind error. eg what happens if there is a temporary connectivity issue, or the SMPP server is down for a short while/ What I'm trying highlight is that there is a gap in logic .. Currently regardless of the type of error we continually retry to bind. If we specifically receive an error indicating the password is invalid the SMSC is obviously up but we may as well kill the thread. yep, that's true in some sense. Trying to reconnect forever while we get the error information from the SMSC that we can't login with that credentials *could* be considered as login abuse :) At least I would consider this if our SMPP clients would hammer our SMPP server with invalid credentials. 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 -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de msn: [EMAIL PROTECTED] icq: 98063111
Re: bug in smsc_smpp.c login failure
Hi At 03:46 PM 2/27/03 +1300, Alan McNatty wrote: Hello, found that if I type in the smpp password incorrectly kannel loops forever trying to reconnect. ie: -1 from me In the current form this path will not allow any retries for any sort of bind error. eg what happens if there is a temporary connectivity issue, or the SMPP server is down for a short while/ Nisan [6] DEBUG: SMPP PDU 0x80f3a18 dump: [6] DEBUG: type_name: bind_receiver_resp [6] DEBUG: command_id: 2147483649 = 0x8001 [6] DEBUG: command_status: 14 = 0x000e [6] DEBUG: sequence_number: 732 = 0x02dc [6] DEBUG: system_id: NULL [6] DEBUG: SMPP PDU dump ends. [6] ERROR: SMPP[xxx]: SMSC rejected login to receive, code 0x000e. [6] ERROR: SMPP[xxx]: I/O error or other error. Re-connecting. And so on .. The smsc_smpp.c handle_pdu notices the error (and indeed reports on it) but it's not noticed at the io_thread level so keeps trying. I worked around it by setting smpp-quitting = 1 after the error message in handle_pdu (see patch) which has the effect of shutting down the failing threads (so they don't keep trying). Crude - provided as example only - will look at improving this. Also, in the instance you only have 1 smpp connection which when fails in this way, the bearerbox sits without actually shutting down (ie: doesn't realise there are no active threads and clean up, etc). Should the bearerbox shutdown in this instance? Cheers, Alan -- Alan McNatty [EMAIL PROTECTED]
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: multiple bearer box - Netikos?
At 11:37 AM 2/25/03 +0100, Stipe Tolj wrote: Kalle Marjola wrote: That's why I published them, altought I knew that some things are a bit too radical. As we have no resources to do any development on it right now, I hope that you can scavenge useful things out from it and this way improve the Kannel project. yep, +1 :) that's what we all do. ditto +1 i dont have much spare time, but I could over the next week or so make a list of those pieces that we can move over basically transparently (eg http libs) and those that would be relatively easy (eg adding the sms-service rules from NMGW) and those that cannot be done without some major changes to Kannel. Nisan 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: multiple bearer box - Netikos?
At 10:20 AM 2/20/03 +0100, Stipe Tolj wrote: Alexander Malysh wrote: that's true. That's why we implemented the 'include = file' feature for the config file handling, so you can structurize the global config file for your own needs. It's like you setup an apache config for every VHost you'd like to run. AFAIK, the Netikos version had such things. We should definetly start to port things from their version to the official tree. yup it does. I keep wanting to do this but then worry about getting off the current tree too much. For whats its worth here are some notes that I started on NMGW a while back. * I like the merged smsbox/bearerbox. * NMGW have much better handling of concat messages. I had a situation where a user posted through a udh of 264 bytes, this will crash the current Kannel. I havent tested this with your NMGW, but from looking at your code it seems you will handle it. * NMGW reconcats MO messages. * The current Kannel however has a much more complete EMI,SMPP and AT2 implementations, * The DLR handing is a tricky one. NMGW has a better implementation and abstraction layer for the dlr stuff, and it would be relatively easy to roll the exisiting Kannel DLR functionality into NMGW but not the other way. * Utoi's reworked HTTP lib is indeed substantially better. * Without doubt the extended charset / unicode support is great. * I see that you dont have mclass support in the sms push CGI - Kannel is ahead on smsbox/config file options. * Kannel has better control over stopping and starting individual SMSC connections from the HTTP admin interface, but NMGW reloads configs better. I dont think either can add new SMSC connections on the fly. I am also not sure how NMGW handles queued messages when restarting from HTTP interface. * A bit concerned about the lack of mysql support? Is the NMGW store file support super stable? It becomes critical for deliv acks to keep state between restarts of the gateway? * The NMGW sms-service stuff is very very nice. I like the power of the conditions and matching rules. And might be helpfull for handling deliv_acks. I think rolling NMGW into Kannel would be worthwhile. At the same time come up with a combined bbox+smsbox version, with the same HTTP interface. In addition an API to build XXXboxs with. Smsbox would be the first such app and maybe the smppbox and emibox that have been mentioned on the list. Nisan
Re: multiple bearer box ?
At 10:29 AM 2/20/03 +0100, Stipe Tolj wrote: ok, as all of you kick-ass with benchmark figures, I'll do too ;)) The max. throughput we reached with a Dell PowerEdge 2x CPU (1.2 GHz) Linux 2.4 Kernel in a fakesmsc - bearerbox - smsbox chain was approx. 2400 msg/sec. We had also MO values while loading the bearerbox quueue (fakesmsc - bearerbox) with over 1 msg/sec. So I guess this is pretty fast :) that is - but tell me were you using dlr acks? And if so internal or mysql store? Nisan 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: [PATCH] allow setting service-type for SMPP SMSC
At 01:51 PM 2/18/03 +, David Holland wrote: Please find below a patch to allow an SMPP SMSC group to contain a service-type definition. Previously Kannel would always send NULL, i.e. use default service-type. I've tested this patch and it works against Xwireless/Mblox SMPP server. If no-one objects I'll commit it to CVS and update the userguide. looks good +1 nisan
Re: [PATCH] allow setting service-type for SMPP SMSC
At 04:49 PM 2/18/03 +0100, Stipe Tolj wrote: just kidding. I guess you're then interested in getting smppbox into Kannel's cvs repository, right?! No, it's a standalone app that has nothing to do with Kannel. I know (or I assumed to be more precise :). But I guessed you'd be interested in playing arround with out SMPP server implementation based on Kannel's sources. I think many of us on the list would love to play with yur smpp box...hint... ;-) nisan 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: Billing Kannel SMS side
At 04:58 AM 2/18/03 +, Kita B. Ndara wrote: --- Stipe Tolj [EMAIL PROTECTED] wrote: Kita B. Ndara wrote: What I mean is to allow a config file element (in SMSC group) that is a command that is called by bearerbox before it inserts the msg into the smsc specific queue, and another command in the conf file that is run after the SMSC accepts the message. Both comamnd specs allow substitution of %P, %p (sender, recipient) and others. why not just do the first call on submitting to smsbox and use the std Kannel DLR mechanism for the rest? nisan Any thoughts? Kannel's scope of function is beyond billing. In other words, billing should be done by software component entities that are *not* part of Kannel. To make it short and simple. It's more or less a religious question if you incorporate billing facilities to Kannels functional scope. Most of us decided not to do this, because billing (in that SMS traffic sense) is not standardized in any way and hence we would implement properietary things, which open source developer don't like :) Ok, but in this case kannel would merely leave it up to external commands to provide this functionality -- just as we do for content. That is, only if the pre-submit comamnd returns TRUE do we put the msg on the smsc-specific queue, and after it is accepted, we run the post-submit command. The first one is like a balance check, the latter the real billing command. Does this still violate the goodness of OS? 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 __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: [PATCH] make SMPP's PDU parsing more robust
hi At 03:06 PM 1/26/03 +0100, Alexander Malysh wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stipe, On Sunday 26 January 2003 14:13, Stipe Tolj wrote: Hi Alexander, Alexander Malysh schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, attached patch make parsing of SMPP optional parameters more robust (IMHO). Patch include some cleanups , increasing MAX_SMPP_PDU_LEN comments and votes please ... looks good.. +1 and tested and works for us.. nisan
Re: [RFC] smppbox cvs module
At 02:17 PM 1/26/03 +0100, Stipe Tolj wrote: Hi list, if Wapme releases it's SMPP server implementation (smppbox) to kannel, would we include it directly to kannel's gateway cvs module, or would we inheritate an own module called smppbox? The benefit of having an own module would imply that other SMSC server implementation, i.e. EMI/UCP maybe called emibox and hence a cleaner code seperation would be present. Yes, rather keep it as a separate module. I think smsbox should be a base interface to bearerbox (using common HTTP for the low level user and aggregator) and smppbox, emibox and whatever would be more for the professional SMS carriers and hosters. What of potential merges with Kalle's Netikos (some of which is much better than Kannel) and the path they have taking of combining bearerbox and smsbox? Nisan
RE: Notice of issue in SMPP Driver
Hi At 12:37 PM 1/22/03 +, Michael Mulcahy wrote: Hi, The approach I have taken is to set the status to be SMSCCONN_RECONNECTING when either the transmitter or receiver go down. This allows an administrator to see the problem immediately. Plus I did not want to make changes to the SMSCConn module for just the SMPP driver. We have a patch running that is done quite differently. We have added two elements to the SMPP structure; transmitter_status (also used for transceiver) and receiver_status. We then change these variables depending on the status of the various components. We have also added smscconn states SMSCCONN_ACTIVE_RECV and SMSCCONN_ACTIVE_TRANS. We have modified the status page to show connecting if both connections down, receiver if running as a receiver and transmitter if transmitter only and online if both. This allows us for example to run a transmitter or receiver only connection. (yes one of our providers insisted that we bind with essentially 2 different sets of account details, one instance transmitter only and the other receiver only). Nisan Any comments or suggestions? Michael. ANAM Wireless Internet Solutions http://www.anam.com mailto:[EMAIL PROTECTED] +353 1 284 7555 Castle Yard, Saint Patrick's Road, Dalkey, County Dublin, Ireland -Original Message- From: Indrek Mandre [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 17:40 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Notice of issue in SMPP Driver Is there a patch for this? What is the status of this bug? And the race condition? I've had cases of similar behaviour where the driver fails to send messages out and nothing else but a restart helps. I understood from the following messages that this is a fundamental problem with the smpp driver. How to fix this? Regards, Indrek Michael Mulcahy wrote: Hi All, There is a bug in the current SMPP driver that stops the driver from accepting messages to be submitted to the SMSC. Scenario: SMPP SMSC configured as receiver and transmitter, transmitter and receiver connected and bound successfully. 1) Receiver SMPP connection disconnects 2) SMPP SMSC status changed to SMSCCONN_RECONNECTING 3) Receiver SMPP connection reconnects to SMSC after reconnect delay and sends bind_receiver pdu 4) In handling of bind_receiver_resp the status is incorrectly set to SMSCCONN_ACTIVE_RECV as the previous status was SMSCCONN_RECONNECTING (This does not take into account that the transmitter is still successfully connected) 5) Now the driver cannot receive any messages for submission to SMSC as status is not SMSCCONN_ACTIVE. There also appears to be a potential race condition in the handling of the bind_transmitter_resp and the bind_receiver_resp pdus, the status variable is modified in both places and is not protected. Regards, Michael Mulcahy. ANAM Wireless Internet Solutions http://www.anam.com mailto:[EMAIL PROTECTED] +353 1 284 7555 Castle Yard, Saint Patrick's Road, Dalkey, County Dublin, Ireland
Re: Problem with SMPP 3.3 SMSC in message delivery
Hi please give more of the log file, we need to see the full deliver_sm PDU dump nisan At 12:09 AM 1/10/03 +0530, Ritesh Shah wrote: Hi YJ, How did u solved the prob. of Incomplete replies I am trying to connect with logica smsc. I am also getting the same prob. which The Kannel bearer's log text indicated that it: SMPP handle_pdu Got DELIVER REPORT But then it followed up with ERROR: Got DELIV REPORT but couldnt find message or was not interested in it For deliver_sm I am getting service_type NOREP (No Reply), We have defined the system-type = Ext. ###deliver_sm dump 2003-01-09 19:44:28 [6] DEBUG: type_name: deliver_sm 2003-01-09 19:44:28 [6] DEBUG: command_id: 5 = 0x0005 2003-01-09 19:44:28 [6] DEBUG: command_status: 0 = 0x 2003-01-09 19:44:28 [6] DEBUG: sequence_number: 3 = 0x0003 2003-01-09 19:44:28 [6] DEBUG: service_type: NOREP 2003-01-09 19:44:28 [6] DEBUG: source_addr_ton: 1 = 0x0001 2003-01-09 19:44:28 [6] DEBUG: source_addr_npi: 1 = 0x0001 2003-01-09 19:44:28 [6] DEBUG: source_addr: 919029392923 2003-01-09 19:44:28 [6] DEBUG: dest_addr_ton: 0 = 0x 2003-01-09 19:44:28 [6] DEBUG: dest_addr_npi: 1 = 0x0001 2003-01-09 19:44:28 [6] DEBUG: destination_addr: 1234 ## and then there is no submit_sm for this msg. following is the dump of bind_transmitter and bind_receiver ## 2003-01-09 17:37:41 [5] DEBUG: type_name: bind_transmitter 2003-01-09 17:37:41 [5] DEBUG: command_id: 2 = 0x0002 2003-01-09 17:37:41 [5] DEBUG: command_status: 0 = 0x 2003-01-09 17:37:41 [5] DEBUG: sequence_number: 0 = 0x 2003-01-09 17:37:41 [5] DEBUG: system_id: test 2003-01-09 17:37:41 [5] DEBUG: password: test 2003-01-09 17:37:41 [5] DEBUG: system_type: Ext 2003-01-09 17:37:41 [5] DEBUG: interface_version: 51 = 0x0033 2003-01-09 17:37:41 [5] DEBUG: addr_ton: 0 = 0x 2003-01-09 17:37:41 [5] DEBUG: addr_npi: 1 = 0x0001 2003-01-09 17:37:41 [5] DEBUG: address_range: ^1234 2003-01-09 17:37:41 [6] DEBUG: type_name: bind_receiver 2003-01-09 17:37:41 [6] DEBUG: command_id: 1 = 0x0001 2003-01-09 17:37:41 [6] DEBUG: command_status: 0 = 0x 2003-01-09 17:37:41 [6] DEBUG: sequence_number: 1 = 0x0001 2003-01-09 17:37:41 [6] DEBUG: system_id: test 2003-01-09 17:37:41 [6] DEBUG: password: test 2003-01-09 17:37:41 [6] DEBUG: system_type: Ext 2003-01-09 17:37:41 [6] DEBUG: interface_version: 51 = 0x0033 2003-01-09 17:37:41 [6] DEBUG: addr_ton: 1 = 0x0001 2003-01-09 17:37:41 [6] DEBUG: addr_npi: 1 = 0x0001 2003-01-09 17:37:41 [6] DEBUG: address_range: ^1234 # This prob. is only coming with logica smsc, there was no prob. connecting with other types of SMSC's. Regards Ritesh Shah
Re: Country Table Lookup
hi u need a list of the country dialing codes, and then you do a longest prefix match. i.e. the longest prefix in your country list that matches the leftmost digits of the destination msisdn. How to do this, well there are many algorithms. nisan At 08:45 PM 12/27/02 +0200, George C wrote: no they are 3 digit country codes.. quite a few.. cyprus +357 ok. this number.. how do i know its china or trinidad.. +8681234567 ok its trinidad cause it has the 3rd digit 8 but how u code this and the logic.. 1st sms get sent.. then i neeed to appoint a charge to it.. by looking up what coutry it belongs to.. and then addint the charge to it... hmmm... im still baffled.. :) I think the 3 digits codes you mention are actually US area codes, not international prefixes... So they'll be prefixed by 1 (north american zone code). As far as I could tell no 3 digits codes conflict with a 2 digits code (ie albania is 355 but 35 alone is not affected) Stefan On Fri, 2002-12-27 at 14:15, George C wrote: Was wondering what logic can be used to lookup what country sms is being sent to.. Hope u can help me out.. its something that is done usually by providers.. and i need to implement this logic.. Wish to find a way to be able to tell from a International mobile number i.e +868 that this number is a gsm in xyz country. Then I will be able to add a charge my clients based on the numbers and country of destination since each country is different to send sms.. in terms of charges.. when I have picked the country code that sms has been sent to.. I can deduct then the sms credits from that account.. How or what algorith or logic can i use for this.. If all the country codes would be similar to +30 and +40, it would be easy. But some countries have 3 digits, and for some, the first 2 digits are identical to a country with 2 digits. For instance: Spain - 34 U.S. Virgin Islands - 340 China - 86 Trinidad and Tobago - 868 St Kitts and Nevis - 869 hmmm how or do u have any methods how I can approach this.?? much appreciate any info or docs. :) /george -- Stefan Praszalowicz [EMAIL PROTECTED] Avedya
RE: [PATCH] admin, sendsms bind to interface
Hi At 07:06 PM 12/23/02 -0300, Mauricio Ramos wrote: Sorry about this late question. I didn't undertand what this bind to a specified interface is for. A server can be setup with multiple ip numbers on one or more network cards. We use such a setup in our LVS cluster. It is useful in such situations to bind the listener to a specific interface. Nisan I also didn't find neither any messages related nor the usage of this in CVS's Userguide. Best regards, Mauricio. -Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 19, 2002 9:33 PM To: Nisan Bloch Cc: [EMAIL PROTECTED] Subject: Re: [PATCH] admin, sendsms bind to interface Patches to the bb_http.c and smsbox.c to allow the admin and sendsms http interface to bind to a specified interface. files patched: gw/smsbox.c, gw/bb_http.c, gwlib/cfg.def +1, sounds reasonable and doesn't change default behaviour, commited to cvs. Thanks for the patch Nisan. 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: [PATCH] EMI part 2
Hi any take on this EMI patch yet? nisan At 10:33 PM 12/8/02 +0200, you wrote: Hi This patch to the EMI module tries to address the problem of dealing with msgs that do not get acked by the SMSC after the wait-ack period. This should never happen but it does, even with wait-acks in the region of 240-600secs. Thanks to Andreas for his input. It adds a new config var (wait-ack-expire) that defines what to do with such an error. After some discussion between Andreas and I, we decided that a disconnect/reconnect should be the default behavior. The various option for wait-ack-expire are 0x00 - disconnect/reconnect, (default) 0x01 - as is now, requeue, but this could potentially result in the msg arriving twice 0x02 - just carry on waiting (given that the wait-ack should never expire this is the mst accurate) I have submitted this patch distinctly different from the patch to handle the window problem to make voting and testing easier. I have tested it a fair amount, but I think it needs some more. Nisan
Re: kannel OTA WAP settings R320
Hi
At 06:27 PM 2/28/02 +0200, Peter Löfman wrote:
I have sent ota messages successfully to these phones:
Nokia: 3330, 6210, 7110, 6310, 8310, 6510
Ericsson: R520, T39, T65, T68, T20, T29, T66
Just ask if you want example xml files.
Yes, please..
Nisan
Phones I am about to test with is Siemens phones and Motorola.
BR
Peter Lofman
- Original Message -
From: Indrek Mandre [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 27, 2002 3:51 PM
Subject: kannel OTA WAP settings R320
Does current kannel CVS support sending OTA WAP setting to
Ericsson R320? Has any1 got it working? Could you provide
detailed information how you did it? Or any other Ericsson
model?
I have running a CVS from Nov 20011107 and according to testing
the sendota works only for Nokias (6210). For R320 it just
comes as an empty message.
I just upgraded the ota sending function to current CVS level,
still no luck. The R320 receives two messages, it can't even
concatenate them?
I also had a look on the contrib/php-admin/sendota.php, but
that seemed to be broken. The R320 also received empty message,
the msg to Nokia was recognised but values were empty.
I also found a little bug there (latest CVS):
functions.inc:
function octstr_append_cstr($mystring)
{
for($pos=0;$posstrlen($mystring);$pos++) {
- $mystring2 .= sprintf(%%%02x,$mystring[$pos]);
+ $mystring2 .= sprintf(%%%02x,ord($mystring[$pos]));
}
return ($mystring2);
}
Regards,
Indrek
[PATCH] EMI
Hi
Here is a patch to fix the problem of Kannel not respecting the window size
setting. The constant EMI2_MAX_TRN was been used for all limits and the
mod function to find a new free slot/window, rather than the window setting.
Nisan
--- cvs/gateway/gw/smsc/smsc_emi2.c Thu Dec 5 19:03:57 2002
+++ ./smsc_emi2.c Thu Dec 5 22:34:20 2002
@@ -780,7 +780,7 @@
int i;
debug(smsc.emi2, 0, EMI2[%s]: clear_sent called,
octstr_get_cstr(privdata-name));
-for (i = 0; i EMI2_MAX_TRN; i++) {
+for (i = 0; i privdata-window; i++) {
if (privdata-slots[i].sendtime privdata-slots[i].sendtype == 51)
list_produce(privdata-outgoing_queue,
privdata-slots[i].sendmsg);
privdata-slots[i].sendtime = 0;
@@ -816,7 +816,7 @@
*/
static int emi2_next_trn (SMSCConn *conn)
{
-#define INC_TRN(x) ((x)=((x) + 1) % EMI2_MAX_TRN)
+#define INC_TRN(x) ((x)=((x) + 1) % privdata-window)
int result;
while (SLOTBUSY(conn,PRIVDATA(conn)-priv_nexttrn))
@@ -1121,7 +1121,7 @@
if (PRIVDATA(conn)-unacked (current_time
(PRIVDATA(conn)-check_time + 30))) {
PRIVDATA(conn)-check_time = current_time;
- for (i = 0; i EMI2_MAX_TRN; i++) {
+ for (i = 0; i privdata-window; i++) {
if (SLOTBUSY(conn,i)
PRIVDATA(conn)-slots[i].sendtime (current_time -
PRIVDATA(conn)-waitack)) {
PRIVDATA(conn)-slots[i].sendtime = 0;
Re: SMPP getting stuck
Hi
Here is a different take the Andreas's SMPP generic_nack patch. This is a
bit more complete, and fixes a potential NULL pointer exception in the
code. On line 922 a check is made for msg==NULL, and an error message
outputed, but then bb_smscconn_send_failed is called with the NULL msg.
This patch is quite different so I have attached the changed case, rather
than a diff.
Nisancase generic_nack:
cmd_stat = pdu-u.generic_nack.command_status;
os = octstr_format(%ld, pdu-u.generic_nack.sequence_number);
msg = dict_remove(smpp-sent_msgs, os);
octstr_destroy(os);
if (msg == NULL) {
warning(0, SMPP[%s]: SMSC sent generic_nack
with wrong sequence number 0x%08lx,
octstr_get_cstr(smpp-conn-id),
pdu-u.generic_nack.sequence_number);
} else {
if ((cmd_stat == SMPP_ESME_RTHROTTLED) ||
(cmd_stat == SMPP_ESME_RMSGQFUL)) {
info(0,SMPP[%s]: SMSC sent generic_nack %s: status 0x%08lx ,
(cmd_stat==SMPP_ESME_RTHROTTLED?ESME_RTHROTTLED:ESME_RMSGQFUL),
octstr_get_cstr(smpp-conn-id),pdu-u.generic_nack.command_status);
time((smpp-throttling_err_time));
reason = smpp_status_to_smscconn_failure_reason(
pdu-u.generic_nack.command_status);
bb_smscconn_send_failed(smpp-conn, msg, reason);
--(*pending_submits);
} if (cmd_stat == SMPP_ESME_RUNKNOWNERR) {
info(0,SMPP[%s]: SMSC sent generic_nack SMPP_ESME_RUNKNOWNERR:
status 0x%08lx ,
octstr_get_cstr(smpp-conn-id),pdu-u.generic_nack.command_status);
reason = smpp_status_to_smscconn_failure_reason(-1);
bb_smscconn_send_failed(smpp-conn, msg, reason);
--(*pending_submits);
} else {
error(0, SMPP[%s]: SMSC sent generic_nack type 0x%08lx, code
0x%08lx.,
octstr_get_cstr(smpp-conn-id), pdu-type,
pdu-u.generic_nack.command_status);
reason = smpp_status_to_smscconn_failure_reason(-1);
bb_smscconn_send_failed(smpp-conn, msg, reason);
--(*pending_submits);
}
}
break;
[PATCH] EMI
Hi
Sorry ran diff against wrong directory.
here is the correct one.
Nisan
--- cvs/gateway/gw/smsc/smsc_emi2.c Sun Dec 8 21:08:50 2002
+++ kannel-cvsup/gw/smsc/smsc_emi2.c Sun Dec 8 21:06:57 2002
@@ -780,7 +780,7 @@
int i;
debug(smsc.emi2, 0, EMI2[%s]: clear_sent called,
octstr_get_cstr(privdata-name));
-for (i = 0; i EMI2_MAX_TRN; i++) {
+for (i = 0; i privdata-window; i++) {
if (privdata-slots[i].sendtime privdata-slots[i].sendtype == 51)
list_produce(privdata-outgoing_queue,
privdata-slots[i].sendmsg);
privdata-slots[i].sendtime = 0;
@@ -816,7 +816,7 @@
*/
static int emi2_next_trn (SMSCConn *conn)
{
-#define INC_TRN(x) ((x)=((x) + 1) % EMI2_MAX_TRN)
+#define INC_TRN(x) ((x)=((x) + 1) % PRIVDATA(conn)-window)
int result;
while (SLOTBUSY(conn,PRIVDATA(conn)-priv_nexttrn))
@@ -1121,7 +1121,7 @@
if (PRIVDATA(conn)-unacked (current_time
(PRIVDATA(conn)-check_time + 30))) {
PRIVDATA(conn)-check_time = current_time;
- for (i = 0; i EMI2_MAX_TRN; i++) {
+ for (i = 0; i PRIVDATA(conn)-window; i++) {
if (SLOTBUSY(conn,i)
PRIVDATA(conn)-slots[i].sendtime (current_time -
PRIVDATA(conn)-waitack)) {
PRIVDATA(conn)-slots[i].sendtime = 0;
Fwd: Re: CVS SMPP Optional parameters
Hi Any resolution on this one yet? It would be really usefull, but in its current form I would vote for it to be removed, as it is causing problems in the CVS. Nisan Date: Mon, 18 Nov 2002 19:56:10 +0200 To: Stipe Tolj [EMAIL PROTECTED] From: Nisan Bloch [EMAIL PROTECTED] Subject: Re: CVS SMPP Optional parameters Cc: [EMAIL PROTECTED] Hi Stipe We are experiencing problems with the current cvs with the optional smpp parameters. Here is a debug log. I will try look into it further, but seen as you have just done this code it may be quicker for u to look. 2002-11-18 14:10:40 [0] INFO: Kannel bearerbox II version cvs- starting 2002-11-18 14:10:40 [0] INFO: MAIN: Start-up done, entering mainloop 2002-11-18 14:10:40 [7] DEBUG: sms_router: time to sleep 2002-11-18 14:10:40 [7] DEBUG: sms_router: list_len = 0 2002-11-18 14:10:40 [6] DEBUG: SMPP[log1]: Sending PDU: 2002-11-18 14:10:40 [6] DEBUG: SMPP PDU 0x912c968 dump: 2002-11-18 14:10:40 [6] DEBUG: type_name: bind_receiver 2002-11-18 14:10:40 [6] DEBUG: command_id: 1 = 0x0001 2002-11-18 14:10:40 [6] DEBUG: command_status: 0 = 0x 2002-11-18 14:10:40 [6] DEBUG: sequence_number: 0 = 0x 2002-11-18 14:10:40 [6] DEBUG: system_id: 2002-11-18 14:10:40 [6] DEBUG: password: 2002-11-18 14:10:40 [6] DEBUG: system_type: 2002-11-18 14:10:40 [6] DEBUG: interface_version: 52 = 0x0034 2002-11-18 14:10:40 [6] DEBUG: addr_ton: 0 = 0x 2002-11-18 14:10:40 [6] DEBUG: addr_npi: 0 = 0x 2002-11-18 14:10:40 [6] DEBUG: address_range: 2002-11-18 14:10:40 [6] DEBUG: SMPP PDU dump ends. 2002-11-18 14:10:41 [5] DEBUG: SMPP[log1]: Sending PDU: 2002-11-18 14:10:41 [5] DEBUG: SMPP PDU 0x912caa0 dump: 2002-11-18 14:10:41 [5] DEBUG: type_name: bind_transmitter 2002-11-18 14:10:41 [5] DEBUG: command_id: 2 = 0x0002 2002-11-18 14:10:41 [5] DEBUG: command_status: 0 = 0x 2002-11-18 14:10:41 [5] DEBUG: sequence_number: 1 = 0x0001 2002-11-18 14:10:41 [5] DEBUG: system_id: 2002-11-18 14:10:41 [5] DEBUG: password: 2002-11-18 14:10:41 [5] DEBUG: system_type: 2002-11-18 14:10:41 [5] DEBUG: interface_version: 52 = 0x0034 2002-11-18 14:10:41 [5] DEBUG: addr_ton: 0 = 0x 2002-11-18 14:10:41 [5] DEBUG: addr_npi: 0 = 0x 2002-11-18 14:10:41 [5] DEBUG: address_range: 2002-11-18 14:10:41 [5] DEBUG: SMPP PDU dump ends. 2002-11-18 14:10:41 [6] DEBUG: Optional parameter length read as 0 2002-11-18 14:10:41 [6] DEBUG: Optional parameter length read as -1 2002-11-18 14:10:41 [6] PANIC: gwlib/octstr.c:275: octstr_copy_real: Assertion `len = 0' failed. Nisan
[PATCH] EMI part 2
Hi This patch to the EMI module tries to address the problem of dealing with msgs that do not get acked by the SMSC after the wait-ack period. This should never happen but it does, even with wait-acks in the region of 240-600secs. Thanks to Andreas for his input. It adds a new config var (wait-ack-expire) that defines what to do with such an error. After some discussion between Andreas and I, we decided that a disconnect/reconnect should be the default behavior. The various option for wait-ack-expire are 0x00 - disconnect/reconnect, (default) 0x01 - as is now, requeue, but this could potentially result in the msg arriving twice 0x02 - just carry on waiting (given that the wait-ack should never expire this is the mst accurate) I have submitted this patch distinctly different from the patch to handle the window problem to make voting and testing easier. I have tested it a fair amount, but I think it needs some more. Nisan smsc_emi2.patch Description: Binary data
Re: SMPP getting stuck
Hi Yup we have. This is what happens when you send above the throughput allowed by the SMSC you are connecting to for your account. 0x58 is SMPP_ESME_RTHROTTLED We have also seen SMPP_ESME_RMSGQFUL comming in on a generic_nack_resp. Our smsc module is modified for this. Basically we have added generic_nack_response pdu handler, which reques the message. I can submit patches if you are interested. Nisan At 08:02 AM 12/5/02 +0100, Andreas Fink wrote: Anyone seen this: 2002-12-05 06:57:53 [10] DEBUG: SMPP[link5]: Got PDU: 2002-12-05 06:57:53 [10] DEBUG: SMPP PDU 0x814fdc8 dump: 2002-12-05 06:57:53 [10] DEBUG: type_name: generic_nack_resp 2002-12-05 06:57:53 [10] DEBUG: command_id: 2147483648 = 0x8000 2002-12-05 06:57:53 [10] DEBUG: command_status: 88 = 0x0058 2002-12-05 06:57:53 [10] DEBUG: sequence_number: 31 = 0x001f 2002-12-05 06:57:53 [10] DEBUG: SMPP PDU dump ends. 2002-12-05 06:57:53 [10] ERROR: SMPP[link5]: Unknown PDU type 0x8000, ignored. This happens under high load on a SMPP link to a SMSC. after that the link is more or less stuck. Only restarting helps dequeuing messages again. Andreas Fink Fink Consulting GmbH --- Tel: +41-61-332 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com --- /blockquote/x-html
Re: SMPP getting stuck
Hi
At 11:10 AM 12/5/02 +0100, Andreas Fink wrote:
I've fixed the problem in CVS.
the implementation didnt expect to see an error as generic_err_resp but
only as sms_submit_resp
the error was a THROTTLING.
Our soln is basically the same but with some minor differences..
Primarily we remove the message for sequence_number from the dictionary
(first), also we check for SMPP_ESME_RMSGQFUL. I removed the msg first
before checking the command_status, because it may be an
unknown/unhandled status, and then the message would remain in the
dictionary. This would slowly eat away at mem.
case generic_nack_resp:
os =
octstr_format(%ld,
pdu-u.generic_nack_resp.sequence_number);
msg =
dict_remove(smpp-sent_msgs, os);
octstr_destroy(os);
if
(msg == NULL) {
warning(0, SMPP[%s]: SMSC sent generic_nack_resp
with wrong sequence number 0x%08lx,
octstr_get_cstr(smpp-conn-id),
pdu-u.generic_nack_resp.sequence_number);
}
else if ((pdu-u.generic_nack_resp.command_status ==
SMPP_ESME_RTHROTTLED) ||
(pdu-u.generic_nack_resp.command_status == SMPP_ESME_RMSGQFUL))
{
info(0,SMPP[%s]: ESME_RTHROTTLED/ESME_RMSGQFUL: status 0x%08lx
,
octstr_get_cstr(smpp-conn-id),pdu-u.generic_nack_resp.command_status);
time((smpp-throttling_err_time));
reason = smpp_status_to_smscconn_failure_reason(
pdu-u.generic_nack_resp.command_status);
bb_smscconn_send_failed(smpp-conn, msg, reason);
--(*pending_submits);
} else
{
error(0, SMPP[%s]: NACK PDU type 0x%08lx, code
0x%08lx.,
octstr_get_cstr(smpp-conn-id), pdu-type,
pdu-u.generic_nack_resp.command_status);
reason = smpp_status_to_smscconn_failure_reason(-1);
bb_smscconn_send_failed(smpp-conn, msg, reason);
--(*pending_submits);
}
break;
Nisan
RE: [PATCH] http.c
Hi Michael
yup, thats it exactly, and this causes havoc, under load with delivery acks
or many MO messages.
Nisan
At 03:53 PM 12/3/02 +, Michael Mulcahy wrote:
The problem is with the calling of parse_url in the code.
parse_url is called twice when a http request is being made.
It is the second call that causes the leak.
the write_request_thread function invokes get_connection, this calls
parse_url and populates the trans-host field.
then write_request_thread invokes send_request, this calls parse_url
again
and populates the trans-host fields.
However send_request does not destroy the trans-host that has already been
allocated.
cheers,
michael.
ANAM Wireless Internet Solutions
http://www.anam.com mailto:[EMAIL PROTECTED]
+353 1 284 7555
Castle Yard, Saint Patrick's Road, Dalkey, County Dublin, Ireland
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Stipe Tolj
Sent: 03 December 2002 14:25
To: Nisan Bloch
Cc: [EMAIL PROTECTED]
Subject: Re: [PATCH] http.c
the check for != NULL is not necessary, yes. But the
octstr_destroy is, as
in http.c:parse_url:1155 , host is created.
*host = octstr_copy(url, prefix_len, host_len);
but the host is inside the HTTPServe trans structure, it should be
free'ed there, see gwlib/http.c:616:
static void server_destroy(void *p)
{
HTTPServer *trans;
trans = p;
octstr_destroy(trans-url);
http_destroy_headers(trans-request_headers);
trans-request_headers = NULL;
octstr_destroy(trans-request_body);
entity_destroy(trans-response);
octstr_destroy(trans-host);
gw_free(trans);
}
and the previous server_create() garantees that the -host is NULLed.
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
[PATCH] http.c
Hi small memory leak in http.c, --- gwlib/http.cMon Nov 18 08:02:13 2002 +++ ../../gateway-cvsup/gwlib/http.cMon Nov 25 11:45:50 2002 @@ -1226,6 +1226,10 @@ path = NULL; request = NULL; + if (trans-host != NULL) + octstr_destroy(trans-host); + trans-host = NULL; + if (parse_url(trans-url, trans-host, trans-port, path, trans-ssl, trans-username, trans-password) == -1) Nisan
[PATCH] mem leak bb_smscconn
Hi
another small mem leak
--- cvs/gw/bb_smscconn.cThu Nov 28 13:22:30 2002
+++ cvsup/gw/bb_smscconn.c Mon Dec 2 23:36:32 2002
@@ -423,7 +423,7 @@
{
CfgGroup *grp;
SMSCConn *conn;
-Octstr *smscid;
+Octstr *smscid = NULL;
int i;
/* find the specific smsc via id */
@@ -466,6 +466,7 @@
list_append(smsc_list, conn);
smscconn_start(conn);
+ octstr_destroy(smscid);
if (router_thread = 0)
gwthread_wakeup(router_thread);
Nisan
Re: [PATCH] http.c
Hi At 01:15 AM 12/3/02 +0100, Stipe Tolj wrote: small memory leak in http.c, --- gwlib/http.cMon Nov 18 08:02:13 2002 +++ ../../gateway-cvsup/gwlib/http.cMon Nov 25 11:45:50 2002 @@ -1226,6 +1226,10 @@ path = NULL; request = NULL; + if (trans-host != NULL) + octstr_destroy(trans-host); + trans-host = NULL; + if (parse_url(trans-url, trans-host, trans-port, path, trans-ssl, trans-username, trans-password) == -1) I don't think this is necessary, see gwlib/octstr.c:244: the check for != NULL is not necessary, yes. But the octstr_destroy is, as in http.c:parse_url:1155 , host is created. *host = octstr_copy(url, prefix_len, host_len); Nisan
Re: EMI/UCP bug
Hi Andreas Did you get any further on this one? Nisan At 08:06 AM 10/23/02 +0200, you wrote: There's a bug in EMI which shows up under the following conditions: a) Kannel is under heavy load. b) the throughput of the EMI/UCP smsc is limited to a low value The effect occurs like this: The EMI/UCP SMSC does throttle to enforce the speed limitations. So the ACK's/NACK's will not come in immediately but a bit later. For example if you have 5 messages a seconds set up, the EMI/UCP SMSC will take 200msg to get you the ACK/NACK. Now Kannel does send additional packets down the same pipe because of windowing. And they get delayed even further. The problem starts when those cumulated delays become larger than 60 seconds (or whatever timeout you define). Then Kannel presumes your SMS didnt get there and sends it again. Usually it was getting there but no ACK/NACk was received yet due to enforced speed limit of the SMSC. So the result of all this is SMS duplications in masses. There's a speed limit factor in Kannel which lets it wait after a submission a certain time. However this one doesn't work because new incoming SMS on bearerbox do wake up the thread to continue. This is relatively easy to fix. But ther's another issue. Windowing. Usually if you set windowing to 4 or similar value, kannel should not submit more than 4 outstanding messages and then wait for ACK/NACK. In this scenario, Kannel should never ever get to the point where the ACK/NACK's cumulate to values above 60 seconds but only to 4x the throughput delay, in our 5msg/sec example with windowing set to 4 that would be 0.8s. So there's definitively something wrong. We have seen this problem in our setup and I've heard from other Kannel users having similar problems with other SMSC's from other carriers. I will look into this bug more seriously now. If anyone has a few good hints, let me know. Andreas Fink Global Networks, Inc. -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association /blockquote/x-html
Re: repost: [PATCH] SMPP: data_coding (deliver_sm) votes?!
Hi At 12:57 PM 11/24/02 +0100, Andreas Fink wrote: We don't, well the smpp driver doesn't - that's the whole point of this patch. In the case where the data coding is set to SMSC default (0x00) - the smpp driver doesn't know what decoding to do. Well the spec says that its GSM character set. actually not, quote from smpp 3.4 specs 5.2.19 data_coding Bits 7 6 5 4 3 2 1 0 Meaning Notes 0 0 0 0 0 0 0 0 SMSC Default Alphabet But no mention of what the default alphabet of the smsc ought tio be. nisan
Re: [BUG] smsc stop start
Hi At 03:57 PM 11/20/02 +0100, Stipe Tolj wrote: If we store the smsc as submitted in the original request from smsbox, it would be stored as link1 but the incoming sms would still be link1a..c so the only way would be to have another name in the DLR code for grouping SMSC links together for DLR's. Another parameter? I would like to avoid this. yep, me too. ditto.. I gave this some thought, and dont like the idea of yet another parameter, but it may be needed. We thought of a symbolic name for each link that is only used for the stop/start and maybe in the status page. This way the smsc-id routing can stay as is. Hmmm, let's think about if we can solve this on another way... We could however put an extra element into the smscconn structure to uniquely id a particular link, and then get bearerbox to generate a HTML page that can be used to stop and start SMSC links. The disadvantage of this is that one will have to use the admin page to stop and start links, rather than been able to automate or script it. We may still have the problem of identifying the equivalent links on this page. We like Andreas have parallel links to the same provider, with dlrs comming in on any of the links and not necessary the one the message was sent out on. Nisan
Re: repost: [PATCH] SMPP: data_coding (deliver_sm) votes?!
At 03:55 PM 11/20/02 +0100, you Andreas Fink: On Mittwoch, November 20, 2002, at 03:42 Uhr, Stipe Tolj wrote: Oded Arbel wrote: This patch was originated from m-Wise code, so I'm not sure I'm allowed to vote on it.. but if for nothing else, at least it introduces iconv into Kannel - which I think is mighty useful. except that, all I can say is works for me(tm). ok, let's interpret this as +1 :) My main concern is what the developers thing of having another hard-wired dependency to third-party software, iconv in this case. standard libxml bails if iconv is not there. I did run into that problem on earlier MacOS X systems (10.2 and newer is ok) However you can get around this by doing ./configure --without-iconv when you compile libxml. It probably has some replacement function. Now to the stupid question. What is iconv doing at all and why do we need it? Also if libxml has a replacement function for systems which dont have it, can we simply rely on libxml for solving it for us? I dont think so.. We ended up using it for a proprietary SMSC we connect to. Libxml's replacement functions seem only to handle character encodings needed for XML. Libiconv is also pretty std on most systems I have worked with. Iconv supports many charsets, so another advantage of using it is we have support for charsets that are not yet required or have not been encountered by the list yet. I vote +1 for rolling this patch. We allready use it and it works for us, and its a real pain to keep our source base up to date when there are these differences. Nisan
Re: [BUG] smsc stop start
At 08:02 PM 11/20/02 +0100, Andreas Fink wrote: how about simply numbering the SMSC's? or do something like smsc=link1 start/stops all link1 links smsc=5 start/stops the 5th link smsc=link1:1start/stops the 1st link of the group link1 I like this.. We could alter the status page to display a link number. Small change though smsc=link1 start/stops all link1 links smsc=link1:1 start/stops the 1st link of the group link1 smsc-no=5 start/stops the 5th link Otherwise smsc-ids that are a numeric (silly, but it may happen), will cause problems. We should think about getting the stop /start to reload the config file for that link. This way we can change the configuration and simply stop/start that link, rahter than bouncing Kannel. Nisan Nisan
Re: [FYI] smsbox routing patch commited
At 08:48 PM 11/19/02 +0100, Stipe Tolj wrote: Hmm, ok, trying to sum things up here: The error results in gw/bb_boxc.c:route_incoming_sms() and if msg-sms.boxc_id != NULL. This means the boxc_id has been set. Hmm, but if your smsbox does not identify to bearerbox, why does specific smsc module sets the boxc_id?! yup.. and remember there are no smsbox-id and no smsbox-route group in the config Are you using dlr via internal memory or mysql?! If you use mysql, please check what the boxc_id entry is saying. mysql.. most the entries are blank and some are (null), which could have to do with some of the octstr patches? Interesting issue, can you provide more information? AFAIK, this should not happen. not much more.. it doesnt really affect things, but is annoying ;-) nisan 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: [FYI] smsbox routing patch commited
Hi Stipe There is a small problem in the smsbox routing patch. I have a configuration as before your patch. i.e. no smsbox-id and no smsbox-route group. When smsbox receives a dlr notification from bbox we get the following error. The dlrurl still gets called however. 2002-11-18 14:45:38 [5] DEBUG: Found entry, row[0]=31, row[1]=, row[2]=http://newsite.clickatell.com:13303/test_dlr?from=%PapiMsgId=XXtext=Result:%d,SMSC:%i,Text:%A, row[3]=tester, row[4]=(null) 2002-11-18 14:45:38 [5] DEBUG: created DLR message for URL http://newsite.clickatell.com:13303/test_dlr?from=%PapiMsgId=XXtext=Result:%d,SMSC:%i,Text:%A 2002-11-18 14:45:38 [5] DEBUG: DLR not deleted because we wait on more reports 2002-11-18 14:45:38 [5] ERROR: Could not route message to smsbox id (null), smsbox is gone! Smsboxes are running just fine.. they are definately there ;-) Nisan Nisan
Re: CVS SMPP Optional parameters
Hi Stipe We are experiencing problems with the current cvs with the optional smpp parameters. Here is a debug log. I will try look into it further, but seen as you have just done this code it may be quicker for u to look. 2002-11-18 14:10:40 [0] INFO: Kannel bearerbox II version cvs- starting 2002-11-18 14:10:40 [0] INFO: MAIN: Start-up done, entering mainloop 2002-11-18 14:10:40 [7] DEBUG: sms_router: time to sleep 2002-11-18 14:10:40 [7] DEBUG: sms_router: list_len = 0 2002-11-18 14:10:40 [6] DEBUG: SMPP[log1]: Sending PDU: 2002-11-18 14:10:40 [6] DEBUG: SMPP PDU 0x912c968 dump: 2002-11-18 14:10:40 [6] DEBUG: type_name: bind_receiver 2002-11-18 14:10:40 [6] DEBUG: command_id: 1 = 0x0001 2002-11-18 14:10:40 [6] DEBUG: command_status: 0 = 0x 2002-11-18 14:10:40 [6] DEBUG: sequence_number: 0 = 0x 2002-11-18 14:10:40 [6] DEBUG: system_id: 2002-11-18 14:10:40 [6] DEBUG: password: 2002-11-18 14:10:40 [6] DEBUG: system_type: 2002-11-18 14:10:40 [6] DEBUG: interface_version: 52 = 0x0034 2002-11-18 14:10:40 [6] DEBUG: addr_ton: 0 = 0x 2002-11-18 14:10:40 [6] DEBUG: addr_npi: 0 = 0x 2002-11-18 14:10:40 [6] DEBUG: address_range: 2002-11-18 14:10:40 [6] DEBUG: SMPP PDU dump ends. 2002-11-18 14:10:41 [5] DEBUG: SMPP[log1]: Sending PDU: 2002-11-18 14:10:41 [5] DEBUG: SMPP PDU 0x912caa0 dump: 2002-11-18 14:10:41 [5] DEBUG: type_name: bind_transmitter 2002-11-18 14:10:41 [5] DEBUG: command_id: 2 = 0x0002 2002-11-18 14:10:41 [5] DEBUG: command_status: 0 = 0x 2002-11-18 14:10:41 [5] DEBUG: sequence_number: 1 = 0x0001 2002-11-18 14:10:41 [5] DEBUG: system_id: 2002-11-18 14:10:41 [5] DEBUG: password: 2002-11-18 14:10:41 [5] DEBUG: system_type: 2002-11-18 14:10:41 [5] DEBUG: interface_version: 52 = 0x0034 2002-11-18 14:10:41 [5] DEBUG: addr_ton: 0 = 0x 2002-11-18 14:10:41 [5] DEBUG: addr_npi: 0 = 0x 2002-11-18 14:10:41 [5] DEBUG: address_range: 2002-11-18 14:10:41 [5] DEBUG: SMPP PDU dump ends. 2002-11-18 14:10:41 [6] DEBUG: Optional parameter length read as 0 2002-11-18 14:10:41 [6] DEBUG: Optional parameter length read as -1 2002-11-18 14:10:41 [6] PANIC: gwlib/octstr.c:275: octstr_copy_real: Assertion `len = 0' failed. Nisan
[BUG] smsc stop start
Hi All There is a bug in the smsc stop/start admin interface. Before I fix it, I want to check that the soln we propose will work for the list. The scenario is as follows: Assume you have more than one smsc group with the same smsc-id. eg one provider with 2 different host. Ok when you use the stop-smsc code it stops the first smsc in the list with that smsc-id and not the others. If you then start and stop and start again one ends up with both the links up, but not necessary to the two different hosts. eg.. snips from status page [snip] linka8SMPP:web1.host.com:16252/16252:Clickatell: (online 21s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) linka8SMPP:web2.host.com:26252/26252:Clickatell: (online 24s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) [end snip] [snip] linka8SMPP:web1.host.com:16252/16252:Clickatell: (dead, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) linka8SMPP:web2.host.com:26252/26252:Clickatell: (online 73s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) [end snip] [snip] linka8SMPP:web2.host.com:26252/26252:Clickatell: (online 107s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) linka8SMPP:web1.host.com:16252/16252:Clickatell: (online 1s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) [end snip] [snip] linka8SMPP:web2.host.com:26252/26252:Clickatell: (dead, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) linka8SMPP:web1.host.com:16252/16252:Clickatell: (online 16s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) [end snip] [snip] linka8SMPP:web1.host.com:16252/16252:Clickatell: (online 31s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) linka8SMPP:web1.host.com:16252/16252:Clickatell: (online 1s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) [end snip] I propose that the stop-smsc admin interface should stop ALL smsc links with the given smsc-id, similarly start-smsc should start/restart all smsc links with the given smsc-id In addition there is a new memory leak. For each stop/start we end up with the following 2002-11-18 15:42:45 [0] DEBUG: Allocated by list_create_real at gwlib/list.c:71 2002-11-18 15:42:45 [0] DEBUG: Claimed by smsc2_start at gw/bb_smscconn.c:332 Nisan
[BUG] smsbox memleak
Hi All There is a new memory leak in the cvs, in smsbox. For each dlr ack.. and probabally sms-service 2002-11-18 15:59:11 [0] DEBUG: Allocated by octstr_create_from_data_real at gwlib/octstr.c:185 2002-11-18 15:59:11 [0] DEBUG: Claimed by parse_url at gwlib/http.c:1156 2002-11-18 15:59:11 [0] DEBUG: Contents of area (first 16 bytes): 2002-11-18 15:59:11 [0] DEBUG: 48 5a 0c 09 16 00 00 00 17 00 00 00 00 00 00 00 2002-11-18 15:59:11 [0] DEBUG: Area 0x90c2960, size 16, max_size 16 2002-11-18 15:59:11 [0] DEBUG: Allocated by octstr_create_from_data_real at gwlib/octstr.c:185 2002-11-18 15:59:11 [0] DEBUG: Claimed by parse_url at gwlib/http.c:1156 2002-11-18 15:59:11 [0] DEBUG: Contents of area (first 16 bytes): Nisan
Re: CVS SMPP Optional parameters
At 12:20 AM 11/18/02 +0100, Stipe Tolj wrote: No, the client side (smsc_smpp.c) has yet not been modified by us to use the optional parameters. ok.. i am about to do this to replace our msgpayload patch. Do you have any utils code to get and set the optional parameters in the PDU? Nisan 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: [BUG] smsc stop start
At 08:21 PM 11/18/02 +0100, Andreas Fink wrote: I was thinking of exactly the reverse. How do I stop /start a single link if I have mutiple ones name the same way (for DLR grouping this is required). Maybe we should have the SMSC link be named unique and group them by some other name for DLR processing. mm.. not sure.. we use the smsc-ids for routing (done external to kannel), then within Kannel multiple links with the same smsc-id are balanced by Kannel, or are failovers of each other (connections to the same provider on different ips) - maybe a name for the links that is distinct from the smsc-id? nisan On Montag, November 18, 2002, at 07:05 Uhr, Nisan Bloch wrote: Hi All There is a bug in the smsc stop/start admin interface. Before I fix it, I want to check that the soln we propose will work for the list. The scenario is as follows: Assume you have more than one smsc group with the same smsc-id. eg one provider with 2 different host. Ok when you use the stop-smsc code it stops the first smsc in the list with that smsc-id and not the others. If you then start and stop and start again one ends up with both the links up, but not necessary to the two different hosts. eg.. snips from status page [snip] linka8 SMPP:web1.host.com:16252/16252:Clickatell: (online 21s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) linka8 SMPP:web2.host.com:26252/26252:Clickatell: (online 24s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) [end snip] [snip] linka8 SMPP:web1.host.com:16252/16252:Clickatell: (dead, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) linka8 SMPP:web2.host.com:26252/26252:Clickatell: (online 73s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) [end snip] [snip] linka8 SMPP:web2.host.com:26252/26252:Clickatell: (online 107s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) linka8 SMPP:web1.host.com:16252/16252:Clickatell: (online 1s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) [end snip] [snip] linka8 SMPP:web2.host.com:26252/26252:Clickatell: (dead, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) linka8 SMPP:web1.host.com:16252/16252:Clickatell: (online 16s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) [end snip] [snip] linka8 SMPP:web1.host.com:16252/16252:Clickatell: (online 31s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) linka8 SMPP:web1.host.com:16252/16252:Clickatell: (online 1s, rcvd 0, sent 0, failed 0, queued 0 dlrq 1 msgs) [end snip] I propose that the stop-smsc admin interface should stop ALL smsc links with the given smsc-id, similarly start-smsc should start/restart all smsc links with the given smsc-id In addition there is a new memory leak. For each stop/start we end up with the following 2002-11-18 15:42:45 [0] DEBUG: Allocated by list_create_real at gwlib/list.c:71 2002-11-18 15:42:45 [0] DEBUG: Claimed by smsc2_start at gw/bb_smscconn.c:332 Nisan Andreas Fink Global Networks, Inc. -- Tel: +41-61-333 Fax: +41-61-6932729 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association /blockquote/x-html
[PATCH] admin, sendsms bind to interface
Hi All
Patches to the bb_http.c and smsbox.c to allow the admin and sendsms http
interface to bind to a specified interface.
files patched: gw/smsbox.c, gw/bb_http.c, gwlib/cfg.def
Nisan
--- ../cvs/gateway/gw/smsbox.c Thu Nov 14 12:11:38 2002
+++ ../gateway-cvsup/gw/smsbox.c Sun Nov 17 22:51:45 2002
@@ -44,6 +44,7 @@
static long bb_port;
static int bb_ssl = 0;
static long sendsms_port = 0;
+static Octstr *sendsms_interface = NULL;
static Octstr *smsbox_id = NULL;
static Octstr *sendsms_url = NULL;
static Octstr *sendota_url = NULL;
@@ -2930,6 +2937,7 @@
}
cfg_get_integer(sendsms_port, grp, octstr_imm(sendsms-port));
+ sendsms_interface= cfg_get(grp, octstr_imm(sendsms-interface));
cfg_get_integer(sms_max_length, grp, octstr_imm(sms-length));
#ifdef HAVE_LIBSSL
@@ -2977,7 +2985,7 @@
cfg_get_integer(http_queue_delay, grp, octstr_imm(http-queue-delay));
if (sendsms_port 0) {
- if (http_open_port(sendsms_port, ssl) == -1) {
+ if (http_open_port_if(sendsms_port, ssl,sendsms_interface) == -1) {
if (only_try_http)
error(0, Failed to open HTTP socket, ignoring it);
else
@@ -3111,6 +3119,7 @@
octstr_destroy(reply_requestfailed);
octstr_destroy(reply_couldnotfetch);
octstr_destroy(reply_couldnotrepresent);
+ octstr_destroy(sendsms_interface);
numhash_destroy(black_list);
numhash_destroy(white_list); cfg_destroy(cfg);
--- ../cvs/gateway/gw/bb_http.c Wed Aug 7 21:03:48 2002
+++ ../gateway-cvsup/gw/bb_http.c Sun Nov 17 20:54:04 2002
@@ -24,6 +24,7 @@
static volatile sig_atomic_t httpadmin_running;
static long ha_port;
+static Octstr *ha_interface;
static Octstr *ha_password;
static Octstr *ha_status_pw;
static Octstr *ha_allow_ip;
@@ -364,6 +365,8 @@
if (cfg_get_integer(ha_port, grp, octstr_imm(admin-port)) == -1)
panic(0, Missing admin-port variable, cannot start HTTP admin);
+ ha_interface = cfg_get(grp, octstr_imm(admin-interface));
+
ha_password = cfg_get(grp, octstr_imm(admin-password));
if (ha_password == NULL)
panic(0, You MUST set HTTP admin-password);
@@ -398,7 +401,7 @@
octstr_destroy(ssl_server_key_file);
#endif /* HAVE_LIBSSL */
- http_open_port(ha_port, ssl);
+ http_open_port_if(ha_port, ssl, ha_interface);
if (gwthread_create(httpadmin_run, NULL) == -1)
panic(0, Failed to start a new thread for HTTP admin);
@@ -413,6 +416,7 @@
http_close_all_ports();
gwthread_join_every(httpadmin_run);
octstr_destroy(ha_password);
+ octstr_destroy(ha_interface);
octstr_destroy(ha_status_pw);
octstr_destroy(ha_allow_ip); octstr_destroy(ha_deny_ip);
--- ../cvs/gateway/gwlib/cfg.def Mon Nov 18 08:02:12 2002
+++ ../gateway-cvsup/gwlib/cfg.def Mon Nov 18 11:36:26 2002
@@ -21,6 +21,7 @@
SINGLE_GROUP(core,
OCTSTR(admin-port)
OCTSTR(admin-port-ssl)
+ OCTSTR(admin-interface)
OCTSTR(admin-password)
OCTSTR(status-password)
OCTSTR(admin-deny-ip)
@@ -137,6 +138,7 @@
OCTSTR(bearerbox-host)
OCTSTR(sendsms-port)
OCTSTR(sendsms-port-ssl)
+ OCTSTR(sendsms-interface)
OCTSTR(sendsms-url)
OCTSTR(sendota-url)
OCTSTR(xmlrpc-url)
[PATCH] http server bind to interface
Hi All
a small patch to the http code to allow the http server to bin to a
specified interface.
Nisan
--- cvs/gateway/gwlib/http.cSun Nov 17 11:46:30 2002
+++ gateway-work/gwlib/http.c Sun Nov 17 11:45:51 2002
@@ -1922,7 +1922,7 @@
}
-int http_open_port(int port, int ssl)
+int http_open_port_if(int port, int ssl, Octstr *interface)
{
struct server *p;
@@ -1931,8 +1931,7 @@
p = gw_malloc(sizeof(*p));
p-port = port;
p-ssl = ssl;
-p-fd = make_server_socket(port, NULL);
- /* XXX add interface_name if required */
+p-fd = make_server_socket(port,
interface==NULL?NULL:octstr_get_cstr(interface));
if (p-fd == -1) {
gw_free(p);
return -1;
@@ -1945,6 +1944,11 @@
gwthread_wakeup(server_thread_id);
return 0;
+}
+
+int http_open_port(int port, int ssl)
+{
+return http_open_port_if(port,ssl,NULL);
}
--- cvs/gateway/gwlib/http.hSun Nov 17 11:46:31 2002
+++ gateway-work/gwlib/http.h Sun Nov 17 11:45:51 2002
@@ -272,6 +272,14 @@
* for SSL-enabled connections.
*/
int http_open_port(int port, int ssl);
+
+/*
+ * Same as http_open_port with the addition of specifing the interace
+ * to bind to
+ */
+int http_open_port_if(int port, int ssl, Octstr *interface);
+
+
CVS SMPP Optional parameters
Hi Stipe I see that your implementation of optional parameters in SMPP is not quite complete. The PDU code is done, but I dont see you using it as such in the SMPP module, well at least in the CVS version. Do you have a more recent version of smsc_smpp that does use your mods? Nisan
[PATCH] was Re: SMPP: data_coding (deliver_sm)
Hi any reason why this didnt make it to the cvs? Also why not apply it to the data_coding in submit_sm? nisan At 08:42 PM 11/6/02 +1300, Alan McNatty wrote: Here's Oded's patch against current cvs. Is working fine for me ... On Sat, 2002-11-02 at 11:21, Alan McNatty wrote: In progress - am building a patch against cvs for Oded's posts, and re-post for testign etc ... Thanks again Oded - your patches look great. On Sat, 2002-11-02 at 00:04, Stipe Tolj wrote: remeber guys to have a [PATCH] post to the mailing list if you want to have that in the general cvs tree. Just a reminder. 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 -- Alan McNatty -- Catalyst IT Ltd -- http://www.catalyst.net.nz Level 2, 150-154 Willis St, PO Box 11-053, Wellington, NZ Mob: +64 21-312136, DDI: +64 4 9167203, Office: +64 4 4992267 ... error accessing whit Segmentation fault (core dumped)
Re: [FYI] smsbox routing patch commited
At 03:35 AM 11/14/02 +0100, Stipe Tolj wrote: Hi list, I commited now Wapme's smsbox routing patch to Kannel's cvs HEAD tree. nice! what are the emibox, webbox and milbox groups in cfg.def for? nisan
Re: [PATCH] avoid bearerbox oom-kill (fix)
Hi please re submit this patch as a unified diff, and ignoring changes to white space. This is horrid to read as there are many lines in the diff that are not necessary. nisan At 06:49 PM 11/15/02 +0100, Alexander Malysh wrote: Content-Type: text/plain; charset=iso-8859-15 X-MIME-Autoconverted: from 8bit to quoted-printable by mail-in-01.piro.net id SAA23798 Hi, this is the same oom-kill patch with memleak bugfix. -- Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 150 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de
Re: incoming originator on SMPP
Hi
surely just not setting my-number in the config will sort that
out.
Nisan
At 11:46 AM 11/13/02 +0100, Andreas Fink wrote:
scenario:
you have
global-sender = 123
so all your outgoing SMS which dont have from=... set will be from
123
you got one SMPP link. no my-number stuff defined.
you get an incoming SMS from that SMPP link and it will be always
to 123 even the sender might have used another short ID.
The problem seems to come from gw/smsc/smsc_smpp.c line 738ff
/* Replace MO destination number with my-number */
if (octstr_len(smpp-my_number)) {
octstr_destroy(msg-sms.receiver);
msg-sms.receiver = octstr_duplicate(smpp-my_number);
}
Removing this, makes it work. However its supposed to be there for a
particular reason.
whats the best way to fix this?
Andreas Fink
Global Networks, Inc.
--
Tel: +41-61-333 Fax: +41-61-6932729 Mobile:
+41-79-2457333
Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland
Web:
http://www.global-networks.ch/
[EMAIL PROTECTED]
--
Member of the GSM Association
/blockquote/x-html
Re: delivery reports and EMI [known bug issue]
Hi snips from all the postings At 07:59 AM 11/13/02 +0100, Andreas Fink wrote: We have a work around, which is a bit hacky but works for us. We use the 8 right most digits of the number to match the DLR in the db/store. That would not be good enough in most cases. why? given that there is a timestamp and destination in the dlr tables. one would need multiple messages in quick succession, within 1 second to the same nmber, to end up with a clash. This is not ideal but works in most cases. My approach would simply to specify international and national prefixes and country codes on the SMSC link. I am not convinced that we can make a unified prefix work in all cases, and allow us to still have applications routing dynamically to Kannel. I have seen quite diverse numbers comming back from some EMI connections. It might also make the Kannel configs quite messy if one has many international and national prefixes and country codes on one SMSC link. Upstream providers also tend to change coverage patterns quite regularly and this would mean restarting Kannel. This would also help on the sending side where a + currently is replaced hardcoded with 00 which is not really always true. The unified-prefix on an SMSC basis can be used to overcome this. I have a small patch for EMI2 module to do this. I agree on this but a delivery of the first message makes it very likely that the second message gets delivered too. So you would expect to have two identical deliveries or failures. Not so.. The destination network may bar multiple quick submission of messages from the same src to the same destination, the SIM may become full etc.. Nisan
Re: delivery reports and EMI [known bug issue]
At 08:38 PM 11/13/02 +0100, Andreas Fink wrote: On Mittwoch, November 13, 2002, at 08:25 Uhr, Nisan Bloch wrote: Hi snips from all the postings At 07:59 AM 11/13/02 +0100, Andreas Fink wrote: We have a work around, which is a bit hacky but works for us. We use the 8 right most digits of the number to match the DLR in the db/store. That would not be good enough in most cases. why? given that there is a timestamp and destination in the dlr tables. one would need multiple messages in quick succession, within 1 second to the same nmber, to end up with a clash. This is not ideal but works in most cases. Ok. lets at least add the last 8 digits of the phone number to the timestamp to make it unique. I think thats a good compromize which solves 99.9% of the problems. Stipe, got your patch ready or shall I upgrade cvs? the way we did it is not to add the 8 digits to the timestamp, but to have an alternative to the dlr_find_mysql function that uses the 8 digits from the dest in the SQL select. I am not using the latest CVS, so still have the older dlr functionality, but I can send u the relevant cuts from the code. nisan
Re: incoming originator on SMPP
At 08:38 PM 11/13/02 +0100, Andreas Fink wrote: On Mittwoch, November 13, 2002, at 08:27 Uhr, Nisan Bloch wrote: Hi surely just not setting my-number in the config will sort that out. thats just the point. I have NOT set it. The only thing set was global-sender and that has to be there for outgoing messages without from... aah..yes i see..but then i dont understand the problem. The code you mention removing wont have any affect if the my-number config is not set. Nisan
Re: delivery reports and EMI [known bug issue]
Hi At 12:22 AM 11/13/02 +0100, Andreas Fink wrote: Does anyone has some brilliant ideas how we can solve this always unify the number format for EMI without making configuration of the SMSC a nightmare of config variables? Should we simply replace incoming number with 0 with 00+ country code? But whats the country code - config variable again? config vars wont work as u dont know what the country is as one emi connection may send to many destinations. We have a work around, which is a bit hacky but works for us. We use the 8 right most digits of the number to match the DLR in the db/store. nisan Andreas Fink Fink-Consulting -- Tel: +41-61-332 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink /blockquote/x-html
RE: SMPP: data_coding (deliver_sm)
Hi I would vote +1 for this to be rolled into CVS. We have somethng similar but it is not as general nor as complete. Nisan At 01:24 PM 10/31/02 +0200, Oded Arbel wrote: -Original Message- From: Alan McNatty [mailto:alan;catalyst.net.nz] ok - my mistake, according to the specs, it should be if ( pdu-u.deliver_sm.data_coding == 0x00 ) charset_gsm_to_latin1(msg-sms.msgdata); yes - I'm aware that this does not solve your problem, but SMPP servers send GSM 7 bit alphabet encoded messages using data_coding 0x00. Yes - this is what I thought. What's your opionion on having an additional config directive stating what the SMSC default alphabet. I don't know how in the world anyone is suppost to know in advance what the SMSC default alphabet is... ie: default_alphabet = 0x01 I hate putting in more configuration paremeters. how about this rewrite of data_coding handling (see attached patch file). a similar version is running on our system for about half a year now, I only now had the incentive to generalize it, but I changed some stuff, to treat this code as untested. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Let's suppose you have a table with 2^n cups... Wait a second - is n a natural number?
Re: SMPP Limitation
Hi We have seen providers who do this if the messages are all to the same MSISDN. Also I have run across a bunch who claimed to have an SMPP server, except that it wasnt asynchronous, and one has to wait for a submit_sm_resp before sending the next message, but this is not correct according to the SMPP specs. nisan At 08:33 PM 10/28/02 +0500, Cipher Strength wrote: HI all, MY SMSC provider told me that. In SMPP there is no windowing support. After sending a message my application should give delay for 15 seconds. In which acknolgdment will be received , before sending another message otherwise the first message will be discarded( not sent to mobile). Is there really such with SMPP. I have doubts cause this can make SMPP slow Kindly comment on that CIPHER _ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp
RE: Message retry and backoff
Hi
At 09:40 AM 10/23/02 +0200, you wrote:
Everytime.
that is - everytime the driver returns a message to the bearerbox with a
non-terminal error. otherwise the message is discarded
anyway.
I can think of one place where this might mess things up, but it is
external to Kannel. Kannelers might be have written apps that will resend
certain messages on certain error conditions. If the backoff and retry is
configurable, it could be disabled in Kannel allowing the apps to handle
this.
The other comment I have without having seen the code, is that it might
be usefull to use the dlr mechanism to notify smsbox and hence external
apps of this.
Anychance of posting the code as it is so far?
Nisan
--
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]
+972-9-9581711 (116)
+972-67-340014
::..
Excellent day for putting Slinkies on an escalator.
-Original Message-
From: Nisan Bloch
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 22, 2002 10:48 PM
To: Oded Arbel; Kannel-devel (E-mail)
Subject: Re: Message retry and backoff
hi
sounds good.. Under what conditions do you retry?
Nisan
At 04:13 PM 10/22/02 +0200, Oded Arbel
wrote:
Hi list.
we added a patch to Kannel to enable message retry and backoff. it
was quite simple really, but I'm pretty sure it can mess things up, so I
would like to get suggestions as to how to properly handle this . it goes
something like this :
- we add to the message structure to integers, retry and
delay.
- whenever smscconn_send() is called on a message, and before it
stores that message in the driver's queue it will increment the retry
field by one, and add to the delay field a configured number of seconds
(we set it currently to 60) times the number of retries (this achieving
the backoff effect).
- sms_router(), before calling smsc_rout() we do this
:
snip
if (msg-sms.retry
BB_SMSCCONN_MAX_RETRY) {
warning(2, Message has too many retries - consider it a
failure);
bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED);
ret = 0;
continue;
}
if (msg-sms.delay +
msg-sms.time time(NULL)) {
debug(bb.sms, 0, Message is delayed - will send later,
message retries %d, msg-sms.retry);
list_produce(outgoing_sms, msg);
ret = 0;
continue;
}
/snip
the ret=0 emmulates the effect of smsc_rout() returning after not
founding any available drivers.
comments please ?
--
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]
+972-9-9581711 (116)
+972-67-340014
::..
-- Pulchritude possesses solely cutaneous
profundity.
Re: Message retry and backoff
hi
sounds good.. Under what conditions do you retry?
Nisan
At 04:13 PM 10/22/02 +0200, Oded Arbel wrote:
Hi
list.
we added a patch to Kannel to enable message
retry and backoff. it was quite simple really, but I'm pretty sure it can
mess things up, so I would like to get suggestions as to how to properly
handle this . it goes something like this :
- we add to the message structure to integers,
retry and delay.
- whenever smscconn_send() is called on a
message, and before it stores that message in the driver's queue it will
increment the retry field by one, and add to the delay field a configured
number of seconds (we set it currently to 60) times the number of retries
(this achieving the backoff effect).
- sms_router(), before calling smsc_rout() we
do this :
snip
if
(msg-sms.retry BB_SMSCCONN_MAX_RETRY) {
warning(2, Message has too many retries - consider it a
failure);
bb_smscconn_send_failed(NULL, msg, SMSCCONN_FAILED_DISCARDED);
ret = 0;
continue;
}
if
(msg-sms.delay + msg-sms.time time(NULL)) {
debug(bb.sms, 0, Message is delayed - will send later,
message retries %d, msg-sms.retry);
list_produce(outgoing_sms, msg);
ret = 0;
continue;
}
/snip
the ret=0 emmulates the effect of smsc_rout()
returning after not founding any available drivers.
comments please ?
--
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]
+972-9-9581711 (116)
+972-67-340014
::..
-- Pulchritude possesses solely cutaneous
profundity.
Re: SMPP SMS-MO broken
Hi At 09:23 AM 10/21/02 +0200, Andreas Fink wrote: yup - this is smpp 3.4. Your dump shows an optional parameter tag 04 24 which is the msg_payload parameter. We have a hack where I have added the following into smpp_pdu.def OPT_INTEGER(id_1, 2) OPT_INTEGER(len_1,2) OPT_OCTETS(data_1, len_1) OPT_INTEGER(id_2, 2) OPT_INTEGER(len_2,2) OPT_OCTETS(data_2, len_1) OPT_INTEGER(id_3, 2) OPT_INTEGER(len_3,2) OPT_OCTETS(data_3, len_1) Then in smpp_pdu_unpack we check for these. It wont allways work, it will depend on which other optional params are used by the SMSC. We almost need an array type in the def file to handle this properly. With most SMSCs using ver 3.3 will solve this. We however have one that only talks 3.4 Nisan There seems to be a problem in the SMPP module. I have a connection to an SMSC which should deliver me incoming SMS but instead I always get messages with no content. I've added an octstr dump to see the original SMPP PDU as raw data and found that the text is very well received but not correctly decoded apparently. The test message contained the word TEST Here's what I see: The PDU dump in binary 2002-10-21 09:13:45 [6] DEBUG: SMPP PDU dump ends. 2002-10-21 09:14:04 [6] DEBUG: Octet string at 0x80d9038: 2002-10-21 09:14:04 [6] DEBUG: len: 53 2002-10-21 09:14:04 [6] DEBUG: size: 54 2002-10-21 09:14:04 [6] DEBUG: immutable: 0 2002-10-21 09:14:04 [6] DEBUG: data: 00 00 00 05 00 00 00 00 2002-10-21 09:14:04 [6] DEBUG: data: 00 00 00 01 00 01 01 39 ...9 2002-10-21 09:14:04 [6] DEBUG: data: 37 31 35 30 34 39 32 30 71504920 2002-10-21 09:14:04 [6] DEBUG: data: 39 35 38 00 03 09 39 37 958...97 2002-10-21 09:14:04 [6] DEBUG: data: 38 33 00 00 00 00 00 00 83.. 2002-10-21 09:14:04 [6] DEBUG: data: 01 00 00 00 00 04 24 00 ..$. 2002-10-21 09:14:04 [6] DEBUG: data: 04 54 45 53 54 .TEST 2002-10-21 09:14:04 [6] DEBUG: Octet string dump ends. The PDU dump after decoding 2002-10-21 09:14:04 [6] DEBUG: SMPP[link5]: Got PDU: 2002-10-21 09:14:04 [6] DEBUG: SMPP PDU 0x80d9038 dump: 2002-10-21 09:14:04 [6] DEBUG: type_name: deliver_sm 2002-10-21 09:14:04 [6] DEBUG: command_id: 5 = 0x0005 2002-10-21 09:14:04 [6] DEBUG: command_status: 0 = 0x 2002-10-21 09:14:04 [6] DEBUG: sequence_number: 1 = 0x0001 2002-10-21 09:14:04 [6] DEBUG: service_type: NULL 2002-10-21 09:14:04 [6] DEBUG: source_addr_ton: 1 = 0x0001 2002-10-21 09:14:04 [6] DEBUG: source_addr_npi: 1 = 0x0001 2002-10-21 09:14:04 [6] DEBUG: source_addr: 971504920958 2002-10-21 09:14:04 [6] DEBUG: dest_addr_ton: 3 = 0x0003 2002-10-21 09:14:04 [6] DEBUG: dest_addr_npi: 9 = 0x0009 2002-10-21 09:14:04 [6] DEBUG: destination_addr: 9783 2002-10-21 09:14:04 [6] DEBUG: esm_class: 0 = 0x 2002-10-21 09:14:04 [6] DEBUG: protocol_id: 0 = 0x 2002-10-21 09:14:04 [6] DEBUG: priority_flag: 0 = 0x 2002-10-21 09:14:04 [6] DEBUG: schedule_delivery_time: NULL 2002-10-21 09:14:04 [6] DEBUG: validity_period: NULL 2002-10-21 09:14:04 [6] DEBUG: registered_delivery: 1 = 0x0001 2002-10-21 09:14:04 [6] DEBUG: replace_if_present_flag: 0 = 0x 2002-10-21 09:14:04 [6] DEBUG: data_coding: 0 = 0x 2002-10-21 09:14:04 [6] DEBUG: sm_default_msg_id: 0 = 0x 2002-10-21 09:14:04 [6] DEBUG: sm_length: 0 = 0x 2002-10-21 09:14:04 [6] DEBUG: short_message: 2002-10-21 09:14:04 [6] DEBUG: SMPP PDU dump ends. 2002-10-21 09:14:04 [6] DEBUG: SMPP[link5]: Sending PDU: Anyone have seen this before? Andreas Fink Global Networks, Inc. -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association /blockquote/x-html
Re: [RFY] rolling 1.2.1 tarball?!
At 10:45 AM 10/17/02 +0200, Stipe Tolj wrote: Hi, anyone complaints about rolling now the stable 1.2.1 tarball out of cvs head branch?! +1 from me... Nisan Afterwards we'd apply several (more or less huge) patches, like Igor's WTP-SAR patch and my smsbox-routing patch. Ohhh, yeah, what about Stefan Cars' cimd2 patch? Anyone reviewed the code and tested? 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: access.log
Hi Another way is to write a front end application to Kannel, that you use to submit messages to Kannel. Then you can use Kannels DLR mechanism to callback to your app. This way you can trace the messages and log them into a database. We do this quite effectively. Nisan At 10:22 PM 10/17/02 +1300, Alan McNatty wrote: One thing you could try is writing a (daemon) script in perl that tails the access log and acts on occurances (ie: load them into a database, report errors, etc). Useful for monitoring when logcheck isn't enough - might work for you although might have it limits if volumes are high. I can supply you with a simple example if you wish. On Thu, 2002-10-17 at 22:00, Andy Elacion, Jr. wrote: Andy Elacion, Jr. schrieb: There are times that our subscriber would like to verify their transactions and we have hard time in doing this. We do it manually like grep the accesslog for a particular cell no and it give us a pain. Another thing is to monitor the reply of our system. hehe, we know about that ;) hehehe. A MySQL support for logging may be added in the future. But to be honest I'm more interested in getting a Kannel module API done before embedding to much individual external software support into it. We'll wait for this feature in the future release. You may import the file access.log by perl script to MySQL engine and query on that data then?! We do this also but, we were late by 1 day. We don't have an application that will do this like, online. We really appreciate any pointers/web site that you could recommend. Thanks, Andy 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 -- Alan McNatty -- Catalyst IT Ltd -- http://www.catalyst.net.nz Level 2, 150-154 Willis St, PO Box 11-053, Wellington, NZ Mob: +64 21-312136, DDI: +64 4 9167203, Office: +64 4 4992267 ... error accessing whit Segmentation fault (core dumped)
Re: [RFC] SMPP TON detection
At 12:29 PM 10/16/02 +0200, Stipe Tolj wrote: how about a smsc group directive like this: group = smsc smsc = smpp autodetect-ton-npi = yes ... +1 nisan which means if this boolean directive is set, the smpp module will (for this smpp link only) do the autodetection and corresponding settings of the ton and npi values. (default would be off). Mainly this is then what we already have. Hmmm, currently (if no forcing is configured) the smpp module assumes ton = 0 and npi = 1. We at Wapme here almost use only ton = 1, npi = 1 in our smsc connections. So if we force to ton = 1, npi = 1 for the normal way, we do have an individual default per smsc. If autodetect-ton-npi is on it will afterwards detect and set ton, npi accordingly, I guess this would be a good solution?! 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: [PATCH] Chararcter @ in SMPP
Hi At 11:43 AM 10/2/02 +0700, you wrote: I d like to propose patch to fix problem with character @ in SMPP. vote -2 .. no ways .. the mapping array in Kannel is correct for Latin1 to GSM and back!!.. @ is 0x00 in GSM charset. Now if you look carefully you will see that there are not that many chars that are actually different from Latin1 to GSM, but more than just the @. The real issue is that not all SMSCs use the GSM charset as the default. Vodacom in SA use ASCII and only ASCII. Anyone interested in seeing the patch to add other character mappings to the charset handling functions in Kannel. We use this to load an ASCII mapping table (from a config file) for the one SMPP provider that wants @ (and the other few) as its ASCII representation. latin1_to_mapset and mapset_to_latin1 Nisan Since, I read from kannel userguide.html, the character @ in SMPP has sign y? . It means driver probably has this feature, has not been tested . Then I tested it. The conclusion is the problem seems still there because kannel mapping @ to I . This patch will patch file charset.c (below dir /gwlib). I notice that smsc_smpp.c use character set defined in charset.c file. I modified character mapping (for @) in charset.c. I already use this patch since 1.2.0 in CVS (maybe since 1.1.6 don t remember) and it work for me. I used it for my sms to mail and mail to sms services. Please take a look on this patch, because I only test it in SMPP environment. I am afraid this patch affects other driver. Kindly Regards -dedy-
Re: routing via prefix and smsc..
Hi At 04:37 PM 10/2/02 +0200, Stefan Cars wrote: Hello all! This is a kind of problem, or may not be but I'm not finding out what todo.. we deal with this before we submit messages to Kannel and pass an smsc_id to Kannel. This is then used in the config files along with preferred-smsc, allowed-smsc and denied-smsc.. You will find many other vaiants in the various providers other than Alphanumeric sender id. You may have a very cheap provider that doest let you set UDH or do Unicode, and another more expensive has same coverage but lets u set the UDH etc. nisan For our Sweden SMSC's we can send alphanumeric just through two out of three operators (telia doesn't support alphanumeric sender). Today we route all outgoing SMs depending on what prefix the mobile number has. This works very well but now we want todo that with just two SMSCs. That is if someone is sending as with alphanumeric sender we would like to one of the two SMSCs we have depending on prefix (send all to vodafone through vodafone and all the rest through tele2 since they are cheaper in sending to other networks). That routing would be done via prefix. Is this possible ? It doesn't look like that ? I've been trying around with preferred-smsc-id and denied etc. together with the prefix. But the prefix routing doesn't seem to work if you do as the above example. ?? /S
Re: That pesky @ sign
Hi well the problem is that the default character set on the SMPP servers is not allways the GSM charset that Kannel uses. Some SMPP servers use ASCII others Roman 8 and others GSM. We have a small patch that loads up a character mapping array (similar to the latin1 to gsm array in Kannel) to handle this. Nisan At 08:32 AM 9/30/02 +0100, Kita B. Ndara wrote: I wonder whether anyone out there has had this problem, and what solution they've discovered: When a user sends the '' character in an sms, on some SMSCs, kannel receives '', on other it receives NULL (as per GSM character spec). Now in the former case, gwlib/charset.c will cause convert and cause kannel to pass on the wrong character! What's the solution here, if any? I keep having to recompile kannel for the specific smsc, after changing gwlib/charset.c a little. Not cool. Thanks. __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: [RFC] unified-prefix on smsc basis
At 11:58 AM 9/6/02 +0200, you wrote: So, I guess defining the unified-prefix rules on a smsc basis is very easy to implement. BTW, I'm just coding this right now. Any comments or objections against introducing this new feature?! tis very easy.. I have done this for SMPP, but not for the other smscs. We have another similar issue with sender-id. One of our providers lets one set the sender id to anything one likes as long as is prefixed by a 5digit string (probabally some account id). It might be better to do a unified-source-prefix and unified-dest-prefix. Nisan 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: [PATCH] SMPP sequence_number
Hi +1 from me.. well spotted... n At 11:27 AM 9/6/02 +0200, you wrote: Hi all, Find attached a patch to set correctly the sequence_number field of the PDU header. According to SMPP 3.3 and 3.4 specs, it must be in the 1-N range, but currently it is in the 0-N range. This causes problems with one of our providers, wich refuses to ack our first bind_transmitter (with a 0 sequence_number). Also attached is a bearerbox.log showing the problem. 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
Re: [PATCH] internal bearerbox - smsbox routing
Hi Stipe.
Wow..this sounds really usefull.. I can already use it, but I think we
should have it as a separate patch for now, the CVS is relatively stable,
and this is quite a big internal change. I would be happy to try it on our
dev servers.
nisan
At 09:58 PM 9/6/02 +0200, Stipe Tolj wrote:
Hi all,
attached is a patch that I developed today for internal smsbox routing
inside bearerbox. The patch is quite big, so I'll try to explain what
the intention is and what it does.
Basically currently any sms that arrives at bearerbox via a specific
thread of a specific smsc module is produced to a global queue
(incoming_sms). All connected smsbox'es do grap a msg from that queue
all process it. This mechanism is basically used to load-balance msg
traffic to various smsbox'es.
However, sometimes it may be desireable for various reasons to be able
to route the sms msg to a specific smsbox. This has to be done
inside bearerbox, between the smsc module layer and the communication
to the smsbox'es.
First, bearerbox needs to know about smsboxes in a way that is
semantically more relevant. We know the IP of the smsbox and even a
local file descriptor, but that's not enough. Imagine a smsbox sending
a DLR-requesting msg. Not smsbox(1) sends msg to bearerbox, bearerbox
holds the dlr queue, receives the report from the smsc module and now
does not know if it should route to smsbox(1) or smsbox(2). Now
basically in this easy scenario it does not matter, because each
smsbox instance does only a URL lookup. But think of a SMPP proxying
box that has own state tables and reports have to be re-routed exactly
to that instance to update status tables.
Ok, here is how the thing works:
* gw/smsbox.c: graps a 'smsbox-id' from it's config group and sends
an admin msg identifying itself with a id to bearerbox
* gw/bb_boxc.c: when an admin msg is received by an identicying
smsbox, the incoming queue is switched to a private list, so that no
other smsbox shares the same list with the new identified smsbox
* gw/msg.h: adding a boxc_id Octstr to type sms to hold the
smsbox-id while transporting msg from smsbox'es to bearerbox
* gw/dlr.c: adding a boxc_id parameter to the dlr_add() abstraction
layers and to the relecant smsc_foobar.c modules
* the message went out of the smsc module door
* the delivery report comes in
* gw/dlr.c: dlr_find() inserts the remembered boxc_id to the msg
structure and passes it through the smsc module to gw/bb_smscconn.c
* gw/bb_smscconn.c: gets all incoming sms from the smsc modules and
calls the new gw/bb_boxc.c:route_incoming_sms() routine to descride to
while list this msg is produced and hence to which smsbox the msg is
routed
The smsbox routing is defined in the configuration file via the
multi-grou smsbox-route, like this
group = smsbox-route
smsbox-id = smsbox_1
smsc_ids = fake_1;fake_2;fake_3
shortcuts = 83444;83555
which means route any message coming from the smsc-id's or
msg.receiver number to this smsbox instance.
To store the mapping and routing information, 3 hash dictionaries are
used. One that holds all connection pointers from the smsbox'es and 2
seperate dictionaries for the smsc-id and receiver number mapping.
I'd like to apply the patch. Mainly it does not change any current
behaviour, but it's still a cerious change in the bearerbox internals,
so I'd like to ask for comments or objections before going to commit
this. I have tested a lot of this, but no garantee, as always :))
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 arediff -ru gateway/gw/bb_boxc.c
gateway-smpp/gw/bb_boxc.c
--- gateway/gw/bb_boxc.c2002-09-06 14:03:16.0 +0200
+++ gateway-smpp/gw/bb_boxc.c 2002-09-06 21:21:16.0 +0200
@@ -40,6 +40,9 @@
static volatile sig_atomic_t wapbox_running;
static List*wapbox_list = NULL;
static List*smsbox_list = NULL;
+static Dict *smsbox_by_id = NULL;
+static Dict *smsbox_by_smsc = NULL;
+static Dict *smsbox_by_receiver = NULL;
static longsmsbox_port;
static int smsbox_port_ssl = 0;
@@ -65,6 +68,7 @@
List *retry; /* If sending fails */
List *outgoing;
volatile sig_atomic_t alive;
+Octstr *boxc_id;
} Boxc;
@@ -173,6 +177,26 @@
store_save(msg);
debug(bb.boxc, 0, boxc_receiver: got ack);
}
+else if (msg_type(msg) == admin msg-admin.command ==
cmd_identify) {
+ List *newlist;
+
+ /* and add the boxc_ud into conn for boxc_status() output */
+ if (conn-boxc_id == NULL)
+ conn-boxc_id = octstr_duplicate(msg-admin.boxc_id);
[PATCH] SMPP
Hi
A patch to help resolve the fact that different SMSCs use different
standards for the number base of the msg_id in the submit_sm_resp and
deliver_sm.. they use hex or decimal or a mixture...
Here is a patch lets you set them independently.
The config file works like this.
smpp-msg-id-type;
bit 1 submit_sm_resp
bit 2 deliver_sm
if he bit is set the value is hex
0x00 deliver_sm decimal, submit_sm_resp decimal
0x01 (default) deliver_sm decimal, submit_sm_resp hex
0x02 deliver_sm hex, submit_sm_resp decimal
0x03 deliver_sm hex, submit_sm_resp hex *
nisan
--- cvs/gateway/gw/smsc/smsc_smpp.c Mon Aug 19 20:57:59 2002
+++ ./smsc_smpp.c Mon Aug 19 20:54:30 2002
-97,6 +97,16
int version;
int priority; /* set default priority for messages */
time_t throttling_err_time;
+int smpp_msg_id_type; /* msg id in hex or decimal..
+ * bit 1 submit_sm_resp bit 2 deliver_sm
+ * bit set value is hex
+ * 0x00 deliver_sm decimal, submit_sm_resp decimal
+ * 0x01 (default) deliver_sm decimal,
submit_sm_resp hex
+ * 0x02 deliver_sm hex, submit_sm_resp decimal
+ * 0x03 deliver_sm hex, submit_sm_resp hex *
+ */
+
+
SMSCConn *conn;
} SMPP;
-109,7 +119,8
int dest_addr_ton, int dest_addr_npi,
int alt_dcs, int enquire_link_interval,
int max_pending_submits, int reconnect_delay,
- int version, int priority, Octstr *my_number)
+ int version, int priority, Octstr *my_number,
+int smpp_msg_id_type)
{
SMPP *smpp;
-143,6 +154,7
smpp-priority = priority;
smpp-conn = conn;
smpp-throttling_err_time = 0;
+ smpp-smpp_msg_id_type = smpp_msg_id_type;
return smpp;
}
-657,7 +669,12
if (msgid != NULL) {
Octstr *tmp;
+if ((smpp-smpp_msg_id_type 0x02))
+tmp = octstr_format(%ld,
strtol(octstr_get_cstr(msgid), NULL, 16));
+else
tmp = octstr_format(%ld,
strtol(octstr_get_cstr(msgid), NULL, 10));
+
+
dlrmsg = dlr_find(octstr_get_cstr(smpp-conn-id),
octstr_get_cstr(tmp), /* smsc
message id */
octstr_get_cstr(pdu-u.deliver_sm.destination_addr),
/* destination */
-773,9 +790,14
} else {
Octstr *tmp;
-/* deliver gives mesg id in decimal, submit_sm in hex.. */
+if ((smpp-smpp_msg_id_type 0x01))
tmp = octstr_format(%ld, strtol(
octstr_get_cstr(pdu-u.submit_sm_resp.message_id),
NULL, 16));
+else
+tmp = octstr_format(%ld, strtol(
+octstr_get_cstr(pdu-u.submit_sm_resp.message_id),
NULL, 10));
+
+
/* SMSC ACK.. now we have the message id. */
if (msg-sms.dlr_mask
(DLR_SMSC_SUCCESS|DLR_SUCCESS|DLR_FAIL|DLR_BUFFERED))
-1089,6 +,7
long reconnect_delay;
long version;
long priority;
+ long smpp_msg_id_type;
my_number = NULL;
-1180,13 +1203,16
if (cfg_get_integer(priority, grp, octstr_imm(priority)) == -1)
priority = SMPP_DEFAULT_PRIORITY;
+if (cfg_get_integer(smpp_msg_id_type, grp,
octstr_imm(smpp-msg-id-type)) == -1)
+smpp_msg_id_type = 0x01; /* default(0x01) deliver_sm decimal,
+
submit_sm_resp hex */
smpp = smpp_create(conn, host, port, receive_port, system_type,
username, password, address_range, our_host,
source_addr_ton, source_addr_npi, dest_addr_ton,
dest_addr_npi, alt_dcs, enquire_link_interval,
max_pending_submits, reconnect_delay,
- version, priority, my_number);
+ version, priority, my_number, smpp_msg_id_type);
conn-data = smpp;
conn-name = octstr_format(SMPP:%S:%d/%d:%S:%S,
RE: Bearerbox is not shutting down on command.
Hi 05:47 PM 8/19/02 +0300, Oded Arbel wrote: If I understand whats going on here, then something like this happens : the bearerbox waits for sms/wap boxes to connect to it - firing a handler thread for each box connecting. all handler threads of the same type share a single message queue (incoming_sms in case of an smsbox). now, since the bearerbox creates handler threads with abandon and does not collect their ids or anything, there is never a notion of all handler threads have terminated. There is a dummy list flow_threads, that has producers added to it at the start of a thread and producers removed from it at the end. Bearerbox, waits on these for shutdown (bearerbox.c:501) My guess is that it is one of the smsc modules that are not shutting down properly. Do you have debug logs of the shutdown process, which threads exit? Nisan so if there's a message in the queue but nobody is alive that extracts messages from the queue - the message will stay in the queue forever and none will be the wiser. If we had a consumer count on a list as we have a producer, it would be easy to work around - when the consumer count drops to 0 , and we are in shutdown state - clear the queue and go home. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. The Key to life is 'fast forward'. there are some bad parts in life, and the trick is to 'fast forward' through them to the good parts. -- Fishizm
Re: Again SMPP DLR
Hi At 02:26 PM 8/16/02 +0500, David Chkhartishvili wrote: Hi All, I've sent few messages regarding got DLR but could not find message or was not interested in it, but didn't get any answer. this is probabally because the smscs use different std for the format of the msg_id in the submit_sm_resp and deliver_sm.. they use hex or decimal or a mixture... I have a patch that lets you set them independently, I will extract and post it to the list later today.. The config file works like this. smpp-msg-id-type; bit 1 submit_sm_resp bit 2 deliver_sm if he bit is set the value is hex 0x00 deliver_sm decimal, submit_sm_resp decimal 0x01 (default) deliver_sm decimal, submit_sm_resp hex 0x02 deliver_sm hex, submit_sm_resp decimal 0x03 deliver_sm hex, submit_sm_resp hex * nisan I'm asking for help again, because that issue is very important for me. Here is problem description: kannel-snapshot, smsc_smpp debug switched on. SMPP DLR with mysql storage. Every time I submit message I get: ERROR: SMPP[test]: got DLR but could not find message or was not interested in it Here is dump of smpp submit_sm_resp: SMPP[test]: Got PDU: 2002-08-16 14:08:44 [5] DEBUG: SMPP PDU 0x80d3f60 dump: 2002-08-16 14:08:44 [5] DEBUG: type_name: submit_sm_resp 2002-08-16 14:08:44 [5] DEBUG: command_id: 2147483652 = 0x8004 2002-08-16 14:08:44 [5] DEBUG: command_status: 0 = 0x 2002-08-16 14:08:44 [5] DEBUG: sequence_number: 2 = 0x0002 2002-08-16 14:08:44 [5] DEBUG: message_id: 2002-08-16 14:08:44 [5] DEBUG:Octet string at 0x80d4210: 2002-08-16 14:08:44 [5] DEBUG: len: 50 2002-08-16 14:08:44 [5] DEBUG: size: 51 2002-08-16 14:08:44 [5] DEBUG: immutable: 0 2002-08-16 14:08:44 [5] DEBUG: data: 46 46 46 46 31 34 3a 30 14:0 2002-08-16 14:08:44 [5] DEBUG: data: 38 3a 34 32 3a 30 32 38 8:42:028 2002-08-16 14:08:44 [5] DEBUG: data: 31 20 30 38 2d 31 36 2d 1 08-16- 2002-08-16 14:08:44 [5] DEBUG: data: 32 30 30 32 20 30 30 39 2002 009 2002-08-16 14:08:44 [5] DEBUG: data: 37 34 36 38 34 31 36 20 7468416 2002-08-16 14:08:44 [5] DEBUG: data: 30 30 39 38 30 32 37 30 00980270 2002-08-16 14:08:44 [5] DEBUG: data: 30 34 04 2002-08-16 14:08:44 [5] DEBUG:Octet string dump ends. 2002-08-16 14:08:44 [5] DEBUG: SMPP PDU dump ends. deliver_sm: SMPP[test]: Got PDU: 2002-08-16 14:08:49 [5] DEBUG: SMPP PDU 0x80d41c8 dump: 2002-08-16 14:08:49 [5] DEBUG: type_name: deliver_sm 2002-08-16 14:08:49 [5] DEBUG: command_id: 5 = 0x0005 2002-08-16 14:08:49 [5] DEBUG: command_status: 0 = 0x 2002-08-16 14:08:49 [5] DEBUG: sequence_number: 1 = 0x0001 2002-08-16 14:08:49 [5] DEBUG: service_type: 2002-08-16 14:08:49 [5] DEBUG: source_addr_ton: 2 = 0x0002 2002-08-16 14:08:49 [5] DEBUG: source_addr_npi: 1 = 0x0001 2002-08-16 14:08:49 [5] DEBUG: source_addr: 99599182418 2002-08-16 14:08:49 [5] DEBUG: dest_addr_ton: 2 = 0x0002 2002-08-16 14:08:49 [5] DEBUG: dest_addr_npi: 1 = 0x0001 2002-08-16 14:08:49 [5] DEBUG: destination_addr: 432 2002-08-16 14:08:49 [5] DEBUG: esm_class: 4 = 0x0004 2002-08-16 14:08:49 [5] DEBUG: protocol_id: 0 = 0x 2002-08-16 14:08:49 [5] DEBUG: priority_flag: 0 = 0x 2002-08-16 14:08:49 [5] DEBUG: schedule_delivery_time: 2002-08-16 14:08:49 [5] DEBUG: validity_period: 2002-08-16 14:08:49 [5] DEBUG: registered_delivery: 0 = 0x 2002-08-16 14:08:49 [5] DEBUG: replace_if_present_flag: 0 = 0x 2002-08-16 14:08:49 [5] DEBUG: data_coding: 0 = 0x 2002-08-16 14:08:49 [5] DEBUG: sm_default_msg_id: 0 = 0x 2002-08-16 14:08:49 [5] DEBUG: sm_length: 0 = 0x 2002-08-16 14:08:49 [5] DEBUG: short_message: 2002-08-16 14:08:49 [5] DEBUG: SMPP PDU dump ends. deliver_sm_resp: SMPP[test]: Sending PDU: 2002-08-16 14:08:49 [5] DEBUG: SMPP PDU 0x80d40b8 dump: 2002-08-16 14:08:49 [5] DEBUG: type_name: deliver_sm_resp 2002-08-16 14:08:49 [5] DEBUG: command_id: 2147483653 = 0x8005 2002-08-16 14:08:49 [5] DEBUG: command_status: 0 = 0x 2002-08-16 14:08:49 [5] DEBUG: sequence_number: 1 = 0x0001 2002-08-16 14:08:49 [5] DEBUG: message_id: NULL 2002-08-16 14:08:49 [5] DEBUG: SMPP PDU dump ends. As you see, deliver_sm doesn't conatin any short_message, also deliver_sm_resp contains no message_id. Please clarify, is it SMSC problem (may be message_id?) or SMPP DLR module. Looking forward for your response. Thank you. -- David Chkhartishvili
Re: [RFC] SMPP enquire link
At 11:39 AM 8/14/02 +0200, Stipe Tolj wrote: You don't get submit_sm PDUs from the SMPP server, do you?! I guess you mean deliver_sm PDU for MO messages? nope, submit_sm_resp, one of our providers can lag behind up to 500 odd messages.. Ok, you want to splitt the send/receiving threads from the enquire_link thread, got it. Yeah, sounds reasonable to me. well there isnt an enquire_link thread.. But Oded has some valid points on the extra thread.. I will look at another soln. Nisan 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
[RFC] SMPP enquire link
Hi All We are experiencing the following problem with the SMPP module. There are 2 instances of io_thread sender: - calls send_enquire_link and send_messages receiver: - calls send_enquire_link, after each PDU it reads and handles. What happens when there are a largish number of messages in the msgs_to_send list, 1. the send_messages loop runs and we end up with a situation where one needs to throttle the throughput to the SMPP server 2. the send_message loop now sleeps 3. the io_thread doing send_messages now cannot call send_enquire_link regularly enough to check whether it is time to send an enquire link to the SMPP server. 4. and sometimes we havent yet started to receive submit_sm's back from the smpp server - so send_enquire_link is not getting called by the io_threads.. I propose that we make an extra thread for the enquire_link sender. A very simple thread that will simply send and enquire_link and then sleep. There will be 2 instances of this thread, one for each of the instances of io_thread. io_thread will be responsible for starting and stopping this thread. Nisan
[PATCH] SMPP
Hi All Some SMPP smscs give the msg id in hex at submit_sm_resp and in the deliver_sm (default), others hex in submit_sm_resp and hex in deliver_sm. This patch adds a new config var to the SMPP module: smpp-msg-id-type: 0 - default behaviour 1- hex in both submit_sm_resp and deliver_sm Nisan smpp.patch Description: Binary data
[PATCH] SMPP Sorry
Hi Please ignore the patch.. I cvsdiffed against a much too early version. Nisan smpp.patch Description: Binary data
Re: [RFC] new module : SOAP.
Hi Oded
This looks great. I will do some testing this weekend. We have also done an
inhouse SOAP module, but far less generic than yours. So I can test to
these providers, and I can test it on our proprietory simple XML/HTTP API.
The XML example you have is not quite correct for SOAP, but then neither is
it correctly structured for XML-RPC, so its more like XML over HTTP. But
that is really irrelevant as the templates do the work.
One problem we did run into in our SOAP modules when under load, is that
the Kannel HTTP client library is not effecient enough. This rears it head
even more with a SOAP server that is *slow*. One ends up with lots of
queued messages in bearerbox. We ended up using libcurl with a configurable
amount of sender threads.
Some other problems we have bumped into with some SOAP servers, eg those
built with Wasp are often set up to expect a persistent connection between
sending your request and getting an acknowledgement. And then others use a
session id that must be honoured in the SOAP-ENV:Header.
And finally did you consider using a XSL processor - like Sablot? Generate
a XSL style sheet to map the providers XML onto an internal form that
Kannel knows about?
Nisan
At 10:55 AM 8/8/02 +0300, Oded Arbel wrote:
Hi list.
Created a new SMSC module for Kannel for use with connection
to some proprietary gateway systems some of our providers use
(we currently use this module for 3 different providers). I
call this SOAP, after the Microsoft standard as it seems to
me to be the same thing though none of our providers call it
like this in their specs. In actuality, simple XML over HTTP,
storing a provider specific XML format in a POST variable.
I tried to make this module as general as possible, but as
each provider uses different semantics and different XML
formats and even different data formats inside the XML for
the same message elements, it's harder then it seems at
first. The approach I've taken so far is to use some
configuration variables (added to cfg.def - patch attached),
file templates for creating the text buffers Kannel sends,
spec files for parsing the XML buffers Kannel receives, and
some hard coded keywords inside the template parser to
generate some weird data representations that some of our
providers like to use.
The module's HTTP server (for calls from the SOAP server to
Kannel for MO and DLR) exposes two calls :
http://ip:port/mo for MO delivery and
http://ip:port/dlr for DLR delivery. the server expects a
singe CGI post parameter whose name doesn't matter (it is
discarded) and then reads and attempts to parse the XML using
the relevant spec file. the syntax to the spec file is very
simple: it's a tab separated list where each record (line)
contains 2 or 3 elements -
1) identification of element we wish to extract. sorry to
point you to the code, but these keywords must conform to
hard coded values found in the code itself. I tried to
conform to the SMS message structure defined in Kannel's
msg-decl where possible
2) path in the XML hierarchy to the element
3) if the required data is not the content of the XML element
but one of its attributes, then this will contain the
required attribute's name
The XML template parser understand various tokens that can
be embeded in the templates to provide the actuall run-time
content. you can either use the format %token_name or %{token
name} . if you are not using the curly braced version then
the token name must start with a letter and continue only
with letters. numers and under-scores. if the token is
encapsulated is culry braces it can contain anything (except
and ending curly brace), but it of course wouldn't make much
sense unless it conforms to the same format as the former
version as they both match against the same keywords. any
member name of the SMS message structure can be used, and
also some special data formats are recognized - look in the
soap_parse_token() function's code.
Sorry for no documentation yet, I will get down to it (of
course - I will be much more motivated to provide
documentation if people will show interest in the module ;-),
in the mean time you can always read the source.
I had to add several new functions to the Kannel
infrastructures (patches attached), and here they are described :
* date.[ch]:
int date_parse_iso (struct universaltime *ut, Octstr *os) -
attempts to parse an ISO-8601 date representation,
substituting missing fields with the base values (0 or 1),
returning 0 on success and -1 on failure. the time is read
from the Octstr os and returned in the universal time structure ut.
Octstr* date_create_iso(time_t unixtime) - creates an
ISO-8601 formatted date string from a unix epoch time stamp.
* charset.[ch]:
int charset_convert(Octstr* string, char* charset_from, char*
charset_to) - converts a string buffer between arbitary
character sets using the standard glibc library iconv
(Hopefully it is present in other OSs). I had to add this
utility as the libxml encoding
Re: [PATCH] DLR
At 10:01 PM 7/10/02 +0200, Andreas Fink wrote: Hi All A small patch to the dlr code. In a situation of highload, we get duplicate ts columns in the dlr.dlr table for a particular smsc. The Mysql dlr_find code, did not take the destination into account in its query. Patch makes the SQL in dlr_find search on smsc, ts, destination rather than just smsc,ts Nisan this wont work if the submitted number doesnt match the number the SMSC is giving back. Example: I send to +4179245733 which is my phone number in international format. The EMI driver will make 004179245733 out of it but the report will show 079245733 as the reported number because that's the national format. I was thinking of changing that and storing the timestamp as given back by the EMI ACK which would always match but then I have to update the record in memory/in database so I have to keep track the record number with the submitted sequence number. Not that easy as it sounded. ..eek.. didnt realise that with EMI.. With SMPP it isnt a problem, as one has unique message ids, our modified http driver we gen our own unique ids.. Do you think a closest right most match on the destination would work, say 80% of the chars from the right match, along with the ts and smsc_id? --- cvs/gateway/gw/dlr.cTue Apr 9 15:09:03 2002 +++ ./dlr.c Tue Jul 9 11:13:58 2002 @@ -413,11 +413,13 @@ MYSQL_RES *result; MYSQL_ROW row; -sql = octstr_format(SELECT %s, %s, %s FROM %s WHERE %s='%s' AND %s='%s';, +sql = octstr_format(SELECT %s, %s, %s FROM %s WHERE %s='%s' AND %s='%s' +AND %s='%s';, octstr_get_cstr(field_mask), octstr_get_cstr(field_serv), octstr_get_cstr(field_url), octstr_get_cstr(table), octstr_get_cstr(field_smsc), -smsc, octstr_get_cstr(field_ts), ts); +smsc, octstr_get_cstr(field_ts), ts, + octstr_get_cstr(field_dst), dst); mutex_lock(dlr_mutex); -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink Nisan
Re: throtle error in SMPP/kannel-1.2.0
hI if anyone needs a patch to handle this better, we have one. Nisan At 07:01 PM 7/10/02 +, Oded Arbel wrote: Damjan wrote: Hello, I just downloaded and compiled Kannel-1.2.0. I use it to connect to a SMSC through the SMPP protocol, and from preliminary test I can say that it works pretty much OK, except for one problem. That is Kannel curently doesn't handle the SMPP throtlleing error (command_status 0x58). So if I send messages to fast, and the SMSC doesn't allow me to send so fast, the SMS messages are never delivered. I think sollutions to this problem were in fact provided on this list but it seems they never got accepted (why?). Can someone inform me about the current status of this. [ Following is a PDU dump of the submit_resp command response ] 2002-07-04 19:21:12 [5] DEBUG: SMPP PDU 0x80d2ba0 dump: 2002-07-04 19:21:12 [5] DEBUG: type_name: submit_sm_resp 2002-07-04 19:21:12 [5] DEBUG: command_id: 2147483652 = 0x8004 2002-07-04 19:21:12 [5] DEBUG: command_status: 88 = 0x0058 2002-07-04 19:21:12 [5] DEBUG: sequence_number: 7 = 0x0007 2002-07-04 19:21:12 [5] DEBUG: message_id: 2002-07-04 19:21:12 [5] DEBUG: SMPP PDU dump ends. at m-Wise we have a patch to do better ESME error detection and handling, and it does support the throttling error code. we are waiting till 1.2 will be release before submitting it, as this is a major functionality change. I'm also out of the office and won't be back till the end of the next week at the earliest, so it will have to wait till then. -- Oded Arbel m-Wise mobile solutions
[PATCH] SMPP
Hi
A small patch for the SMPP SMSC module.
When the bind_receiver_resp comes in after the bind_transmitter_resp the
SMPP module switches SMSCCONN_ACTIVE_RECV when it is allready in
SMSCCONN_ACTIVE and preventing messages getting routed to this smsc.
Nisan
--- gw/smsc_smpp.c Tue Jun 4 23:14:24 2002
+++ /home/nisof/kannel/work/smsc_smpp.c Thu Jun 20 23:27:44 2002
-779,6 +779,7
octstr_get_cstr(smpp-conn-id),
pdu-u.bind_transmitter_resp.command_status);
} else {
+ if (smpp-conn-status != SMSCCONN_ACTIVE)
smpp-conn-status = SMSCCONN_ACTIVE_RECV;
smpp-conn-connect_time = time(NULL);
}
Re: combined patch SMPP things
At 01:01 PM 5/6/02 +0200, Stipe Tolj wrote:
Benjamin Lee schrieb:
looks good for me, +1 for commitment, any other opinions?
yeah +1 for me.. except that the generic nack can be used by the SMSC for
ESME_RTHROTTLED. I have the following for generic_nack_resp
case generic_nack_resp:
{
error(0, SMPP: NACK PDU type 0x%08lx,
code 0x%08lx.,
pdu-type, pdu-u.generic_nack_resp.command_status);
if (pdu-u.generic_nack_resp.command_status ==
0x58) //ESME_RTHROTTLED
{
warning(0, SMPP: nack: %s
ESME_RTHROTTLED. Re re queuing,octstr_get_cstr(smpp-conn-name));
reason = smpp_status_to_smscconn_failure_reason(
pdu-u.submit_sm.command_status);
bb_smscconn_send_failed(smpp-conn, msg, reason);
--(*pending_submits);
}
}
break;
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: [Fwd: [PATCH] SMPP pid and dcs (Was: Re: overwrite a previous send SMS)]
Hi
I havent tested, but it all looks ok according to the specs ;-)
+1 from me
At 04:07 PM 5/1/02 +0100, Bruno David Simões Rodrigues wrote:
I'm going to commit this unless someone complains
I've had one successfull user:
From: Damjan [EMAIL PROTECTED]
Ok, this patch works - I successfully compiled it and sent
several overwriting messages with pid=65.
Thanks David.
(Off to testing Kannel/SMPP further).
-Forwarded Message-
From: Bruno David Simões Rodrigues [EMAIL PROTECTED]
To: Damjan [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], Steffen Lindemann
[EMAIL PROTECTED]
Subject: [PATCH] SMPP pid and dcs (Was: Re: overwrite a previous send SMS)
Date: 30 Apr 2002 02:23:36 +0100
It looks like smpp module lacks pid support.
This is a patch hopefully to enable pid support (MO and MT) and
MO dcs support (setting mclass, coding, etc)
As I don't have access to SMPP SMSC's neither I know smpp,
please someone test this and tell me if it works so I could commit,
or the SMPP people check, fix and commit themselves
Index: gw/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc_smpp.c,v
retrieving revision 1.56
diff -u -r1.56 smsc_smpp.c
--- gw/smsc_smpp.c 24 Apr 2002 08:13:36 - 1.56
+++ gw/smsc_smpp.c 30 Apr 2002 01:21:02 -
@@ -199,6 +199,8 @@
msg-sms.msgdata = pdu-u.deliver_sm.short_message;
pdu-u.deliver_sm.short_message = NULL;
charset_gsm_to_latin1(msg-sms.msgdata);
+msg-sms.pid = pdu-u.deliver_sm.protocol_id;
+dcs_to_fields(msg, pdu-u.deliver_sm.data_coding);
return msg;
}
@@ -276,6 +278,8 @@
}
pdu-u.submit_sm.data_coding = fields_to_dcs(msg, 0);
+if(msg-sms.pid)
+ pdu-u.submit_sm.protocol_id = msg-sms.pid;
if (octstr_len(msg-sms.udhdata)) {
pdu-u.submit_sm.short_message =
Re: sendsms and smsc parameter
At 11:49 AM 4/26/02 +0200, Andrea Viscovich wrote: As someone pointed out sometime ago, if you have multiple smsc, the parameter smsc in sendsms url does not work. I know the routing can be done by properly write the kannel conf file, but I would like to choose it from a web page time by time, so the only thing is to have the parameter working. this does work.. I use it all the time.. As in the conf file the name is smsc-id not smsc, I hope the doc tell the truth saying the parameter name in sendsms is smsc. It's difficult to solve it? when you call smsbox use.. http://./sendsms?.smsc= In your Kannel config, you must allocate smsc-ids to each SMSC. These dont have to be unique; this is usefull to group SMSCs. Then in the Kannel config you either use: denied-smsc-id OR allowed-smsc-id. If using denied-smsc-id no messages with those smsc-ids set in sendsms will be routed to that SMSC. Alternatively if you use allowed-smsc-id in the kannel conf then only messages with that particular smsc_id will be sent through this SMSC. eg. group=smsc smsc-id=A denied-smsc-id=X;Y;Z group=smsc smsc-id=X allowed-smsc-id=X will allow any message with smsc-id other than X,Y,Z to be sent through SMSC A will only allow messages with smsc-id set to X be sent through SMSC X nisan
Re: [PATCH] SMPP null terminated input
Hi At 06:26 PM 4/26/02 +0200, Stipe Tolj wrote: Null terminated messages received by kannel keep hold of the null and turn it into an '@'. This is best demonstrated if you do a get-url with an input null terminated message. anyone from the core developers voting for this patch to commit? +1 I have a version of smsc_smpp with a number of patches rolled in, both from the list and my own. This version is running in production. Thse include: 1. transceiver 2. Proper handling of ESME_RMSGQFUL, ESME_RTHROTTLED 3. unbind handling 4. throughput throttling 5. small patch to dlr reports anyone interested? 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: [RFC] implementing XML-SMS calls using libxml2 functions
At 12:45 PM 4/16/02 +0200, Stipe Tolj wrote: Hi all, I'd like to hear votes for rolling current cvs tree back, espacially the parts Bruno added for the XML-SMS support using the octstr_append() implementation. We should do this with libxml2 functions. At least I would like to strip things out again as soon as I have finished the libxml2 implementation. agreed... libxml works nicely with Kannel, we use it for a proprietory smsc n
Re: [PATCH] SMPP transceive option
hi nice.. thanks.. n At 06:18 PM 4/10/02 +0100, Simon Beale wrote: Hi The attached patch adds in the boolean option transceiver-mode. If set, it will do a 'tranceive' connection instead of a transmit connection down the standard port. It doesn't do any fallback to 'transmit' if 'transceive' fails, and it only is relevant for SMPP v3.4. Simon
Re: REPOST [PATCH] combined: smpp nack/priority/throughput/unbind,
hi +1 from me for at least for points 1 and 4 n At 07:46 PM 4/8/02 +1000, Benjamin Lee wrote: Makefile.in Reply-To: For what it's worth, find attached a repost of a combined patch consisting of: 1. SMPP handling (debug printing) of GENERIC NACK packets. 2. SMPP message priority, set via configuration option (0..5) 3. SMPP throughput, set via configuration option. 4. SMPP unbind when bearerbox is shutdown?password= 5. Makefile.in changes to allow nicer builds by non-root and temporary install dir, e.g. for RPMS /var/tmp/... - $(INSTALL) -d $(bindir) + $(INSTALL) -d $(DESTDIR)$(bindir) -- Benjamin Lee 71-75 City Rd, South Melbourne, VIC 3006 Australia http://www.dotwap.com/ Phone +61 3 9698 1840 Mobile +61 414 717 573 Fax +61 3 9698 1841
Re: Kannel supporting greek SMs?
Hi At 03:36 PM 3/8/02 +0200, Aarno Syvänen wrote: Hi List, Have someone experiences withSMs using greek character set ? GSM default alphabet certainly does not contain may greek letters :( yup, you need to use unicode nisan aarno
Re: Contributions... generic NACK info and throttling
At 03:42 PM 2/14/02 +0100, you wrote: Alex Judd wrote: BTW did we add the ton/npi configuration file changes for the SMPP driver to CVS yet? I can add the other configuration changes at the same time. no it's yet not incorporated to cvs. It seems the pro and cons discussion isn't leading us to something valueable. So, if you are advocating for one options try to convince the others (Andreas mainly). What I have done is as follows: 0. All numbers get submitted to Kannel in full international format. 1. I have four new params per SMPP smsc. forced-src-ton, forced-src-npi, forced-dest-ton, forced-dest-npi. I use Andrea's auto detect logic, and then override the appropriate settings according to the above params if they exist. 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: global-sender on a smsc basis ?
Hi yes, but then how do we deal with the situation that where possible we want to set a specific source address or sender id, but as we do not know which smsc the message ultimately will go through allow the smsc modules to override with their default if necessary. nisan At 01:41 PM 1/31/02 +0100, Angel Fradejas wrote: I agree on that, but I would like applications to be able to send with a fixed from= if the like. I mean sendsms?to=999text=Hello would be routed to te proper smsc (based on preferred-prefix for example) and then default-sender applied. As application cannot know in advance with smsc will the sms go to (this is my case), this is the proper thing. sendsms?to=999text=Hellofrom=1234 In this case, I would like to set sender=1234, whatever smsc goes it through. This is the semantics I prefer: default-sender, not forced-sender. We could have both default-sender and forced-sender, but I don't see the need. I keep thinking in the cleanest and more useful way to implement this feature. Angel Fradejas. -Mensaje original- De: Nisan Bloch [mailto:[EMAIL PROTECTED]] Enviado el: jueves 31 de enero de 2002 12:50 Para: Stipe Tolj; Angel Fradejas CC: Kannel Developers Asunto: Re: global-sender on a smsc basis ? At 01:54 AM 1/27/02 +0100, Stipe Tolj wrote: I dislike the issue that one *must* unset global-sender in the core group to make default-senders work in smsc groups. Can you point out the impacts of situation in mis-configured state? Is there a way to let both exist and in general smsbox will apply first global-sender and then bearerbox over-applies for the specific smsc to default-sender?! At least there was no heavy discussion on this topic, so I'm a bit unlead here. Some more objections or confirmations from the developers, please! I think bearerbox should override all sender settings. The applications dont need to know that some SMSCs are pikcy about sender ids and others not. So it would be better if smsbox requests had sender set as per normal, and then for the picky smscs let bearerbox override all the earlier settings.. 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: Too many concurrent allocations.
Hi STipe
I sent you a small patch for the smpp module a few days ago. It should
address this error.
Here it is again.
--- gw/smsc_smpp.c Thu Jan 17 22:51:52 2002
+++ smsc_smpp.c Mon Jan 21 21:01:35 2002
@@ -548,6 +548,7 @@
info(0,DLR = %s,octstr_get_cstr(dlrmsg-sms.msgdata));
bb_smscconn_receive(smpp-conn, dlrmsg);
+ bb_smscconn_sent(smpp-conn, msg);
}
else
{
Nisan
At 02:53 PM 1/31/02 +0100, Stipe Tolj wrote:
Benjamin Lee wrote:
After running the cvs 20020126 version of kannel connected to an SMPP
gateway quite happily for the last 6 days... kannel died with:
2002-01-31 00:11:22 [8] PANIC: Too many concurrent allocations.
Does this imply that the server it was running on ran out of memory? Or, is
there a subtle leak somewhere?
No, Kannel has a limitation if you run it in --with-malloc=check mode
which is the default setting while configuring.
For productive enviroments I would suggest using the
--with-defaults=speed flag which sets malloc and assertion checking
accordingly.
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: SMPP implementation in current CVS build
Hi Alex At 02:00 PM 1/27/02 -0600, Alex Judd wrote: With the SMPP code this causes the mutex lock code to try and lock the same mutex twice and hence panics the box. Before I look into moving the smpp code to a format similar to smsc_emi2 or smsc_http has anyone already done this or is there a quick way around this? We havent seen this behavior. Please could you send us some beaererbox logs. nisan Alex -- Alex Judd http://www.enpocket.com/
Re: SMPP: possible to do RECEIVE_BIND only ?
Hi
here is a patch that should do it. Setting the relative port or
receive-port to 0 in the smpp smsc group config will disable either the
transmitter/receiver. I have to bind both with my SMSC, could someone
please test.
Nisan
--- ../cvs/gateway/gw/smsc_smpp.c Thu Jan 10 20:23:48 2002
+++ smsc_smpp.c Thu Jan 17 22:35:46 2002
@@ -853,10 +853,13 @@
octstr_destroy(address_range);
conn-status = SMSCCONN_CONNECTING;
+if (port !=0)
smpp-transmitter = gwthread_create(io_thread, io_arg_create(smpp, 1));
+if (receive_port !=0)
smpp-receiver = gwthread_create(io_thread, io_arg_create(smpp, 0));
-if (smpp-transmitter == -1 || smpp-receiver == -1) {
+if ((port !=0 smpp-transmitter == -1) ||
+(receive_port !=0 smpp-receiver == -1)) {
error(0, SMPP: Couldn't start I/O threads.);
smpp-quitting = 1;
if (smpp-transmitter != -1) {
At 04:59 PM 1/17/02 +0100, Stipe Tolj wrote:
Paul Keogh wrote:
Hi. We've got access to an SMPP interface, which sort of works...
But the SMPP only allows us to do BIND_RECEIVER, not BIND_TRANSMITTER.
Is there any way to tell kannel to forget about that BIND_TRANSMIT
that it cannot have?
Kannel insists on doing an endless 2-second loop of
2002-01-09 10:42:48 [7] ERROR: SMPP: SMSC rejected login to
transmit, code
0x000d.
2002-01-09 10:42:48 [7] ERROR: SMPP: I/O error or other error.
Re-connecting.
2002-01-09 10:42:50 [7] ERROR: SMPP: SMSC rejected login to
transmit, code
0x000d.
2002-01-09 10:42:50 [7] ERROR: SMPP: I/O error or other error.
Re-connecting.
Receiving works OK, though, it's just annoying with
those connect attempts every 2 seconds...
Do anyone know of a way to avoid that?
Not through configuration. You'll have to make a code change to get
this functionality.
I guess this _should_ be configurable.
Jacob, could you please send a patch for the devel@ list if you had
your hands on this issue and we will try to incorporate it to cvs with
configurable directives.
--
Für weitere Fragen stehe ich Ihnen gerne telefonisch
oder via E-Mail zur Verfügung.
Mit freundlichen Grüßen
Stipe Tolj
Department Management
Technology Center Research Lab
[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: high load troubles...
Hi At 03:43 PM 1/16/02 +0100, Andreas Fink wrote: Got a new problem under high load. what is highload? bearerbox is running and has delivery reports to deliver to smsbox. smsbox is down. an application is ready to fire lots of data to smsbox. Anyone have an idea what happens here? Maybe its trying to send to bearerbox before bearerbox is connected or so? yup.. I ended up starting bearerbox, then smsbox and letting it settle +-1sec and then start my apps. Nisan -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: DLR Errors
At 03:01 PM 1/7/02 +0100, Andreas Fink wrote: . However I'm pretty sure the code is checking the smsc-id first so this comparison shouldnt happen anyway. yup it does. Does this problem occur with both the memory and the mysql based implementations? Nisan
Re: Error code 0x00000010, SMPP when sending...
At 02:45 PM 12/18/01 +0100, Stefan Cars wrote: Ok. Strange, becuase it did work a couple of days ago and nothing have changed.. It means the destination address is invalid. Maybe your service provider has changed their roaming agreements. What was the destination number, any change part of a Orange. Nisan On 18 Dec 2001, Robin Ericsson wrote: On Tue, 2001-12-18 at 14:14, Stefan Cars wrote: I get this when trying to send via SMPP to swedish tele2. Tried to figure it out but no sucess, anyone else had the same problem: 2001-12-18 14:11:27 [3] DEBUG: Status: 202 Answer: Sent. 2001-12-18 14:11:27 [9] DEBUG: boxc_receiver: sms received 2001-12-18 14:11:27 [3] DEBUG: HTTP: Resetting HTTPClient for `213.136.48.100'. 2001-12-18 14:11:27 [6] ERROR: SMPP: SMSC returned error code 0x0010 in response to submit_sm. I get this error when I use a sender-number not allowed by the SMSC. regards Robin
Re: Kannel queue list limitations
At 04:10 PM 11/22/01 +0100, Andreas Fink wrote: if you run in checked memory configuration, this is a safeguard shutting down kannel as it presumes its a memory runaway situation. ./configure --with-malloc=native switches this off (and makes it a lot faster). I suppose that could be a memory problem, if so we could develop a queue system using the file system and not memory, or extend the current queue system to use the file system when the memory queue list is full... Forget about it, the existing system is very good in this respect. If queuing in memory isnt suficcient enough, I would go for a database. I had several 10'000 SMS in the queue without problems. I agree... except that we have built a Qing system, this sits outside of Kannel and dispatches messages to Kannel. nisan -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: com/woolleynet/SMPPSim/SMPPSim
Hi It looks like you have your ports the wrong way around. SMS_APP_TRANS_PORT Port to listen on for transmitter messages such as SUBMIT_SM i.e. port in the kannel config SMS_APP_RECV_PORT Port to listen on for receiver messages such as BIND_RECEIVER. i.e. receive-port in kannel so in your kannel config you should have port = 12001 receive-port = 12003 Nisan At 10:21 AM 11/20/01 +1300, you wrote: Friends I am trying to use SMPPSim and not having a lot of success. I was wondering if an older kannel hand than I could advise me please... The bearer box says 2001-11-19 21:05:17 [7] ERROR: System error 111: Connection refused 2001-11-19 21:05:17 [7] ERROR: error connecting to server `localhost' at port `12001' SMPPSim says... Starting DELIVER_SM loop DT: DELIVER_SM DT failed writing response The relevant part of smskanel.conf is... # SMPP SMSC group = smsc smsc = smpp # # Host IP of SMPP server host = localhost # # This is the receive port on the SMPP server port = 12003 # # This is the transmit port on the SMPP server receive-port = 12001 # # SMSCID on the SMPP server smsc-username = mysmsc # # None on the SMPP server smsc-password = system-type = VMA The SMPPSim property file is SMS_APP_TRANS_PORT=12001 SMS_APP_TRANS_LISTENERS=10 SMS_APP_RECV_PORT=12003 SMS_APP_RECV_LISTENERS=1 HTTP_CONTROL_PORT=12004 HTTP_CONTROL_LISTENERS=1 qSMSCID=mysmsc RANDOM_STATUS_TRIGGER=50 DELIVERY_MESSAGES_PER_MINUTE=240 DELIVER_MESSAGE=Check out www.mobilelandscape.co.uk DELIVER_FROM_MSISDN=07702876543 DELIVER_TO_MSISDN=64211733380 -- Worik Macky Turei Stanton Whew![EMAIL PROTECTED] Aotearoa
Re: suggest moving smpp_pdu to gwlib
Hi At 08:27 AM 11/16/01 -0800, you wrote: I only needed smpp library. I suggests to move gw/smpp_pdu.* to gwlib. Then I can make smpp client application with only libgwlib.a. Of cource I needed adding more in smpp_pdu.def. And also it would be nice to move some function in smsc_smpp.c to gwlib, This doesnt make sense. gwlib is for general code (I use some of it for other apps), gw is for the gateway. What are you trying to do? Nisan but I didn't. -- Futaya Yamazaki InterLinear Technology,Inc. 1420 Harbor Bay Parkway,Suite 281,Alameda,CA 94502 USA TEL (510)522-5077 FAX (510)522-1228 WWW http://www.ilt.com
