RE: [FYI] pthread_mutex bug in openssl thread locking fixed
Great. Good work, Stipe. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Stipe Tolj Enviado el: martes 4 de marzo de 2003 13:36 Para: [EMAIL PROTECTED] Asunto: [FYI] pthread_mutex bug in openssl thread locking fixed Hi list, just to let you all know that I have fixed and commited a long standing openssl call-back function bug causing to break with pthread_mutex locking. The problem was, that we registered the two different call-back functions to the openssl crypto library, one for the ssl client and one for the ssl server side. But openssl does not know about those issues, it let's you only registed one bunch of mutex locks for it's internal thread locking. This fix should cleanup some ssl related problems. So if you had experienced problems with it, please update your cvs tree and try the latest version. See http://www.kannel.org/cgi-bin/viewcvs.cgi/gateway/gwlib/conn.c.diff?r1=1.58&; r2=1.59 for the changes. 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: [RFC] smsc logging patch commit?!
Hi Stipe, I didn't have the time to try your patch, but, at first sight and from your comments, it looks ok to me. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Stipe Tolj Enviado el: martes 4 de marzo de 2003 14:27 Para: [EMAIL PROTECTED] Asunto: [RFC] smsc logging patch commit?! Hi list, I'd like to apply my patch this afternoon. It an 'feature-add' and hence does not break any common behaviour. If someone has considerable constrainst against a commit, please veto. 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] Octstr additions
+1 too. These functions can be quite handy.
Angel Fradejas
Mediafusion Espana, S.A.
[EMAIL PROTECTED]
www.mediafusion.es
Tel. +34 91 252 32 00
Fax +34 91 572 27 08
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
nombre de Nisan Bloch
Enviado el: martes 4 de marzo de 2003 08:02
Para: [EMAIL PROTECTED]
Asunto: [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;i
[PATCH] quick fixes for last log.c changes
Hi, Attached a patch to fix some minor problems with last log.c patch 1) fixes wrong use of & in a info() call (spotted by "gwlib/log.c:105: warning: char format, different type arg (arg 3)") 2) more consistent and safe check for stderr Cheers. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 patch_logc.diff Description: Binary data
RE: [PATCH] admin http 'loglevel' command for bearerbox
Stipe Tolj wrote: >yep, +1 from me to. > >I'm just addding some more things to it. Especially the ability to >change the log-level of a specific logfile too. Yes, and adding support to add/remove debug_places would be nice. I just sent a basic support patch to see if there was interest in that funcionality. 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
[PATCH] admin http 'loglevel' command for bearerbox
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=x&level=1 Please consider committing to cvs. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 patch_bearerbox_dynamic_loglevel.diff Description: Binary data
[PATCH] generic support for our-host smsc directive
Hi all, Find attached a patch to add generic support for the "our-host" smsc config directive. Until now it was only supported in emi2 and smpp, and not fully (for example emi2_open_listening_socket() created the server socket without explicit binding to a specific interface). This patch adds support to SMSCConn based drivers: smsc_emi2.c CMG UCP/EMI 4.0 smsc_smasi.c SM/ASI (for CriticalPath InVoke SMS Center 4.x) smsc_cgw.c Sonera ContentGateway software smsc_http.c HTTP-based relay and content gateways smsc_fake.c Fake SMSC smsc_smpp.c SMPP 3.4 I may add generic support to the old SMSCenter based drivers (cimd2, ois, etc) if there's interest. Please, consider committing to cvs. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 patch_generic_our_host.diff Description: Binary data
[BUG FILED] 'make tests' broken recently
I filed a bug [Kannel 003]: 'make tests' doesn't work anymore See http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/Makefile.in.diff?r1=1.63&r2=1.64 Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08
RE: Kannel snapshot and Vodaphone Spain
Maybe you can provide with PDU dumps to see what's happening. -Mensaje original- De: Arne K. Haaje [mailto:[EMAIL PROTECTED] Enviado el: miércoles 26 de febrero de 2003 16:31 Para: Angel Fradejas; [EMAIL PROTECTED] Asunto: Re: Kannel snapshot and Vodaphone Spain onsdag 26. februar 2003, 16:06, skrev Angel Fradejas: > Forgot to say, I always supply the destination number in +346 > format. > > -Mensaje original- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > nombre de Angel Fradejas > Enviado el: miércoles 26 de febrero de 2003 15:57 > Para: Arne K. Haaje; [EMAIL PROTECTED] > Asunto: RE: Kannel snapshot and Vodaphone Spain > > > I have these values in my smsc-group: > > #GSM_ADDR_TON_UNKNOWN > source-addr-ton = 0 > #GSM_ADDR_NPI_E164 > source-addr-npi = 1 > # for 0xFX dcs values > alt-dcs = yes > > and successfully work with Vodaphone Spain. > > 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 > > > > -Mensaje original- > De: Arne K. Haaje [mailto:[EMAIL PROTECTED] > Enviado el: miércoles 26 de febrero de 2003 15:43 > Para: Angel Fradejas; [EMAIL PROTECTED] > Asunto: Re: Kannel snapshot and Vodaphone Spain > > onsdag 26. februar 2003, 15:19, skrev Angel Fradejas: > > Try > > > > regular text: &coding=2 > > flash : &coding=2&mclass=1 > > > > and don't forget to use > > > > alt-dcs = yes > > > > on your smsc-group. > > > > If you leave coding unset, you'll have 7bit, and you won't get a dcs that > > is accepted by Vodaphone Spain. > > Thanks, but I still can not receive the messages. Do I need to set anything > else in the smsc-group - ton, npi etc. ? > > I am using the same config as the patched 1.1.5, but I receive no messages > - nether text or binary. This is my setup; # SMSC CONNECTIONS group = smsc smsc = smpp smsc-id = ES_AIRTEL host = 212.73.32.54 port = 2567 preferred-smsc-id = ES_AIRTEL receive-port = 2567 smsc-username = smsc-password = system-type = "MESS" address-range = "" preferred-prefix = "34" alt-dcs = yes source-addr-ton = 0 #GSM_ADDR_NPI_E164 source-addr-npi = 1 # SMSBOX SETUP I send with coding=2 and the +346 format, but I receive no messages. Is there something I need to change in the smsc group? -- Med vennlig hilsen, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.com/
RE: Kannel snapshot and Vodaphone Spain
Forgot to say, I always supply the destination number in +346 format. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Angel Fradejas Enviado el: miércoles 26 de febrero de 2003 15:57 Para: Arne K. Haaje; [EMAIL PROTECTED] Asunto: RE: Kannel snapshot and Vodaphone Spain I have these values in my smsc-group: #GSM_ADDR_TON_UNKNOWN source-addr-ton = 0 #GSM_ADDR_NPI_E164 source-addr-npi = 1 # for 0xFX dcs values alt-dcs = yes and successfully work with Vodaphone Spain. 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 -Mensaje original- De: Arne K. Haaje [mailto:[EMAIL PROTECTED] Enviado el: miércoles 26 de febrero de 2003 15:43 Para: Angel Fradejas; [EMAIL PROTECTED] Asunto: Re: Kannel snapshot and Vodaphone Spain onsdag 26. februar 2003, 15:19, skrev Angel Fradejas: > Try > > regular text: &coding=2 > flash : &coding=2&mclass=1 > > and don't forget to use > > alt-dcs = yes > > on your smsc-group. > > If you leave coding unset, you'll have 7bit, and you won't get a dcs that > is accepted by Vodaphone Spain. Thanks, but I still can not receive the messages. Do I need to set anything else in the smsc-group - ton, npi etc. ? I am using the same config as the patched 1.1.5, but I receive no messages - nether text or binary. -- Med vennlig hilsen, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.com/
RE: Kannel snapshot and Vodaphone Spain
I have these values in my smsc-group: #GSM_ADDR_TON_UNKNOWN source-addr-ton = 0 #GSM_ADDR_NPI_E164 source-addr-npi = 1 # for 0xFX dcs values alt-dcs = yes and successfully work with Vodaphone Spain. 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 -Mensaje original- De: Arne K. Haaje [mailto:[EMAIL PROTECTED] Enviado el: miércoles 26 de febrero de 2003 15:43 Para: Angel Fradejas; [EMAIL PROTECTED] Asunto: Re: Kannel snapshot and Vodaphone Spain onsdag 26. februar 2003, 15:19, skrev Angel Fradejas: > Try > > regular text: &coding=2 > flash : &coding=2&mclass=1 > > and don't forget to use > > alt-dcs = yes > > on your smsc-group. > > If you leave coding unset, you'll have 7bit, and you won't get a dcs that > is accepted by Vodaphone Spain. Thanks, but I still can not receive the messages. Do I need to set anything else in the smsc-group - ton, npi etc. ? I am using the same config as the patched 1.1.5, but I receive no messages - nether text or binary. -- Med vennlig hilsen, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.com/
RE: SMSC Modules (Was: Kannel & Swisscom)
Nicholas Rahn wrote: >> iServer is a proprietary Swisscom "SMSC". It abstracts multiple EMI/UCP >> connections with a proprietary HTTP/socket interface in order to provide >> billing, throughput, etc. There is currently no way to use kannel to >> connect to it. > > You could, however, write a new kannel smsc module to do it. :-) > > Nick Is there anyone willing to share his Swisscom iServer smsc module? If not, I'll have to write one soon. Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
RE: Kannel snapshot and Vodaphone Spain
Try regular text: &coding=2 flash : &coding=2&mclass=1 and don't forget to use alt-dcs = yes on your smsc-group. If you leave coding unset, you'll have 7bit, and you won't get a dcs that is accepted by Vodaphone Spain. Good luck. Angel Fradejas Mediafusion Espana, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] nombre de Arne K. Haaje Enviado el: miercoles 26 de febrero de 2003 14:42 Para: [EMAIL PROTECTED] Asunto: Kannel snapshot and Vodaphone Spain Hello, Does anybody know how to get Kannel to talk to Vodaphone Spain? I need to send regular text messages and flash messages, but whatever I try setting for coding and mclass the messages never reach the recipient. In kannel 1.1.5 I could set pdu->u.submit_sm.data_coding = 0xf5; in smsc_smpp.c to send regular text but I can not send flash messages with that verion. Is there some way of using the latest snapshot with Vodaphone Spain? -- Med vennlig hilsen, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.com/
RE: [PATCH] Re: RE : SMPP 3.3 trouble
Yep of course +1, this is something I already submitted on Sep 06 2002, and was accepted. See http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc/smsc_smpp.c. diff?r1=1.9&r2=1.10 http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/ChangeLog.diff?r1=1. 1950&r2=1.1951 It seems someone rolled it back :-( Angel Fradejas Mediafusion Espana, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de David Holland Enviado el: viernes 21 de febrero de 2003 14:19 Para: Alexander Malysh CC: Raphael Bellec; [EMAIL PROTECTED] Asunto: Re: [PATCH] Re: RE : SMPP 3.3 trouble On Fri, Feb 21, 2003 at 02:06:12PM +0100, Alexander Malysh wrote: > For all: SMPP v3.4 spec allow sequence number in the range from 0x0001 to 0x7FFF > And we send 0x0 , that is wrong and SMSC do right job! Looks plausible to me... +1 I guess most other SMSC's are lax about accepting a zero sequence number or this problem would have been fixed by now. Dave -- :: David Holland :: Systems Manager :: 3G Lab :: +44 01223 478900 :: "Disney does mediated experiences better than anyone. If they understood what OSes are ... they could crush Microsoft in a year or two." -- NS
RE: DCS and PID handling in Kannel
Bruno Rodrigues wrote: >It's not a "Kannel decision", it's a "kannel option" > >did you understand the "you can generate every valid dcs" ? > >did you understand that third parties, which might not have a clue about dcs and >like to just say &mclass=1 for flash or &coding=3&text= for unicode accented >chars? Bruno, you are talking about sendsms interface (MTs), and David is trying to explain a problem (or lack of funcionality) in MOs. What David is proposing is to copy the DCS and PID fields of the MOs received in a corresponding msg->sms.x fields (keeping also the actual fields) and forward them to smsbox and the corresponding %urlpatterns. For example, msg->sms.orig_dcs, msg->sms.orig_pid, etc. David, did I explain it right? 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
[PATCH] http smsc crash
Hi all, Just a quick patch to fix a crash on the http smsc driver, when receiving incoming messages. (Maybe not on the first received, but on the 3rd or 4th). Simple enough to go in before new release. Cheers. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 patch_smsc_http.diff Description: Binary data
RE: [PATCH] unneeded counter increase?!
+1 from me. This is a bug we have observed on our production emi2 link. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: martes 21 de enero de 2003 12:04 Para: [EMAIL PROTECTED] Asunto: [PATCH] unneeded counter increase?! Hi list, is this patch making sense: RCS file: /home/cvs/gateway/gw/smsc/smsc_emi2.c,v retrieving revision 1.7 diff -r1.7 smsc_emi2.c 713d712 < counter_increase(conn->received); Can someone who runs emi2 in production state a comment and/or vote please?! 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_id start with 1)
Ups, so someone rolled back the fix?? -Mensaje original- De: Alexander Malysh [mailto:a.malysh@;centrium.de] Enviado el: jueves 24 de octubre de 2002 15:48 Para: Angel Fradejas; Oded Arbel; [EMAIL PROTECTED] Asunto: Re: [PATCH] smpp (sequence_id start with 1) Hi, but it still not here in the last cvs version ;( Am Donnerstag, 24. Oktober 2002 15:35 schrieb Angel Fradejas: > Hi all, > > Oded, counter_increase() is a post-increment function: it returns the value > before incrementing. > > Anyway, this fix was already posted by myself on Sep 06, and commited in > CVS. > > See > http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc/smsc_smpp.c >. diff?r1=1.9&r2=1.10 > > 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 > > > > -Mensaje original- > De: [EMAIL PROTECTED] [mailto:devel-admin@;kannel.3glab.org]En > nombre de Oded Arbel > Enviado el: jueves 24 de octubre de 2002 15:00 > Para: Alexander Malysh; [EMAIL PROTECTED] > Asunto: RE: [PATCH] smpp (sequence_id start with 1) > > > > -1 for that patch : in msg_to_pdu(), counter_increase is called before > calling pdu_create(), so the counter can never be 0 when pdu_create() is > entered. -- 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: [PATCH] smpp (sequence_id start with 1)
Hi all, Oded, counter_increase() is a post-increment function: it returns the value before incrementing. Anyway, this fix was already posted by myself on Sep 06, and commited in CVS. See http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc/smsc_smpp.c. diff?r1=1.9&r2=1.10 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:devel-admin@;kannel.3glab.org]En nombre de Oded Arbel Enviado el: jueves 24 de octubre de 2002 15:00 Para: Alexander Malysh; [EMAIL PROTECTED] Asunto: RE: [PATCH] smpp (sequence_id start with 1) -1 for that patch : in msg_to_pdu(), counter_increase is called before calling pdu_create(), so the counter can never be 0 when pdu_create() is entered. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Who's more foolish? The fool, or the one who follows him?" -- Ben Kenobi, "Star Wars" > -Original Message- > From: Alexander Malysh [mailto:a.malysh@;centrium.de] > Sent: Thursday, October 24, 2002 1:01 PM > To: [EMAIL PROTECTED] > Subject: [PATCH] smpp (sequence_id start with 1) > > > Hi All, > > here is small 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: [RFY] rolling 1.2.1 tarball?!
+1 of course, then patch time! let's have some fun. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: jueves 17 de octubre de 2002 10:45 Para: [EMAIL PROTECTED] Asunto: [RFY] rolling 1.2.1 tarball?! Hi, anyone complaints about rolling now the stable 1.2.1 tarball out of cvs head branch?! 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: Another one -- smsc
Yes, there is a way, using preferred-smsc group = smsc smsc-id = A preferred-smsc-id = A group = smsc smsc-id = B Then put &smsc=A in all of your sendsms requests. They will go to A, unless it's not online, in that case they will go to B. You can even try to put this group = smsc smsc-id = A preferred-smsc-id = ;A group = smsc smsc-id = B And then you could leave unset &smsc in your sendsms requests, but this is totally untested, just guessing. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Kita B. Ndara Enviado el: lunes 30 de septiembre de 2002 12:04 Para: Stipe Tolj CC: [EMAIL PROTECTED] Asunto: Re: Another one -- smsc Isn't there a way to work with the preffered-smsc and such settings to achieve this? --- Stipe Tolj <[EMAIL PROTECTED]> wrote: > "Kita B. Ndara" wrote: > > > > I have two SMPP connections to a network. One is > > primary the other a backup. I want all my messages > to > > go through the first, unless it is dead. By > default > > kannel does a sort of load balance, which is not > > good... Any ideas? > > if your configuration allows bearerbox to route to > both smsc > connections it will randomly pick one, yes, that's a > sort of > load-balancing. > > If your main smsc link dies it will then route > everything to the > backup connection. > > AFAIK, there is currently no configuration construct > to tell 'send > everything to A and if that breaks everything to B'. > > 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: [VOTE] changing Octstr comparison behaviour (was: converting to and from HTML 4 entities)
My vote is to use strcmp only and let the underlying libc to do the proper work concerning locale. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded Arbel Enviado el: lunes 23 de septiembre de 2002 20:00 Para: Rene Kluwen / Chimit Software Solutions CC: [EMAIL PROTECTED] Asunto: [VOTE] changing Octstr comparison behaviour (was: converting to and from HTML 4 entities) > -Original Message- > From: Rene Kluwen / Chimit Software Solutions > MHO on A couple of things: > - strcmp is (should be) Locale specific, according to POSIX. > - The difference in octstr_compare and octstr_str_compare are at least > inconsequent. They should both use either use strcmp or memcmp to > avoid confusions (my vote is for strcmp). I'd like to put a vote up on the list for changing the current behaviour of the comparison functions in octstr.[ch] to be consistant, and whether they should all use memcmp() or strcmp(). I'm voting to change the current behaviour so that it will be consistent and use only strcmp() or stricmp() internally. > - The discussion about whether entities should be compared to > Locale or > to byte order is more or less void. Entities do not contain > locale-specific characters by definition. Because that is why entities > are used for. oh, right :-) thanks for pointing that out. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. If they wrote error messages in Haiku ? The ten thousand things How long do any persist? Netscape, too, has gone. > OA> -Original Message- > OA> From: Andreas Fink [mailto:[EMAIL PROTECTED]] > OA> Sent: Monday, September 23, 2002 4:13 PM > OA> To: Oded Arbel > OA> Cc: [EMAIL PROTECTED] > OA> Subject: Re: Octstr support for converting to and from > HTML 4 entities. > > > > > > OA> Oh. that was me - sorry. its no hard rule, but basicly > what I meant is - don't use c strings for doing complicated > stuff that the Octstr sub system handles better and more > safely. do use c-string > OA> library calls for simple stuff that the library call > would do better, especially if the call doesnot modify the > content of the string (hence - no risk for buffer overflows). > for example, when you > OA> want to compare octstrings you can use > strcmp(octstr_get_cstr( or you can use octstr_compare(). > this is the border line case IMO, where in this case I would > have used the octstr_compare() as > OA> it involves fewer calls. you have already demonstrated > that you can choose correctly between complexity and safety, > and you can make the same decisions here. most importantly - > don't take > OA> anything said by Kannel developers , especially me, as > hard truth - those are simply recomendations. if we hate your > code so much (not that I do) - we can change when it is in > the CVS :-) > > > > OA> strcmp(octstr_get_cstr(... and octstr_compare() behave > DIFFERENTLY. > OA> if I remember correctly octstr_compare is case sensitive > where strcmp is more or less simply comparing the bytes. > > OA> strcmp should be locale sensitive as per the POSIX > standard, IIRC. it has nothing to do with case sensitivity. > > OA> I wouldnt count on it to compare on upper/lowercase and > even diacritical characters. > > OA> Well - you should. on the contrary - while strcmp is (or > at least should be) locale aware, octstr_compare() uses > memcmp() internally, which does simple byte comparison. OTOH, > octstr_str_compare() > OA> which IMO should behave no different then > octstr_compare() uses strcmp() internally. > > > OA> as you can see comparing strings is not always obvious. > but it should be at least consistent. So if you can write a > parameter in a config file in upper or lower case and it > doesn't really matter, > OA> suddendly using strcmp would make the behaviour really strange. > > OA> if you want to be case insensitive, you can use stricmp() > or octstr_case_compare(). since Rene uses > octstr_str_compare() which internally uses the locale > sensitive strcmp(), maybe we should > OA> change it to use octstr_compare() somehow so that > comparison would be byte ordered (locale insensitive) and > sort the entity list to match ? > > OA> octstr.c is an abstraction layer. Thats what it is there > for. So use it for that purpose. > OA> and frankly, the memory checking stuff is really useful > in it. I'm fixing a few dozen memory leaks by using it. It > points with the finger to it all the time. Very easy to fix t
RE: [REPOST] [PATCH] emi2 reconnection behaviour
>> If you don't want a reconnection, you just can set the "reconnect-delay" >> to a very high value, and you're done (as in the rest of drivers). > Wouldn't that mean that eventually Kannel will reconnect ? Well I meant a VERY high value, let's say 3. That's almost 10 years Angel.
RE: [REPOST] [PATCH] emi2 reconnection behaviour
Oded, that's exactly what I did in my patch and wanted to do I even removed the "retry" option, as the rest of driversbut it seems not everybody agrees with that :-( I think the "retry" directive is a bad idea, whatever it defaults to. If you don't want a reconnection, you just can set the "reconnect-delay" to a very high value, and you're done (as in the rest of drivers). So I guess we need consensus here. Angel. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded ArbelEnviado el: lunes 23 de septiembre de 2002 16:34Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: RE: [REPOST] [PATCH] emi2 reconnection behaviour I'd suggest to set the default of retry as 'yes', as most users do use EMI over TCP/IP. --Oded Arbelm-Wise mobile solutions[EMAIL PROTECTED] +972-9-9581711 (116)+972-67-340014 ::.."Existence is not only temporary, it's pointless!" -- Calvin and Hobbes -Original Message-From: Angel Fradejas [mailto:[EMAIL PROTECTED]]Sent: Monday, September 23, 2002 4:13 PMTo: Andreas FinkCc: [EMAIL PROTECTED]Subject: RE: [REPOST] [PATCH] emi2 reconnection behaviour Ok, sounds reasonable for me. I didn't know that fact for Germany. So I can resubmit the patch, keeping the "retry" directive, with "no" as default (as it is actually), and fix the behaviour with a "reconnect-delay" directive, with a 10 seconds default. Is this ok? Angel. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas FinkEnviado el: lunes 23 de septiembre de 2002 13:44Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: Re: [REPOST] [PATCH] emi2 reconnection behaviourOn Montag, September 23, 2002, at 10:33 Uhr, Angel Fradejas wrote: >Somehow I disageee. Some folks use EMI/UCP on dialup links so you don't > want to have it retry all the time and open the link. >"It always assumes reconnection" is thus not a good idea. Then we could mark it as a compatibility-breaker in the next release. I think there are much more people using it over direct tcp links than dialup ones. This is definitively wrong for users in Germany as the german carriers don't allow connectivity over the internet usually but only over 2Mbps permanent leased line (very expensive) or ISDN dial-on demand dialup to a private network.I think we simply should fix the existing behaviour instead of inventing another new one.Andreas FinkGlobal Networks, Inc.--Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, SwitzerlandWeb: http://www.global-networks.ch/ [EMAIL PROTECTED]--Member of the GSM Association
RE: [REPOST] [PATCH] emi2 reconnection behaviour
Ok, sounds reasonable for me. I didn't know that fact for Germany. So I can resubmit the patch, keeping the "retry" directive, with "no" as default (as it is actually), and fix the behaviour with a "reconnect-delay" directive, with a 10 seconds default. Is this ok? Angel. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas FinkEnviado el: lunes 23 de septiembre de 2002 13:44Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: Re: [REPOST] [PATCH] emi2 reconnection behaviourOn Montag, September 23, 2002, at 10:33 Uhr, Angel Fradejas wrote: >Somehow I disageee. Some folks use EMI/UCP on dialup links so you don't > want to have it retry all the time and open the link. >"It always assumes reconnection" is thus not a good idea. Then we could mark it as a compatibility-breaker in the next release. I think there are much more people using it over direct tcp links than dialup ones. This is definitively wrong for users in Germany as the german carriers don't allow connectivity over the internet usually but only over 2Mbps permanent leased line (very expensive) or ISDN dial-on demand dialup to a private network.I think we simply should fix the existing behaviour instead of inventing another new one.Andreas FinkGlobal Networks, Inc.--Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, SwitzerlandWeb: http://www.global-networks.ch/ [EMAIL PROTECTED]--Member of the GSM Association
RE: [REPOST] [PATCH] emi2 reconnection behaviour
>Somehow I disageee. Some folks use EMI/UCP on dialup links so you don't > want to have it retry all the time and open the link. >"It always assumes reconnection" is thus not a good idea. Then we could mark it as a compatibility-breaker in the next release. I think there are much more people using it over direct tcp links than dialup ones. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08
[REPOST] [PATCH] emi2 reconnection behaviour
Not much feedback on this one... (apart from Oded ;-) Don't you guys think this would be a nice fix to have on CVS? It would be nice to hear from the ones using EMI2 in a production environment. Angel. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Angel FradejasEnviado el: lunes 9 de septiembre de 2002 11:30Para: Kannel DevelopersAsunto: [PATCH] emi2 reconnection behaviour Hi all, Attached is a patch to change the current behaviour of EMI2 driver when handling connection errors.I'm making EMI2 driver consistent with SMPP and SM/ASI behaviour and configuration directives, while trying to fix a couple of things. This is what the patch changes: 1) Removes "retry" smsc config directive for EMI2. It always assumes reconnection, as the rest of drivers.2) Adds a "reconnect-delay" directive, as SMPP and SM/ASI drivers: optional time between attemps in seconds. It defaults to 10 seconds. The reason for this changes (apart from making all drivers consistent), is that current EMI2 handling of reconnection attempts is a mess. Let me explain why: 1) It defaults to not retrying reconnection. That means that when you start bearerbox, if a single EMI2 driver fails, the whole bearerbox refuses to start. This is not acceptable for production use. 2) When it tries a reconnection (other than first time remember), it doubles the time between attempts, until it reaches a fixed value. If you have retry=yes it will grow until 64 minutes (!!!) and then settles on 60 minutes (too much for production use).Weirdly, if you have retry=no, it will also try to reconnect, but the time between attemps grows only until 10 minutes. Please, let me know comments and votes on this patch. Thank you all. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 emi2_reconnect.patch Description: Binary data
RE: MMS Task Force
I'd like to help here. I don't have experience with WAP, unfortunately. I'll do my best anyway. What do I need? I have access to several SMS-C, several protocols, but no MMS-C. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Alex JuddEnviado el: miércoles 11 de septiembre de 2002 17:04Para: [EMAIL PROTECTED]Asunto: MMS Task Force Devel I'd like to suggest that we put together a team of us to work on getting full MMS support into the CVS tree? I've reviewed the recent submissions from Vjacheslav Chekushin <[EMAIL PROTECTED]> which add SAR to the platform and from my limited reading they look fine (few programming opts. etc.) however we'll need to have a team of focused testers/fixers/developers to ensure it works 100%. Stipe/Andreas/Oded - any of you guys interested? Alex http://www.skywire.co.uk/
[PATCH] emi2 reconnection behaviour
Hi all, Attached is a patch to change the current behaviour of EMI2 driver when handling connection errors.I'm making EMI2 driver consistent with SMPP and SM/ASI behaviour and configuration directives, while trying to fix a couple of things. This is what the patch changes: 1) Removes "retry" smsc config directive for EMI2. It always assumes reconnection, as the rest of drivers.2) Adds a "reconnect-delay" directive, as SMPP and SM/ASI drivers: optional time between attemps in seconds. It defaults to 10 seconds. The reason for this changes (apart from making all drivers consistent), is that current EMI2 handling of reconnection attempts is a mess. Let me explain why: 1) It defaults to not retrying reconnection. That means that when you start bearerbox, if a single EMI2 driver fails, the whole bearerbox refuses to start. This is not acceptable for production use. 2) When it tries a reconnection (other than first time remember), it doubles the time between attempts, until it reaches a fixed value. If you have retry=yes it will grow until 64 minutes (!!!) and then settles on 60 minutes (too much for production use).Weirdly, if you have retry=no, it will also try to reconnect, but the time between attemps grows only until 10 minutes. Please, let me know comments and votes on this patch. Thank you all. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 emi2_reconnect.patch Description: Binary data
[PATCH] SMPP sequence_number
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 FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 smsc_smpp.patch Description: Binary data bearerbox.log Description: Binary data
RE: [PATCH] SMPP validity
>> In that case the calculation to get the difference in minutes may be >> more like >> >> (local_tm.tm_year - gmt_tm.tm_year) * 365*24*60 + >> (local_tm.tm_yday - gmt_tm.tm_yday) * 24*60 + >> (local_tm.tm_hour - gmt_tm.tm_hour) * 60 + >> (local_tm.tm_min - gmt_tm.tm_min ); > >Why would I want to handle years and days when I only need the hour >difference ? Think of 31/12/2002 22:00 GMT, it is 01/01/2003 03:00 GMT+5 for example.
RE: compiler warnings
size_t looks good to me. Angel Fradejas Mediafusion Espana, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Harrie Hazewinkel Enviado el: miercoles 31 de julio de 2002 11:20 Para: dev-kannel Asunto: Re: compiler warnings HI, --On Wednesday, July 31, 2002 12:53 AM +0100 Bruno David Rodrigues <[EMAIL PROTECTED]> wrote: > On Ter, 2002-07-30 at 10:07, Harrie Hazewinkel wrote: >> HI, >> >> I noticed that Stipe fixed compiler warnings after my patch. >> So I thought using '--enable-warnings' to have '-Wall' as compile >> option, but I would like to add additional warnings like >> '-Wmissing-prototypes' and '-Wmissing-declarations'. > > Yes, please, add every -W* required to full debug the compile process. > I've added --enable-warnings to be able to use the -Wall everytime I > make "make" > While adding the various -W* warnings I stumble accros various warnings. I am trying to fix those. But the main one is a signed/unsigned conversion. I believe we better fix these. So, for instance, length and size variable should become all unsigned I could take either unsigned long or size_t and would prefer to use size_t for both is this OK with you all?? Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ --- Author of MOD-SNMP, enabling SNMP management to the Apache server.
RE: EMS - Bitmaps *** URGENT ***
Extended objects are for EMS 5.0. Most (if not all) terminals on the market support EMS 4.2, that do not have extended objects. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Marc Wilhelm Enviado el: lunes 1 de julio de 2002 18:02 Para: '[EMAIL PROTECTED]' Asunto: EMS - Bitmaps *** URGENT *** Hi together, has anybody succeded to generate a EMS that contains a user defined picture (52x20 Bit Black&White)? I have tried to code this into an extended object, but i get no working result... This is VERY URGENT, because i have to finish this until tomorrow... Please help, any suggestions are welcome. Marc P.S.: Goal is to place a BW-Bitmap (52x20) centered on a siemens SL45.
RE: question about the latest kannel
Are you using EMI2? 1.1.4 didn't allow bearerbox to start if some emi2 smsc falied, but on version 1.1.6 you can, using "retry=yes" on the smsc group. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Kaido Karner Enviado el: jueves 27 de junio de 2002 11:36 Para: [EMAIL PROTECTED] Asunto: question about the latest kannel re I'm still using kannel 1.1.4 with my own patches and modifications. However, a number of problems seems to bew solved now with 1.1.6 so I'm thinking about upgrade. I've monitored the list sometimes, but not constantly, so if the question is answered in the list - please forgive me. but, the question is: does the 1.1.6 allow starting of the bearerbox with some/all smsc connections failing? if yes - great. if no - why? regards, kaido
RE: Bug: Status stops working...
We haven't noticed this problem. Boxes running for 2 weeks normally. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded Arbel Enviado el: lunes 24 de junio de 2002 20:16 Para: Stipe Tolj; Steve Rapaport CC: [EMAIL PROTECTED] Asunto: RE: Bug: Status stops working... We didn't have that problems with systems runnign well over a week. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 +972-67-340014 ::.. In the long run, every program becomes rococo, and then rubble. -- Alan Perlis -Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Sent: Monday, June 24, 2002 1:16 PM To: Steve Rapaport Cc: [EMAIL PROTECTED] Subject: Re: Bug: Status stops working... Steve Rapaport wrote: > > This is an old bug that I was sure would eventually be > fixed, but at least on our last recompile (Mar 2002) > it hasn't been. I checked the archives but couldn't find > it mentioned anywhere since then. > > Bug: > Doing a status check using > 'http://127.0.0.1:13100/status?password=word' > > seems to stop working after a while of uptime. > We have programs that check it periodically > and after a few hours, the check begins returning > a null string instead of the usual few paragraphs. > (Of course the programs think that kannel has crashed, > but it hasn't!) > Restarting kannel fixes the problem, but not much > else does. > > We've had this problem with several different kannel versions starting over > a year ago, and I guess it seemed too minor to report, but > if someone's rolling 1.2, maybe it's time to check it out. yep. Has anybody else noticed this one? How many hours does it take to get this state of the admin HTTP interface and in which interval time do your request the status page. This should go into STATUS if others can confirm this issue, IMO. 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
We faced that problem too. But we simply swiched to transceiver mode to
avoid it.
+1 from me.
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
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En
nombre de Oded Arbel
Enviado el: viernes 21 de junio de 2002 00:06
Para: Nisan Bloch; [EMAIL PROTECTED]
Asunto: RE: [PATCH] SMPP
Good - we noticed that too.
+1 for commiting this to the stable branch.
--
Oded Arbel
m-Wise Mobile Solutions
[EMAIL PROTECTED]
Mobile: +972-67-340014
Tel: +972-9-9581711 (ext: 116)
::..
This book fills a much-needed gap.
-- Moses Hadas in a review
> -Original Message-
> From: Nisan Bloch [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 20, 2002 11:21 PM
> To: [EMAIL PROTECTED]
> Subject: [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: [patch] smsbox memory leaks and service header
> >(log processing is that simple that I'm generating it >every 5 minutes) > I do it realtime with a sql accounting database, wich kannel feeds directly. It's not a problem for me this patch is not commited. I just thought the service field was more appropiate to reflect an external service routing. 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: Time.date not right
Another top-10 question for the FAQ -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Alan McNatty Enviado el: viernes 7 de junio de 2002 03:04 Para: Kannel Dev Asunto: Re: Time.date not right kannel logs by default in gmt not localtime ... ./config --enable-localtime if you want localtime. On Fri, 2002-06-07 at 06:58, Patrick Mignott wrote: > hi all, > i see that the time/date in the kannel.log file logging wrong, it's 4 hour faster then the BOIS time why?
RE: [REPOST] emi2 MO timestamps (was: bug withdate_convert_universal() )
>Yes, now. I'm suggesting to change that : set it up so that time stamps >are treated as GMT if enable-localtime isn't set, and as local >timestamps otherwise. I'm afraid that is not enough. MO timestamps come in localtime from the SMSC point of view, not the ESME point of view. So, if you connect to several SMSC (each one in a different country), one timestamp could be GMT+1 and another GMT+7 So a different timezone correction is needed for each smsc. This leads to a smsc config directive timezone=GMT+N in my opinion. 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: [REPOST] emi2 MO timestamps (was: bug withdate_convert_universal() )
I use --enable-localtime, but that has nothing to do with emi2 MO timestamps, has it? --enable-localtime applies only to log messages, I think. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded Arbel Enviado el: miércoles 5 de junio de 2002 09:09 Para: Kannel Developers Asunto: RE: [REPOST] emi2 MO timestamps (was: bug withdate_convert_universal() ) The module can be changed to assume GMT time by default and localtime if compiled with --enable-localtime. would that be a good solution ? -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. "Nothing helps a bad mood like spreading it around." -- Calvin and Hobbes > -Original Message- > From: Alan McNatty [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 04, 2002 11:31 PM > To: Kannel Developers > Subject: Re: [REPOST] emi2 MO timestamps (was: bug > withdate_convert_universal() ) > > > Hi Angel, > > I am not farmiliar with the emi2 code but have noticed that > that kannel > can be configured to run in GMT or localtime. My logs where > printing GMT > which is confusing - someone from the list pointed out that you can > compile and enable localtime (./configure --enable-localtime ). You > might like to try this. > Cheers, > Alan > > ps. I don't see this as a problem with kannel although it > makes having a > binary download less useful. As a result I _have to_ compile > from source > - the debian 1.1.5 package exhibits this problem too - I have notified > the maintainer. I guess it just ends up being extra work for distro > maintainers to ensure that kannel packages comply with defacto > standards, etc. > > On Wed, 2002-06-05 at 06:19, Angel Fradejas wrote: > > Andreas Fink wrote: > > >this is definitively the case. The EMI timestamps are also is in > > >LOCAL TIME, not GMT > > > > The current code asumes GMT timestamps from the SMS-C and > this is not the > > case (at least with the providers I connect). > > > > Does anybody need the current behaviour? > > > > Or can we fix it? > > > > > > 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 > > > > > > > > > -- > 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) > >
[REPOST] emi2 MO timestamps (was: bug with date_convert_universal() )
Andreas Fink wrote: >this is definitively the case. The EMI timestamps are also is in >LOCAL TIME, not GMT The current code asumes GMT timestamps from the SMS-C and this is not the case (at least with the providers I connect). Does anybody need the current behaviour? Or can we fix it? Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08
RE: Bind Tranceiver implementation.
Bind transceiver is supported directly by cvs version of kannel. Just use transceiver-mode = yes and unset receive-port on your smpp config. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Gustavo Sepulveda Enviado el: martes 4 de junio de 2002 19:26 Para: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Asunto: Bind Tranceiver implementation. Hello guys: I would like to know yours opinion about implementing connections with bind tranceiver towards the ESME. Most of products based in SMPP, uses Bind Transmitter and Bind Receiver to send and to receive SMS from the ESMEs.Kannel even does this. Are there reason to implement the Bind Tranceiver is these solutions? I was trying modify smpp pdu from kannel for use Bind Tranceiver, but i don't know where the PDU structure is located and how can affect this modification to bearer box o smsbox. Thanks for your help. Regards Gustavo Sepulveda _ Únase con MSN Hotmail al servicio de correo electrónico más grande del mundo. http://www.hotmail.com
RE: [RFC] mcc and mnc
>In this case I suggest you're backend system should know the prefix of >the MO message, hence your backend system has to figure out from which >network the request is coming by parsing the prefix number value. Yes Stipe, but this is mainly guessing, because of mobile number portability. Here in Spain it is not a big problem (about 1% of numbers) but I think in Germany this percentage is bigger (please, correct me if I'm wrong). If you are absolutely sure in the entry point of the MO (kannel) of what is the mobile operator, why guess later? 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] mcc and mnc
>Since the smsc_id in the MO is set by the driver, and this only applies >to custom/proprietery or future drivers, I think that setting the smsc_id >of the MO to something that represents the mcc/mnc will suffice (maybe a >concatenation of their values), and is a good solution. Yes Oded, that was an option I evaluated too. But then you have all of your routing rules (allowed-smsc-id, preferred-smsc-id, denied-smsc-id) invalidated (as MO smsc_id is copied to MT), or extremely bloated (you would have to declare every mcc-mnc combination) or you would have to mess around later in the application handling the MO to output a X-Kannel-SMSC header to correct it. >So my opinion is that if the implementation is clean - it will do no >harm and potentioally can do good. Thx, Oded. Angel Fradejas Mediafusin Espa a, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
RE: [RFC] mcc and mnc
>>Not true in multi-operator links. > >if your multi-operator incoming link tells you the original SMSC the >message comes from (passing the %i) then youre back in business. If >you implement mnc and mcc and the multi-operator link doesnt tell you >this, you're back to square one, hence the original smsc name is as >good as mnc and mcc. Better a practical (and simplified) example: you have only one link group = smsc smsc-id = custom_driver_whatever smsc = custom_type The protocol of this link tells you (in one way or another) the operator originating the MO. Your %i will be "custom_driver_whatever". Hope this clarifies. Angel Fradejas Mediafusion Espana, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
RE: [RFC] mcc and mnc
>Angel, what you want to do is to allow to forward mcc and mnc values >that have to be entered by the system admin by hand to each smsc >group, which means Kannel is only storing and forwarding still >statical information. This blows only unnecessary the code of Kannel >up. > >You can distunguish in each called sms-service from which smsc group >the request came in, hence your backend system should deal with the >translation from smsc-id to mnc, mcc pairs IMO. Not true in multi-operator links. This is mainly the kind of situation I was triyng to deal with. As I said before, fixed directives for direct operator links, copying theses attributes to msg->sms.mcc/mnc members. And then, if a link deals with several mcc and mncs, the driver could get (if possible) the values from the provider and set them in msg->sms.* I'm doing it with success. And I see no reason to think I'm a extremely rare case if SMS bussiness. (Btw, the solution of having one sms-service for each service/operator combination is simply impractical. We have as much as 5000+ services - we are a content developer and provider - so figure yourself). We have a working and practical kannel for a small number of services and smscs. Let's work towards a practical kannel for a huge number of them. (note when I say "let's work" I mean "i would contribute my working solution if anybody is interested"). 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] mcc and mnc
Title: Re: [RFC] mcc and mnc smsc-id is almost as good, but not completely. mcc and mnc are normalized values, and when you have for example 20 connections to the same operator (as I do, one emi2 link for each short code), if you use smsc-id you'll have to translate this value in every application behind kannel, wich is error prone. I know kannel doesn't have a way to know mcc and mnc, that's why i suggest smsc directives. But for extensibility (i mean custom drivers) it would be a good thing: for example, a custom NetSize driver we have developed, gets mcc and mnc information directly from the provider, as you can have any mcc and mnc through this link. In this situation, neither using %i or appendind &mcc=xx&mnc=xx would work. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 -Mensaje original-De: Andreas Fink [mailto:[EMAIL PROTECTED]]Enviado el: lunes 3 de junio de 2002 19:00Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: Re: [RFC] mcc and mnc A question for all developers, What do you think about having kannel pass mnc and mcc information to applications? Sometimes applications need to know the operator for the incoming MO (a logo download application being the typical example), and kannel is the closer element to the operator (and so the most reliable point to declare this info, so you have not to guess based on the mobile number). You can do that by adding &mnc=xxx&mcc=yyy inside the service definition passing those values as a constant string. So you would have an entry for every logo cgi for every SMSC connection. Or you could simply use the %i which is the smsc name. Kannel has no way of knowing which MNC and MCC goes with which SMSC so the smsc name is as good as anything else. -- Andreas FinkFink-Consulting--Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, SwitzerlandE-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com--Something urgent? Try http://www.smsrelay.com/ Nickname afink
[RFC] mcc and mnc
A question for all developers, What do you think about having kannel pass mnc and mcc information to applications? Sometimes applications need to know the operator for the incoming MO (a logo download application being the typical example), and kannel is the closer element to the operator (and so the most reliable point to declare this info, so you have not to guess based on the mobile number). So we could have mcc=xx and mcc=xx directives in every sms-c (for direct operator connections), or in the case you have a multi-operator link (a NetSize o MobileWay one for example), we could give the driver the chance to set those attributes in msg->sms.mcc and msg->sms.mnc members, if possible. Maybe I am missing something obvious, but this is a thing I have implemented and find extremely useful. Comments? Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08
RE: [patch] smsbox memory leaks and service header
You are right, that's exactly what I want. The reason is that we collect all the accounting information from kannel. Anyway, if nobody else sees utility for this, I'll keep that in our corporate patches. No need for a religious discussion ;-) Angel FRADEJAS Director de Investigación y Desarrollo Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 _ Mediafusión España, S.A. ® Aviso legal: Este mensaje electrónico está dirigido únicamente a la(s) dirección(es) indicadas anteriormente; el carácter confidencial, personal e intransferible del mismo está protegido legalmente. Cualquier revelación, uso o reenvío no autorizado, completo o en parte, está prohibido. Si ha recibido este mensaje por equivocación, notifíquelo inmediatamente a la persona que lo ha enviado y borre el mensaje original junto con sus ficheros anexos sin leerlo ni grabarlo, total o parcialmente. Gracias. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded Arbel Enviado el: domingo 2 de junio de 2002 19:26 Para: Angel Fradejas CC: Kannel Developers Asunto: RE: [patch] smsbox memory leaks and service header Let me see if I get this correctly : you want to be able to set, in the HTTP response for a GET or POST query generated by sms-service, the service name for the MT generated from that response. right ? What is it good for ? the only reason I can think of doing it is to have the kannel logs log the dynamic service routing you are doing in the application. why would you want to do that ? -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. I asked my baby if there'd be some way She said she'd save her love for a rainy day I looked in the sky but I look in vain Heavy cloud but no rain. - Sting (Gordon Summer) (Heavy Cloud No Rain/Ten Summoner's Tales) > -Original Message- > From: Angel Fradejas [mailto:[EMAIL PROTECTED]] > Sent: Sunday, June 02, 2002 6:52 PM > To: Bruno Rodrigues > Cc: Kannel Developers > Subject: RE: [patch] smsbox memory leaks and service header > > > >> 2) allow to change msg->sms.service via X-Kannel-Service > header or xml > tag > >Why should you change the sms.service ? > > > >sms.service is the name field in configuration, for sms-service and > >sendsms-user, so you can identify the service or username used, in > >bearerbox_access.log. > > > >We shouldn't give access to clients connecting through http. > >I vote -1 for this part > > It was intended to identify sms-service, not for smssend > requests, as I do > my service routing outside kannel: every MO goes to default > sms-service, > then the application routes to appropiate service. I wanted > to pass the > service handling the MO back to kannel. > > I could rework the patch to allow this X-Kannel header only > on MO handling. > Does this sound better to you? > > > 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] smsbox memory leaks and service header
>> 2) allow to change msg->sms.service via X-Kannel-Service header or xml tag >Why should you change the sms.service ? > >sms.service is the name field in configuration, for sms-service and >sendsms-user, so you can identify the service or username used, in >bearerbox_access.log. > >We shouldn't give access to clients connecting through http. >I vote -1 for this part It was intended to identify sms-service, not for smssend requests, as I do my service routing outside kannel: every MO goes to default sms-service, then the application routes to appropiate service. I wanted to pass the service handling the MO back to kannel. I could rework the patch to allow this X-Kannel header only on MO handling. Does this sound better to you? 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
[patch] smsbox memory leaks and service header
Hi all, here's a patch for smsbox.c 1) a couple of memory leaks (msg->sms.udhdata and accepted_chars) 2) allow to change msg->sms.service via X-Kannel-Service header or xml tag Cheers. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08 smsbox_service.patch Description: Binary data
RE: Daily patch: gateway
Our mails crossed, sorry Harrie. -Mensaje original- De: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] Enviado el: viernes 31 de mayo de 2002 11:41 Para: Stipe Tolj; Angel Fradejas CC: Kannel Developers Asunto: Re: Daily patch: gateway --On Friday, May 31, 2002 10:17 AM +0200 Stipe Tolj <[EMAIL PROTECTED]> wrote: > Angel, > >> > File gateway/gw/bb.h changed from revision 1.5 to 1.6 >> > File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 >> > File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 >> > File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 >> > File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 >> > File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 >> > File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 >> >> All this files have been changed without documentation on ChangeLog. Some of those, I chnaged and I did not edit ChangeLog, since I thought that was updated automatically with the CVS message provided at commit. I will put the same message in ChangeLog. Sorry about that. Harrie Internet Management Consulting mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/
RE: Daily patch: gateway
Harrie please, Would you be so kind as to comment these changes in ChangeLog? They're somewhat described in a post from May 25 (subject: changes to the heartbeat code.) Thanks. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: viernes 31 de mayo de 2002 10:18 Para: Angel Fradejas CC: Kannel Developers Asunto: Re: Daily patch: gateway Angel, > >File gateway/gw/bb.h changed from revision 1.5 to 1.6 > >File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 > >File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 > >File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 > >File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 > >File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 > >File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 > > All this files have been changed without documentation on ChangeLog. > > Please, this is important as we have to follow potential problems to keep > using HEAD of CVS. right, I agree. Could you please lookup who did the commits and post the request directly to hin/her (ehmmm, we don't have a 'her' yet, do we ;)) 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: SMSC Connection
You could use keepalive = 60 for example, in your smsc emi2 connection. That way kannel will keep your connection opened by sending heartbeat messages to your smsc. Your smsc will have to support that of course (ucp operation 31). Angel Fradejas. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de fellyEnviado el: jueves 30 de mayo de 2002 12:23Para: [EMAIL PROTECTED]CC: [EMAIL PROTECTED]Asunto: SMSC ConnectionHi, I use the following configuration file with kannel 1.1.6 : - group = core admin-port = 13003 smsbox-port = 13013 admin-password = [ password ] log-file = "/var/log/kannel/1133.log" log-level = 5 access-log=/var/log/kannel/access1133.log box-allow-ip = "127.0.0.1" admin-allow-ip = "127.0.0.1" # SMSC EMI group = smsc smsc = emi2 smsc-id = 1133 host = [ the ip ]] port = [ the port ] our-port = [ port ] receive-port = [ port ] flow-control = 1 group = smsbox bearerbox-host = localhost #user-allow-ip = "127.0.0.1" sendsms-port = 31133 global-sender = 1133 access-log = "/var/log/kannel/smsbox1133.log" group = sms-service name = 1133 keyword = default catch-all = true max-messages = 0 omit-empty = true send-sender = true post-url = "http://127.0.0.1:80/rcv.php?opid=2&service=%i&sender=%p&udh=%u&text=%a" accept-x-kannel-headers = true group = sendsms-user username = [ username ] password = [ password ] The SMSC I connect with does not have implemented the module for authentication with username and password. My problem is that the SMSC disconnects me if i don't send messages for a half an hour. When I get the status via http, bearerbox responds that connection is "online". netstat reports also an "ESTABLISHED" connection with SMSC, so I don't even know if I can receive messages. How can I solve this problem? Felly
RE: Daily patch: gateway
>File gateway/gw/bb.h changed from revision 1.5 to 1.6 >File gateway/gw/bb_smscconn.c changed from revision 1.45 to 1.46 >File gateway/gw/heartbeat.c changed from revision 1.2 to 1.3 >File gateway/gw/heartbeat.h changed from revision 1.1 to 1.2 >File gateway/gw/smsbox.c changed from revision 1.198 to 1.199 >File gateway/gw/smsc_smpp.c changed from revision 1.67 to 1.69 >File gateway/gw/wapbox.c changed from revision 1.148 to 1.149 All this files have been changed without documentation on ChangeLog. Please, this is important as we have to follow potential problems to keep using HEAD of CVS. Cheers. 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: CVS usage question??
Maybe line-feed format has been changed from unix-like to dos-like. This could happen if you use Windows based tools to edit, etc. Angel. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded Arbel Enviado el: miércoles 29 de mayo de 2002 16:54 Para: Harrie Hazewinkel; dev-kannel Asunto: RE: CVS usage question?? It's possible, if your editing tool reformats tabs and removes spare spaces and such. try to diff all the changes agains the current cvs, and then edit the diffs and remove everything that isn't requires for the patch. then you can checkout from the CVS again, apply the diffs you've edited and commit. Alternativly you can either switch to another code editor, or - commit all the files anyway and hope that your editor will not change any more files. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. Was it Ritchie or Thompson who said about X: "Sometimes, when you fill a vacuum, it still sucks"? > -Original Message- > From: Harrie Hazewinkel [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 29, 2002 2:29 PM > To: dev-kannel > Subject: CVS usage question?? > > > HI all, > > I wanted to commit changes in the gw directory. Although, only > 5 of the many files were changed. But in the 'cvs commit' it > showed almost all files to be chnaged. > > Has anyone seen it before?? > > > Harrie > > Internet Management Consulting > mailto:[EMAIL PROTECTED]http ://www.mod-snmp.com/ > > >
RE: Patch submission and release policy (Was: [PATCH] problems with HTTPS and base support for per message billing)
>If we start doing >architectural changes on the CVS, while everyone is using it to build >their production, we will break things for people who don't/can't know >how to handle it. >So a branch is a must before doing any major surgery on the code. Totally agree. [ Even if I am a "CVS bad guy(tm)" ] 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: Http request & kannel
This is a question I wanted to work at. It is on my todo list, but didn't have the time yet. My opinion is that if smsbox can't fetch content from a web server, it must queue that request, and try again later, with a specified delay between requests, instead of the current "couldn't fetch content" reply. Any other opinions about this? 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Cipher Strength Enviado el: lunes 6 de mayo de 2002 17:28 Para: [EMAIL PROTECTED] Asunto: Http request & kannel Hi All, I am using development relase 1.1.6 . I have noticed that when kannel fetch content from url set in sms-service and the web server is not running at that time, it just stop fetching content from other web servers too. Why is it soo. Is it feature or bug. In coreaccess.log i just see Receive entries. Regards CIPHER _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
RE: sendsms and smsc parameter
Kannel will route the messages to smsc-id=A, unless it is offline (status=connecting,reconnecting), in that case it would route it to smsc-id=B. If you want to avoid that possibility, use allowed-smsc-id. smsc-id = A preferred-smsc-id = A allowed-smsc-id = A .. .. smsc-id = B preferred-smsc-id = B allowed-smsc-id = B 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andrea Viscovich Enviado el: viernes 26 de abril de 2002 20:26 Para: Stipe Tolj CC: [EMAIL PROTECTED] Asunto: Re: sendsms and smsc parameter Well, I'm sorry Stipe. I just thought that setting smsc was enought, instead I realized that I should set preferred-smsc-id to themselves for each smsc group, and now it works. Just one question. Now I have .. smsc-id = A preferred-smsc-id = A .. .. smsc-id = B preferred-smsc-id = B ... etc. for each modem. If I send 10 sms setting smsc=A they will be all delivered by A or after the first one kannel detects A is busy and forward it to B? Thanks Andrea - Original Message - From: "Stipe Tolj" <[EMAIL PROTECTED]> To: "Andrea Viscovich" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, April 26, 2002 6:35 PM Subject: Re: sendsms and smsc parameter > Yes the docs tell the truth. > > In general specifying a "&smsc=foobar" in the GET request should route > the message to the specific smsc-id = "foobar". > > Can you provide us a kannel.conf setup and example GET request where > this is failing? > > 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: Accounting with Kannel
EMI driver reports 2 messages received for each MO in /status. A better solution for accounting would be kannel.access parsing, for example. Or integrate kannel with an accounting database, as I did. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Filipe Múrias Enviado el: jueves 25 de abril de 2002 0:46 Para: devel Asunto: Accounting with Kannel Hi people! I've been using Kannel status (via admin web interface) to do SMS accounting for each one of my large accounts. The problem is that the number of transfered messages Kannel reports is much higher than the actual value. Does anybody have this problem ? Is it due to the fact that I have the EMI keepalive feature turned on (30 sec.) ? Are the keepalive messages counted too ? Can you tell me about a nice solution to do accounting with Kannel ? I'm using Kannel 1.1.6 on a RedHat 7.2 box. Thank you. Filipe Múrias
RE: [Fwd: Daily patch: gateway]
I think it's good to keep old changelogs, as they are valuable to see how things are going, and even they are useful if something breaks suddenly. Probably changelog tells you the one to blame ;-) doc/changelog.*.*.* seems a good place. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Bruno Rodrigues Enviado el: jueves 18 de abril de 2002 18:34 Para: Stipe Tolj CC: [EMAIL PROTECTED] Asunto: Re: [Fwd: Daily patch: gateway] - Original Message - From: "Stipe Tolj" <[EMAIL PROTECTED]> To: "Bruno Rodrigues" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, April 18, 2002 4:31 PM Subject: Re: [Fwd: Daily patch: gateway] > Bruno Rodrigues schrieb: > > > > Can't we split changelog to some kind of > > old changelog.1.1.0, changelog.1.1.1 > > to prevent it from beeing so large ? > > Good idea. Do you intend to branch it off or are we going to cut it > off any continue in the HEAD branch?! I was thinking in just splitting it, but I don't know where to. doc/old/changelog.*.*.* ? > > 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: Reporting the number of message parts sent for long messages.
Like Oded, our applications don't send SM to multiple receivers, but adding that information seems the right thing to do. My vote is +1 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: jueves 18 de abril de 2002 13:41 Para: Oded Arbel CC: Kannel-devel (E-mail) Asunto: Re: Reporting the number of message parts sent for long messages. Oded Arbel wrote: > > I didn't like the fact that you removed the reporting from the 'error' > section in smsbox_req_handle - correct me if I'm wrong, but this way, if > a split message is sent to multiple receivers, and some of them fail, > the calling application can't tell how many messages were sent to the > receivers that didn't fail. or at least, that is my understanding of the > code. you're right. Any votes for adding the SMS split information even if some of the multi-requests fail? I'm +0 for this. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: Reporting the number of message parts sent for long messages.
It was my way to return the number of messages sent (splits), as I didn't want to change the semantics for send_message() return value. 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 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: miércoles 17 de abril de 2002 11:26 CC: Kannel-devel (E-mail) Asunto: Re: Reporting the number of message parts sent for long messages. why did you change the send_message() declaration? what's the argument int* nparts for? 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: Reporting the number of message parts sent for long messages.
Hi Oded, For what it's worth, this was my version of the patch. Nothing special, really. Anyway, now yours it's commited on cvs, so I'll stick to it. A couple of modifications on my calling applications and I'm done. This patch is against smsbox.c revision 1.183 Have fun. 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 -Mensaje original- De: Oded Arbel [mailto:[EMAIL PROTECTED]] Enviado el: martes 16 de abril de 2002 15:02 Para: Angel Fradejas CC: Kannel-devel (E-mail) Asunto: RE: Reporting the number of message parts sent for long messages. Can we see your patch too ? I'm not very good at formatting, so you'r patch may likely be better :-) -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] (972)-67-340014 (972)-9-9581711 (ext: 116) ::.. Get busy living or get busy dying. -- Andy Dufresne (Tim Robbins) in The Shawshank Redemption > -----Original Message- > From: Angel Fradejas [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 16, 2002 1:39 PM > To: Stipe Tolj > Cc: Kannel-devel (E-mail) > Subject: RE: Reporting the number of message parts sent for > long messages. > > > +1 from me > > I had written the same patch for my own use, with a slightly different > format. > > Angel Fradejas. > > -Mensaje original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]En > nombre de Stipe Tolj > Enviado el: martes 16 de abril de 2002 13:35 > CC: Kannel-devel (E-mail) > Asunto: Re: Reporting the number of message parts sent for long > messages. > > > > For some purposes (for example - billing) the application > behind Kannel > > may need to know how messages Kannel actually sent for each > message that > > the application sent to Kannel (as Kannel will split long > messages into > > parts). > > for this prurpose I wrote this hack - it's very simple and not well > > written, but it allowes the application to analyze the response from > > smsbox in order to learn how many msg parts the message was > splitted to. > > > > I would like the opinion of the developers on the usefullnes of this > > behaviour, and how do you think it should be cleaned/standardized. > > I'm +1 for this as it does not change send_message() behaviour and > adds extra information at return. > > Any objections for commiting this? > > Stipe > > [EMAIL PROTECTED] > --- > Wapme Systems AG > > Münsterstr. 248 > 40470 Düsseldorf > > Tel: +49-211-74845-0 > Fax: +49-211-74845-299 > > E-Mail: [EMAIL PROTECTED] > Internet: http://www.wapme-systems.de > --- > wapme.net - wherever you are > > > smsbox.patch Description: Binary data
RE: Reporting the number of message parts sent for long messages.
+1 from me I had written the same patch for my own use, with a slightly different format. Angel Fradejas. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: martes 16 de abril de 2002 13:35 CC: Kannel-devel (E-mail) Asunto: Re: Reporting the number of message parts sent for long messages. > For some purposes (for example - billing) the application behind Kannel > may need to know how messages Kannel actually sent for each message that > the application sent to Kannel (as Kannel will split long messages into > parts). > for this prurpose I wrote this hack - it's very simple and not well > written, but it allowes the application to analyze the response from > smsbox in order to learn how many msg parts the message was splitted to. > > I would like the opinion of the developers on the usefullnes of this > behaviour, and how do you think it should be cleaned/standardized. I'm +1 for this as it does not change send_message() behaviour and adds extra information at return. Any objections for commiting this? Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: bearerbox crash down
It's a limit with checking-malloc. You should compile with native malloc, if I rebember it is done by ./configure --with-defaults=speed Angel Fradejas. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de samEnviado el: lunes 15 de abril de 2002 8:19Para: [EMAIL PROTECTED]Asunto: bearerbox crash downWhen I send large numbers of sms request to the gateway at once,the bearerbox often crash down£¬and the log response like this: "Cannot have more than 21845 allocations at once",is it mean that the gateway have any limit? ŵ»ùÑÇ Ä¦ÍÐÂÞÀ Î÷ÃÅ×Ó ÁåÉùͼƬ·ÅËÍ TOM¶ÌѶ ¸ü¶à¾«²Ê>> ²£Á§Ð¬(Ö£ÐãÎÄ)Æôʾ¼(лöª·æ) Óи£Æø(³Â»ÛÁÕ)ÌìʹÀ¶(ºÎíÊ«) Áµ°®´ó¹ýÌì(twins)Heartbeat(ÈÝ×æ¶ù) ÒõÌì(ĪÎÄε)Ψһ(ÍõÁ¦ºê) ¸É±£¬ÅóÓÑ(ÌïÕð)Äã¿ì»ØÀ´(Ëïéª)
RE: Problem..
Hi all, You have to use catch-all = true in the sms-service declaration for "fslogo" and "fslogo 232" to match, I think. Hope that helps. Angel Fradejas. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Bruno David Rodrigues Enviado el: jueves 28 de marzo de 2002 20:57 Para: Stefan Cars CC: Kannel-devel (E-mail) Asunto: Re: Problem.. I've tested it just now and everything works ok. when I send fslog, I receive a "service unavailable" (the reply-couldnotfetch) when I send "fslog a", I receive the default service exactly the reverse of what you say. Which version are you using ? - Original Message - From: "Stefan Cars" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 28, 2002 4:24 PM Subject: Problem.. > I've set this up: > group = sms-service > keyword = fslogo > url = "" > accept-x-kannel-headers = 1 > omit-empty = 1 > concatenation = 1 > max-messages = 0 > > > When sending "fslogo 232" everything works fine but when sending "fslogo" > without anything after it. It doesn't match, it instead goes to the > default... Why ? Is this a feature or a bug ? > > / Stefan > > >
RE: gwlib/date.c bug you reported
Absolutely right I guess.
Angel Fradejas.
-Mensaje original-
De: Stipe Tolj [mailto:[EMAIL PROTECTED]]
Enviado el: martes 26 de marzo de 2002 12:41
Para: Angel Fradejas
CC: [EMAIL PROTECTED]
Asunto: Re: gwlib/date.c bug you reported
what about doing this in gw/smsc_emi2.c:664:
else {
unitime.year += 2000; /* Conversion function expects full year */
unitime.month -= 1;
msg->sms.time = date_convert_universal(&unitime);
}
this would pass the right month base to the date_convert_universal()
routine?!
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: gwlib/date.c bug you reported
Hi Stipe, This change was made to fix a problem with EMI2 timestamps. The EMI2 driver gets the timestamp from the UCP frame, and calls date_convert_universal(). The problem is that EMI2 timestamps have 1-based months, and date_convert_universal() expects 0-based months (date.c v1.8). So it returns a timestamp that is 1-month ahead, or even worst, it tries to access monthstart[12] wich is out of bounds and dumps core. I suggested changing date_convert_universal() to accept 1-based months: that fixed EMI2 behaviour, but as you can see, broke other things: smsc_http.c for example calls date_convert_universal() with 0-based months. And now checks/check_date complains as well. So IMHO the best solution is to maintain date.c v1.8, and fix the EMI2 behaviour in smsc_emi2.c, to properly build timestamps for MO messages. I think we should consider this EMI2 MO timestamps mis-behavior as a release show-stopper. Angel Fradejas. -Mensaje original- De: Stipe Tolj [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 11:50 Para: Angel Fradejas CC: [EMAIL PROTECTED] Asunto: gwlib/date.c bug you reported Hi Angel, can you please see http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/gwlib/date.c.diff?r1 =1.8&r2=1.9 and tell me exactly why this change was necessary? I'm getting failure reports now from checks/check_date that does reverse date conversion. Until we have not cleanly resolved this, I'm going back to revision 1.8 to make the check routines happy. 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] feature freeze?!
Hello,
I think the source and destination TON patch for SMPP should go in before
freezing. Many of us have to manually hack the code after each release to
get it working.
* smsc_smpp.c source and destination TON
Posted by: Alex Judd <[EMAIL PROTECTED]
Message-ID:
<[EMAIL PROTECTED]>
Also, I consider important all of the timestamping issues: emi2, at2 the
most, also the http one (thread "bug with date_convert_universal" discussed
this month), because of the traffic accounting many of us have to do.
Last, of course, I have a good use for my patch
* SMSC specific default-sender and forced-sender
Posted by: "Angel Fradejas" <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Updated: <[EMAIL PROTECTED]>
and remember some other please who could use it, but maybe it is not of
general interest.
My two cents.
Angel Fradejas.
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En
nombre de Stipe Tolj
Enviado el: miércoles 20 de marzo de 2002 17:54
Para: [EMAIL PROTECTED]
Asunto: [RFC] feature freeze?!
Hi there,
when are we going to feature freeze the cvs tree?
What patches are still open? I see a couple of submissions to the
devel@ list but yet to change in the STATUS file. Please heads up for
anyone of the developers who wants this to go in before freezing.
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: msg->sms.smsc_id versus cfg_get(grp, octstr_imm("smsc-id"))
Having a preferred-smsc would do what you want in most cases (unless the
specified smsc is not online, in that case, kannel would route it to another
smsc in absence of allowed-smc/denied-smsc.
group = smsc
smsc-id = testsmsc1
preferred-smsc-id = testsmsc1
Hope it helps.
Angel Fradejas.
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En
nombre de Bruno David Rodrigues
Enviado el: miércoles 20 de marzo de 2002 17:25
Para: Alex Judd; [EMAIL PROTECTED]
Asunto: Re: msg->sms.smsc_id versus cfg_get(grp, octstr_imm("smsc-id"))
it's not easy to do that in the current code.
You'll have to have a preferred-smsc in your smsc group
or even an allowed-smsc/denied-smsc
what I'm thinking to do is to have a default prefered smsc, like
if the message has a msg.smscid=A, it should preferelly go through A
- Original Message -
From: "Alex Judd" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 20, 2002 4:17 PM
Subject: msg->sms.smsc_id versus cfg_get(grp, octstr_imm("smsc-id"))
> I think I'm trying to convince Kannel to do something that it doesn't want
> to do and appreciate some input from the list.
>
> Objective: Receive /cgi-bin/sendsms message and send through specific SMS
>
> What happens is that when I specify the smsc= parameter to try and force
> the message to go through that SMSC it is tagging the message as coming
> from that SMSC, rather than sending it through the SMSC I specify
>
> The SMSC it sends through seems to be random depending on which thread it
> wakes up and that SMSC has it's ID specified in the configuration file.
>
> Therefore what I'd like to do is when we go to wakeup or create the SMSC
> needed, to create it according to the msg->sms.smsc == cfg_get(grp,
> octstr_imm("smsc-id")) rather than being random
>
> Does this sound correct and where in the process does Kannel decide which
> smsc to connect to?
>
> Thanks in advance
>
> Alex
>
> --
> Alex Judd
> http://www.skywire.co.uk
>
>
>
RE: bug with date_convert_universal()
>>Okay, someone sent me the CMG EMI 3.5 spec. The only specification >>of the date format it has is "DDMMYYhhmmss" without further explanation. >>Since we have evidence of at least one EMI SMSC using 1-based months, >>shall we assume that they all do? It would make sense, if the lack of >>specification means that the date format is intended to be human-readable. >this is definitively the case. The EMI timestamps are also is in >LOCAL TIME, not GMT Yes, that's right. My SMSC works with 1-based months and local time. So it seems we cannot use date_convert_universal as it is for EMI2 timestamps. Besides the 1-based/0-based month problem, it assumes GMT timestamps. Angel Fradejas.
RE: bug with date_convert_universal()
Oded, Sorry for misleading you. The code in date_convert_universal is correct now. It was corrected in version 1.9 as you can see in CVS. It assumes 1-12 input, as you correctly pointed out. The problem is the comment in date.h. I said just the opposite that I wanted to say :-( Angel Fradejas. -Mensaje original- De: Oded Arbel [mailto:[EMAIL PROTECTED]] Enviado el: lunes 11 de marzo de 2002 20:07 Para: Angel Fradejas; Kannel-devel (E-mail) Asunto: RE: bug with date_convert_universal() Current CVS assumes that month is 1 - 12, while comments in date.h disgrees by suggesting 0 - 11 range - as quoted by you. This sounds like a problem to me, where one of these have to be fixed. -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] Every person has his price. Mine is $3.95. > -Original Message- > From: Angel Fradejas [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 11, 2002 8:53 PM > To: Oded Arbel; Kannel-devel (E-mail) > Subject: RE: bug with date_convert_universal() > > > Hi Oded, > > Take a look at my posts about "timestamps with emi2" from > January 14h. This > was corrected because date_convert_universal precisely > assumed 1-12 input, > instead of the correct 0-11. > > Also, taken from date.h > > long month;/* 0-11 */ > > Hope this helps. > > Angel Fradejas. > > > -Mensaje original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]En > nombre de Oded Arbel > Enviado el: lunes 11 de marzo de 2002 18:20 > Para: Kannel-devel (E-mail) > Asunto: bug with date_convert_universal() > > > Hi list. > > date_convert_universal() get a "universaltime" structure as > input, which > its month member is defined as having a range of 0 to 11, but > date_convert_universal assumes that it will get the month as > 1-12 - from > the code : > date += monthstart[t->month-1] * DAY; > > -- > Oded Arbel > m-Wise Inc. > [EMAIL PROTECTED] > > I do not fear Satan half so much as I fear those who fear him. > -- Theresa of Avila > >
RE: bug with date_convert_universal()
Hi Oded, Take a look at my posts about "timestamps with emi2" from January 14h. This was corrected because date_convert_universal precisely assumed 1-12 input, instead of the correct 0-11. Also, taken from date.h long month;/* 0-11 */ Hope this helps. Angel Fradejas. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded Arbel Enviado el: lunes 11 de marzo de 2002 18:20 Para: Kannel-devel (E-mail) Asunto: bug with date_convert_universal() Hi list. date_convert_universal() get a "universaltime" structure as input, which its month member is defined as having a range of 0 to 11, but date_convert_universal assumes that it will get the month as 1-12 - from the code : date += monthstart[t->month-1] * DAY; -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] I do not fear Satan half so much as I fear those who fear him. -- Theresa of Avila
RE: [RFI] octstr_recode
Catenation should be driver independant, shouldn't it? -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded Arbel Enviado el: miércoles 6 de marzo de 2002 17:56 CC: [EMAIL PROTECTED] Asunto: RE: [RFI] octstr_recode Shoot me if I missed something obvious, but why shouldn't the smsc modules do the incoming catenation ? -- Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- Freedom from incrustations of grime is contiguous to rectitude. > -Original Message- > From: Andreas Fink [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 06, 2002 5:40 PM > To: Bruno David Rodrigues > Cc: [EMAIL PROTECTED] > Subject: Re: [RFI] octstr_recode > > > > > What I am missing besides that is incoming support for > UDH so we can > >> receive incoming a ringtone or similar. So a %u could be used (if > >> thats not taken). > > > >Incoming udh will have to wait until we have incoming concatenation > >I'm now thinking about a way to do it :) > > > incoming concatenation could be done later if we already support UDH > we could at least reconcatenate inside the application. > > > -- > > 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: [RFY] Unicode in MO Messages and other patch
That's is the kind of situations I was trying to fix with my default-sender / forced-sender patch. But I chose a driver-independant solution, instead of a EMI2 specific. That way it can be useful for other people, new drivers, custom drivers of whatever. By the way, the patch has been tested and reviewed. Is it going to be commited before the feature freeze and release tag? Or should I forget about it. Angel Fradejas. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas Fink Enviado el: miercoles 6 de marzo de 2002 8:45 Para: Bruno David Simoes Rodrigues CC: [EMAIL PROTECTED] Asunto: Re: [RFY] Unicode in MO Messages and other patch >Oh sorry. /mynumber/ is the mobile number and /0100110120131234/ is the >B Number that SMSC gives to me. > >It should give me the 12345 number, right ? >But that's not what happens, and that's why I (and others in the list) >need the my-number. no you need the SMSC to do what it is supposed to be instead of hacking Kannel to have an other confusing additional parameter :). Well never mind, it is now a standard parameter for AT so it makes sense to have it everywhere for those poor guys who have to deal with SMSC administrators who have no idea what they are doing. > >> > (and hints for having a range of short-numbers redirected to one >> >connection, or >> >having the numbers +351999* are apreciated too) >> >> What speaks against having multiple sessions, one for every service >> number? Every session would have its own login, like a separate >> customer. > >Receiving from 3000 to 3999 ? ;) that will be a long config file but how else would kannel separate the different parties? if your config does not deal with the destination number who will? > > If you have multiple services on the same connection, you have a >> problem inside kannel as you will not be able to offer different >> services as the TO number is not used to differentiate the services >> (in SMSBox) but only the keywords (something to be added to SMSbox). >> Of couse you can do it externally to kannel in a CGI for example. > >I want to receive (if CMG allows it, of course) every message >to 0 in my connection :D I see. Not very easy to do. It will only work if people use your SMSC. So it will still be some kind of fancy "short ID" and a lot of programming needed. I got a solution which works like a virtual phone. So the SMSC would simply terminate the message there and it works. However thats outside of the scope of Kannel. -- 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: Delivery Report crash Kannel
>>> I have problem with kannel CVS regarding SMPP. >>> Thsi problem occured when I activate dlrmask in http request >>> >>>http://localhost:/cgi-bin/sendsms?username=xxxr&password=xxx&to=62818 155112&mclass=1&text=hallo&dlrmask=1 >>> >>> The message seem delivered. But after that kannel crashed with >>> error: >>> 2002-02-28 07:08:05 [5] PANIC: gwlib/octstr.c:2053: >>> seems_valid_real: Assertion `ostr != NULL' failed. (Called from >>> gw/smsc_smpp.c:572:handle_pdu.) >> >>Andreas, this seems to break something in the dlr_add() call. Any >>ideas from you why we are throwing assertion error here? >> > > >this isoctstr_get_cstr(msg->sms.receiver), > >so apparently somehow the receiver of the SMS is not set in the PDU. >This is invalid and has nothing to do with DLR. I agree this is invalid, sure. But we cannot say "this is invalid" and nothing more. The point is that *real* SMSC's may be sending stuff like that, and Kannel cannot just stop. Just imagine if the Apache team would say that with and misformed GET request por example. Kannel must do its best to never quit. Just ignore misformed PDUs with a warning, that's ok! But not quit please. I'm taking the oportunity to speak more generally, not just for this actual failed assertion. Just my 2 cents. Angel Fradejas.
RE: last CVS updates
Hi all, Just to let you know, I have been using this default-sender functionality in our production environment for three months now, with a (I think) respectable traffic (8+ MO per day) , and 16 SMS-C connections (smpp, emi2, and custom drivers). No problems 'till now. BTW, sorry for the missing ocstr_destroy, it were called only once at smsbox exit, so memory was not growing and I didn't see it. Angel Fradejas. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded Arbel Enviado el: lunes 25 de febrero de 2002 14:20 Para: Stipe Tolj CC: Kannel-devel (E-mail) Asunto: RE: last CVS updates > -Original Message- > From: Stipe Tolj [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 25, 2002 3:10 PM > Cc: Kannel-devel (E-mail); Nick Clarey; David Holland > Subject: Re: last CVS updates > > > Oded Arbel wrote: > > And while where here already - what about Angel's > default-sender patch ? > > will it go into CVS ? > > this depends on the pros and cons of the list. As long as there is no > consence in the list and there is no-one actually reviewing the patch > and stating that it is ok, I guess it is still scheduled. I'd really love to see it in - I tested it and I feel ok with it. it's not very important for me, but it does solve a minor issue we've been having. AFAIR, I haven't read anyone who said that the patch is broken (except for the missing octstr_destroy for which I submitted a patch). > At least I'm "blocked" for this week, after that I will engage all > point that are open. But please consider this not as "ok, then we'll > wait!". I'd rather see more activity from the cvs write permission > owner, otherwise we'll vote for adding users like you Oded to have > write permission and step on with development. Just my 2ct. I would like that :-) Oded Arbel m-Wise Inc. [EMAIL PROTECTED] -- Too fucking busy, and vice versa. -- Dorothy Parker Reply to her editor who was bugging her for her belated work while she was on her honeymoon
RE: concatenation = true
I'm using EMI2 and SMPP if that helps. Angel. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Alexei Pashkovsky Enviado el: viernes 22 de febrero de 2002 5:40 CC: [EMAIL PROTECTED] Asunto: Re: concatenation = true This is VERY smsc module dependant. - Original Message - From: "Angel Fradejas" <[EMAIL PROTECTED]> To: "Stipe Tolj" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "P. A. Bagyenda" <[EMAIL PROTECTED]> Sent: Thursday, February 21, 2002 11:20 AM Subject: RE: concatenation = true > Concatenated messages works for me, using current CVS. Never had a problem > with that. > > Angel. > > -Mensaje original- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En > nombre de Stipe Tolj > Enviado el: jueves 21 de febrero de 2002 20:19 > CC: [EMAIL PROTECTED]; P. A. Bagyenda > Asunto: Re: concatenation = true > > > "P. A. Bagyenda" wrote: > > > > I'm still trying to figure out what's going wrong with the concatenation > > = true. It doesn't work for text or binary, for the current snapshot. > > I notice two interesting things: in access.log there is dump of each > > message sent out, plus udh header. However I note that in each case, the > > reported length is one greater than should be. For instance for the udh > > it reports a length of 6, the message a length of 153. Is this part of > > the problem? > > concatenated messages used to work?! > > Can you re-post the things you are seeing as mis-behaviour in a new > mail with attached logs, so the developers could see. > > 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: concatenation = true
Concatenated messages works for me, using current CVS. Never had a problem with that. Angel. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: jueves 21 de febrero de 2002 20:19 CC: [EMAIL PROTECTED]; P. A. Bagyenda Asunto: Re: concatenation = true "P. A. Bagyenda" wrote: > > I'm still trying to figure out what's going wrong with the concatenation > = true. It doesn't work for text or binary, for the current snapshot. > I notice two interesting things: in access.log there is dump of each > message sent out, plus udh header. However I note that in each case, the > reported length is one greater than should be. For instance for the udh > it reports a length of 6, the message a length of 153. Is this part of > the problem? concatenated messages used to work?! Can you re-post the things you are seeing as mis-behaviour in a new mail with attached logs, so the developers could see. 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: [PATCH] smsc default-sender & forced-sender
Yes I know it's ugly that global-sender is needed, but
the alternative was my previous version of this patch, that had the problem of
allowing null sender sms to arrive to bearerbox. Then if you do not have
default-sender, the message with null sender would go to the
smsc.
-Mensaje original-De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]En nombre de Oded
ArbelEnviado el: miércoles 20 de febrero de 2002
17:58Para: Angel Fradejas; Kannel DevelopersAsunto: RE:
[PATCH] smsc default-sender & forced-sender
Hi
everyone.
I
have applied the patch and tested some of it's functionality (global/default
sender and applied defaults) and I found that it does what its advertised to
do (or at least, it doesn't break anything important ;-). I liked the way
default-sender overrides global-sender, but I didn't like the way I still have
to set global-sender anyway - but I guess that cannot be helped.
along the way I had to put down a small fix for this patch to fix a
tiny memory leak, and here it is attached (it should patch against the CVS
too, but that probably wouldn't work well)
Anyway - this one is green on my side.
Have
fun
Oded
Arbelm-Wise Inc.[EMAIL PROTECTED]
--Odette : "I thought you hated boys ?"Verena : "Well, I
figured , they're like stray dogs - you have to takethem in, otherwise
they run wild and are a danger to society." -- from "The
Strike"
-Original Message-From: Angel Fradejas
[mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 19, 2002
6:58 PMTo: Kannel DevelopersSubject: [PATCH] smsc
default-sender & forced-sender
Hi list,
Find attached my patch (version 2) to add support for
default-sender and forced-sender smsc config directives. I will explain some
points:
1) smsbox: precedence of faked_sender,
global_sender,
fromI
have normalized the way these directives are applied. As I posted previously
[ with very little feedback I have to say :-( ], MT-replies, and MT's
were treated in different ways.
I dapply 1) faked_sender then 2) global then
3) from
obey_request_thread,
smsbox_req_handle, smsbox_req_sendota were the functions responsible for
this. I changed smsbox_req_handle, smsbox_req_sendota to work the same as obey_request_thread.
2) struct Msg* :
applied_defaultsNow
smsbox and bearerbox records in the Msg* structure the defaults it applies.
This is coded in applied_defaults member. Each default is represented by one bit, and are available for the rest of
modules to check with dlf_ constants. For example, you could check
inside a smsc driver if
global-sender was applied with something like this
if
(msg->sms.applied_defaults & dfl_global_sender) { /* global-sender
was applied */ }
3) config directives default-sender
and
forced-senderThis
directives can be established for each smsc. Both are optional.
default-sender : it overrides faked-sender and
global-sender, but NOT &from=forced-sender : as it name implies, it overrides
anything. Every message routed to this smsc will have this
sender.
I'd greatly appreciate your
feedback, bug
reporting, flames, anything.
Any
chance for commiting to cvs?
Have
fun.
Angel
Fradejas.
[PATCH] smsc default-sender & forced-sender
Hi list,
Find attached my patch (version 2) to add support for default-sender
and forced-sender smsc config directives. I will explain some
points:
1) smsbox: precedence of faked_sender,
global_sender,
fromI have
normalized the way these directives are applied. As I posted previously [ with
very little feedback I have to say :-( ], MT-replies, and MT's were treated
in different ways.
I dapply 1) faked_sender then 2) global then 3)
from
obey_request_thread,
smsbox_req_handle, smsbox_req_sendota were the functions responsible for
this. I changed smsbox_req_handle, smsbox_req_sendota to work the same as obey_request_thread.
2) struct Msg* :
applied_defaultsNow
smsbox and bearerbox records in the Msg* structure the defaults it applies. This
is coded in applied_defaults member. Each default is represented by one bit, and are available for the rest of
modules to check with dlf_ constants. For example, you could check inside a smsc driver if global-sender was
applied with something like this
if
(msg->sms.applied_defaults & dfl_global_sender) { /* global-sender was
applied */ }
3) config directives default-sender and
forced-senderThis
directives can be established for each smsc. Both are optional.
default-sender : it overrides faked-sender and
global-sender, but NOT &from=forced-sender : as it name implies, it overrides
anything. Every message routed to this smsc will have this sender.
I'd greatly appreciate your
feedback, bug reporting, flames,
anything.
Any chance
for commiting to cvs?
Have
fun.
Angel
Fradejas.
patch_default_sender_2.diff
Description: Binary data
RE: segmentation fault
Peter, take a look at my recent posts about "smsbox_req_sendota broken?". I guess that is the problem. Angel Fradejas. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Peter Löfman Enviado el: lunes 11 de febrero de 2002 19:41 Para: [EMAIL PROTECTED] Asunto: segmentation fault Hi, with latest cvs smsbox crashes with error message "segmentation fault" when i try to send xml ota configuration message. With the EXACT same configuration with about one week old cvs it is working perfectly! What can be the problem? /Peter Lofman
RE: Precedence of faked-sender, global-sender, from
What about this? I need to know if this is a bug or not, given the kind of things I'm trying to add to Kannel. With two different logics, it would be extremely difficult to implement without breaking compatibility. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Angel FradejasEnviado el: jueves 14 de febrero de 2002 13:29Para: Kannel DevelopersAsunto: Precedence of faked-sender, global-sender, from I'm currently working on my patch for smsc default-sender and forced-sender, and I just noted that existing config directives faked-sender and global-sender are treated by smsbox in different ways. With MT-replies, precedence is: first faked-sender, second global-sender and third the MO receiver. With MT's (sendsms), precedence is: first faked-sender, second &from=, third global-sender. This is a bug I guess. I think "1)faked-sender 2)global-sender 3)from" is the way to go. Please can anybody confirm if I am right here? If so, I will include a bugfix for this in the patch. Angel Fradejas.
RE: smsbox_req_sendota broken?
I see the point Stipe, thanks for your response. But before calling
ota_tokenize_ we have all this
smsc = http_cgi_variable(list, "smsc");
if (urltrans_forced_smsc(t)) {
msg->sms.smsc_id = octstr_duplicate(urltrans_forced_smsc(t));
if (smsc)
info(0, "send-sms request smsc id ignored, as smsc id forced to
%s",
octstr_get_cstr(urltrans_forced_smsc(t)));
} else if (smsc) {
msg->sms.smsc_id = octstr_duplicate(smsc);
} else if (urltrans_default_smsc(t)) {
msg->sms.smsc_id = octstr_duplicate(urltrans_default_smsc(t));
} else
msg->sms.smsc_id = NULL;
That's why I said the function was broken. Take a look again please and
correct me if I'm wrong.
Angel Fradejas.
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En
nombre de Stipe Tolj
Enviado el: jueves 14 de febrero de 2002 15:47
Para: Angel Fradejas
CC: Kannel Developers
Asunto: Re: smsbox_req_sendota broken?
Angel Fradejas wrote:
>
> No testing at all, just rushing through the code to add support for
> the conig directives I'm working on but I'd say this function is
> broken.
shouldn't be borken, AFAIK.
>
> We have no initialization for Msg* msg, no msg_create at all.
Ok, now I remember, I have been working on this.
smsbox_req_sendota() calls
if (ota_type)
msg = ota_tokenize_settings(grp, from, phonenumber);
else
msg = ota_tokenize_bookmarks(grp, from, phonenumber);
and those are implemented in gw/ota_prov.c.
So the msg_create is called inside ota_tokenize_foo().
I would hardly wonder that I would commit something like this without
testing if both config OTAs and bookmark OTAs work.
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
smsbox_req_sendota broken?
No testing at all, just rushing through the code to add support for the conig directives I'm working on but I'd say this function is broken. We have no initialization for Msg* msg, no msg_create at all. I cannot test SMS OTA, so maybe someone with the resources available for this please could take a look at there. Angel Fradejas.
Precedence of faked-sender, global-sender, from
I'm currently working on my patch for smsc default-sender and forced-sender, and I just noted that existing config directives faked-sender and global-sender are treated by smsbox in different ways. With MT-replies, precedence is: first faked-sender, second global-sender and third the MO receiver. With MT's (sendsms), precedence is: first faked-sender, second &from=, third global-sender. This is a bug I guess. I think "1)faked-sender 2)global-sender 3)from" is the way to go. Please can anybody confirm if I am right here? If so, I will include a bugfix for this in the patch. Angel Fradejas.
RE: [REPOST] [PATCH] emi2 driver login behaviour
I understand your position. I just thought it was a missed feature in the EMI2 driver at the time of implementation, as the rest of drivers do reconnect without explicity setting a config directive. I just not see the point of not trying to reconnect, as kannel must try to keep all smscs online as long and as quick as possible. Frankly, I considered shortening the delays between reconnect attemps (as it's actual form, it may be as long as 5 minutes), but finally I left that 1,2,4,5 minutes delays just to not change much things at once. I also would like to have more points of view on that. Anybody here thinks that "give-up-on-error" behaviour can be considered a "feature" ? Angel Fradejas. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: lunes 11 de febrero de 2002 13:29 CC: Kannel Developers Asunto: Re: [REPOST] [PATCH] emi2 driver login behaviour Basicly I don't want to drop the idea, I simply want to have a discussion from the others here, before going on with this. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
[REPOST] [PATCH] emi2 driver login behaviour
I just noted this is appears as an open issue in STATUS, but not as an
available patch. Just in case you missed it, here is it again.
-Mensaje original-
De: Angel Fradejas [mailto:[EMAIL PROTECTED]]
Enviado el: miércoles 30 de enero de 2002 11:13
Para: Stipe Tolj
CC: Kannel Developers
Asunto: [PATCH] emi2 driver login behaviour
Yes, I know that's my provider problem. I just wanted to point out a
situation where a re-connect loop is a must.
Find attached the patch for that.
Index: gw/smsc_emi2.c
===
RCS file: /home/cvs/gateway/gw/smsc_emi2.c,v
retrieving revision 1.39
diff -u -r1.39 smsc_emi2.c
--- gw/smsc_emi2.c 2002/01/17 07:52:39 1.39
+++ gw/smsc_emi2.c 2002/01/30 09:47:56
@@ -237,10 +237,9 @@
if (result == -2) {
/* Are SMSCs going to return any temporary errors? If so,
* testing for those error codes should be added here. */
- error(0, "smsc_emi2: Server rejected our login, giving up");
- conn->why_killed = SMSCCONN_KILLED_WRONG_PASSWORD;
+ error(0, "smsc_emi2: Server rejected our login, retrying");
conn_destroy(server);
- return NULL;
+ continue;
}
else if (result == 0) {
error(0, "smsc_emi2: Got no reply to login attempt "
-Mensaje original-
De: Stipe Tolj [mailto:[EMAIL PROTECTED]]
Enviado el: martes 29 de enero de 2002 21:47
Para: Angel Fradejas
CC: Kannel Developers
Asunto: Re: [RFC] emi2 driver login behaviour
Angel Fradejas wrote:
>
> My EMI2 provider from time to time leaves my connections in a zombie
state:
> althought I closed it, they see them as already open (they have problems
> with their soft I guess). The result is that when I try to login again
they
> reject me with a "number of sessions exceeded" reason.
>
> Eventually, the sessions they have will die and I will be able to login.
This session misbehaviour/limit is definitly on the server side (your
provider).
> Others drivers will sleep and try again. I think this is the way to go, as
> Kannel is meant to run 24/7 mostly unattended. The modifications needed to
> do that are trivial. I have done it with good results.
>
> What do you think?
I think looping in order to try to re-connect is a thing we should
take into account here.
Can you provide us a patch against current cvs and we are going to
incorporate it.
BTW, I added this issue to STATUS.
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
patch_loop_connect_emi2.diff
Description: Binary data
RE: global-sender on a smsc basis ?
Yes, it seems the more flexible approach is to have default-sender and forced-sender for each smsc. forced-sender would override everything: global-sender, fake-sender, &from= default-sender would override global-sender and fake-sender, but NOT &from= What about this? Everybody agrees? If so, I'll work on it and submit the patch as soon as possible. Angel Fradejas. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Nisan Bloch Enviado el: jueves 31 de enero de 2002 15:12 Para: Angel Fradejas; Stipe Tolj CC: Kannel Developers Asunto: 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=999&text=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=999&text=Hello&from=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-sender"s 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: global-sender on a smsc basis ?
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=999&text=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=999&text=Hello&from=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-sender"s 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: global-sender on a smsc basis ?
I'm working on this, just wanted to point out that this way, one _must_ set global-sender to whatever value, even knowing that bearerbox will change it. If not, smsbox will reject the message with a "Sender missing and no global set, rejected" reason. An example config would be: group = smsbox global-sender = (or whatever) group = smsc smsc-id = A default-sender = group = smsc smsc-id = B default-sender = And then, the sendsms requests from the applications without a &from=, to let bearerbox select the appropiate one. Agree? Angel Fradejas. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas Fink Enviado el: martes 29 de enero de 2002 16:47 Para: Angel Fradejas CC: [EMAIL PROTECTED] Asunto: RE: global-sender on a smsc basis ? >Ok, I could rework my patch to take this into account. > >So we'd have > >smsbox global-sender >sms-service faked-sender >smsc default-sender >And of course an optional &from= in every message. > >And bearerbox behaviour would be > >&from=never overrideable by smsc default-sender >global-sender overrideable by smsc default-sender (only if applied by >smsbox) >faked-sender overrideable by smsc default-sender (only if applied by >smsbox) >an empty sender overrideable by smsc default-sender > >I do not know the impact of having message in bearerbox with an empty >sender. Will any driver complain about that? > >Before going any further with this implementation, I would like to hear what >to do if a message goes all the way to bearerbox with an empty sender and >there's not default-sender. you can set the default sender in smsbox but have a flag indicate that it can be overriden by a more specific default (smsc specific one). -- 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
[PATCH] emi2 driver login behaviour
Yes, I know that's my provider problem. I just wanted to point out a
situation where a re-connect loop is a must.
Find attached the patch for that.
Index: gw/smsc_emi2.c
===
RCS file: /home/cvs/gateway/gw/smsc_emi2.c,v
retrieving revision 1.39
diff -u -r1.39 smsc_emi2.c
--- gw/smsc_emi2.c 2002/01/17 07:52:39 1.39
+++ gw/smsc_emi2.c 2002/01/30 09:47:56
@@ -237,10 +237,9 @@
if (result == -2) {
/* Are SMSCs going to return any temporary errors? If so,
* testing for those error codes should be added here. */
- error(0, "smsc_emi2: Server rejected our login, giving up");
- conn->why_killed = SMSCCONN_KILLED_WRONG_PASSWORD;
+ error(0, "smsc_emi2: Server rejected our login, retrying");
conn_destroy(server);
- return NULL;
+ continue;
}
else if (result == 0) {
error(0, "smsc_emi2: Got no reply to login attempt "
-Mensaje original-
De: Stipe Tolj [mailto:[EMAIL PROTECTED]]
Enviado el: martes 29 de enero de 2002 21:47
Para: Angel Fradejas
CC: Kannel Developers
Asunto: Re: [RFC] emi2 driver login behaviour
Angel Fradejas wrote:
>
> My EMI2 provider from time to time leaves my connections in a zombie
state:
> althought I closed it, they see them as already open (they have problems
> with their soft I guess). The result is that when I try to login again
they
> reject me with a "number of sessions exceeded" reason.
>
> Eventually, the sessions they have will die and I will be able to login.
This session misbehaviour/limit is definitly on the server side (your
provider).
> Others drivers will sleep and try again. I think this is the way to go, as
> Kannel is meant to run 24/7 mostly unattended. The modifications needed to
> do that are trivial. I have done it with good results.
>
> What do you think?
I think looping in order to try to re-connect is a thing we should
take into account here.
Can you provide us a patch against current cvs and we are going to
incorporate it.
BTW, I added this issue to STATUS.
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
patch_loop_connect_emi2.diff
Description: Binary data
[RFC] emi2 driver login behaviour
My EMI2 provider from time to time leaves my connections in a zombie state:
althought I closed it, they see them as already open (they have problems
with their soft I guess). The result is that when I try to login again they
reject me with a "number of sessions exceeded" reason.
When that happens, the EMI2 driver gives up and does a shutdown. This is the
relevant code:
emimsg = make_emi60(privdata);
emi2_emimsg_send(conn, server, emimsg);
emimsg_destroy(emimsg);
result = wait_for_ack(privdata, server, 60, 30);
if (result == -2) {
/* Are SMSCs going to return any temporary errors? If so,
* testing for those error codes should be added here. */
error(0, "smsc_emi2: Server rejected our login, giving up");
conn->why_killed = SMSCCONN_KILLED_WRONG_PASSWORD;
conn_destroy(server);
return NULL;
}
else if (result == 0) {
error(0, "smsc_emi2: Got no reply to login attempt "
"within 30 s");
conn_destroy(server);
continue;
}
else if (result == -1) { /* Broken connection, already logged */
conn_destroy(server);
continue;
}
Eventually, the sessions they have will die and I will be able to login.
Others drivers will sleep and try again. I think this is the way to go, as
Kannel is meant to run 24/7 mostly unattended. The modifications needed to
do that are trivial. I have done it with good results.
What do you think?
Angel Fradejas.
RE: global-sender on a smsc basis ?
Ok, obvious. I guess I need a rest -Mensaje original- De: Andreas Fink [mailto:[EMAIL PROTECTED]] Enviado el: martes 29 de enero de 2002 16:47 Para: Angel Fradejas CC: [EMAIL PROTECTED] Asunto: RE: global-sender on a smsc basis ? >Ok, I could rework my patch to take this into account. > >So we'd have > >smsbox global-sender >sms-service faked-sender >smsc default-sender >And of course an optional &from= in every message. > >And bearerbox behaviour would be > >&from=never overrideable by smsc default-sender >global-sender overrideable by smsc default-sender (only if applied by >smsbox) >faked-sender overrideable by smsc default-sender (only if applied by >smsbox) >an empty sender overrideable by smsc default-sender > >I do not know the impact of having message in bearerbox with an empty >sender. Will any driver complain about that? > >Before going any further with this implementation, I would like to hear what >to do if a message goes all the way to bearerbox with an empty sender and >there's not default-sender. you can set the default sender in smsbox but have a flag indicate that it can be overriden by a more specific default (smsc specific one). -- 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: global-sender on a smsc basis ?
Ok, I could rework my patch to take this into account. So we'd have smsbox global-sender sms-service faked-sender smsc default-sender And of course an optional &from= in every message. And bearerbox behaviour would be &from=never overrideable by smsc default-sender global-sender overrideable by smsc default-sender (only if applied by smsbox) faked-sender overrideable by smsc default-sender (only if applied by smsbox) an empty sender overrideable by smsc default-sender I do not know the impact of having message in bearerbox with an empty sender. Will any driver complain about that? Before going any further with this implementation, I would like to hear what to do if a message goes all the way to bearerbox with an empty sender and there's not default-sender. Angel Fradejas. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stefan Cars Enviado el: martes 29 de enero de 2002 12:25 Para: Andreas Fink CC: Angel Fradejas; [EMAIL PROTECTED] Asunto: RE: global-sender on a smsc basis ? That sounds very good - Stefan Cars CTO Globalwire Communications Phone: +46 18 10 79 50 Mobile(UK): +44 788 061 36 69 Mobile(SE): +46 708 44 36 00 On Tue, 29 Jan 2002, Andreas Fink wrote: > how about this for global sender idea: > > We add another field to the message structure which is a flag > indicating that the number was set as a "default" number and it can > be replaced if there's another more specific default overriding it? > > this will make a global default sender overrideable by a smsc > specific global sender. > -- > > 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 >
RV: [PATCH] smsc_smpp.c does not timestamp MO messages
Oops, I missed something the patch itself. Sorry. -Mensaje original- De: Angel Fradejas [mailto:[EMAIL PROTECTED]] Enviado el: martes 29 de enero de 2002 11:08 Para: Kannel Developers Asunto: [PATCH] smsc_smpp.c does not timestamp MO messages Hi list, I noticed that MO messages do not get timestamped by SMPP driver. The fix is trivial. You can confirm it using %t token on a get-url directive. Stipe, please, what about a commit for this? :-) Seriously, let be know if I'm missing something. Thanks for your time. Angel Fradejas. patch_smpp_mo_timestamp.diff Description: Binary data
[PATCH] smsc_smpp.c does not timestamp MO messages
Hi list, I noticed that MO messages do not get timestamped by SMPP driver. The fix is trivial. You can confirm it using %t token on a get-url directive. Stipe, please, what about a commit for this? :-) Seriously, let be know if I'm missing something. Thanks for your time. Angel Fradejas.
RE: global-sender on a smsc basis ?
Stipe Tolj wrote: > >Angel Fradejas wrote: >> >> The way sendsms requests get their way, I think this is not an easy thing to >> do. First, smsbox takes the request and if it has an empty sender, it puts >> "global-sender". smsbox does not know about smsc's. Then, bearerbox takes >> the request, and it checks for an empty sender. If so, it puts the right >> smsc "default-sender". >> >> I do not see a way to do your proposal without breaking smsbox/bearerbox >> interface. >> >> Anyway, I'm happy with the way I implemented that. In real life, one could >> have several smsc links, and have the same sender number for all of them. >> Then set global-sender and that's enough. Or one (like me) could have >> several smsc links, each of them requiring a diferent sender. Then leave >> global-sender unset, and set each smsc default-sender properly. > >your patch regarding the "default-sender" directive for the smsc >groups is still scheduled, currently I'm tending for a non commitment, >at least for the current form. > >I dislike the issue that one *must* unset "global-sender" in the core >group to make "default-sender"s 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! > >Stipe If you set both smsbox "global-sender" and bearebox smsc "default-sender" this is what happens: 1) smsbox gets the sendsms request and puts global-sender on it if "&from" is unset. 2) bearerbox get the MT message, finds the appropiate smsc to send it to, but it has valid sender value (smsbox global-sender). So it does not apply the smsc default-sender. For point 2) not to happen, bearerbox would have to be aware of smsbox global-sender value, and replace it with default-sender. Even if this is possible to do, I do not think this is a good idea. First of all, bearerbox would have to read smsbox config directives (think in smsbox/bearerbox on different machines), and second, every message with a sender equal to global-sender is changed to default-sender. One could not send anything with that number on sender. Besides from global-sender, we have sms-service fake-sender etc. If we follow that way of doing things, bearerbox would have to replace these too. So this is my point of view: 1) if all your smsc's accept the same sender (or any sender), use smsbox "global-sender". You can either not ser "&sender=" or set "&sender=" to a fixed value. Everything will work fine. 2) if each of your smsc's require a different sender (and reject any other number), leave global-sender unset, set each smsc default-sender appropiately, and leave "&sender=" unset on your sendsms request. Smsbox will pass the sms to bearerbox unchanged (empty sender), and bearerbox will select the appropiate sender based on smsc. I'm currently using this 2) approach on a productive environment for a couple of months, and I'm having no problems at all. I would be happy to have more feedback from developers too. Angel Fradejas.
RE: SMPP TON
Good idea. I had to hack around a bit with the TON to be accepted by Vodafone... -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Stipe Tolj Enviado el: martes 29 de enero de 2002 9:00 Para: Peter Löfman CC: Andreas Fink; [EMAIL PROTECTED] Asunto: Re: SMPP TON Peter Löfman wrote: > > Hi, > > well I solved the problem by re-compiling with the ton set to 0. > It might be possible that 1 (international) will work also, I have not tested yet. > But with 2 (national) it did not work. so, how about setting this ton variable by a configuration directive within the smsc group?! 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
