Re: datagram mode
On Tue, Sep 27, 2005 at 05:28:30PM +0200, Stipe Tolj wrote:
> I'm -1 on commiting the patch in the form Enver send it in. We need to add
> a meta field layer in order to "pass" smsc specific values to the smsc
> module layer.
I had the same problem while still working for my previous employer
(i.e have to set esm_class suppose to be able to connect to one of CDMA
operators in Indonesia, Telkom/Flexi). At that time, I do make it
configurable through kannel config, i.e set 'submit_esm_class = 1" on
smsc group.
My current connection to the same operator doesn't need that setting
anymore.
Anyway, please take a alook at the attached patch.
Regards,
P.Y. Adi Prasaja
Index: gw/smsc/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.82
diff -a -u -r1.82 smsc_smpp.c
--- gw/smsc/smsc_smpp.c 12 Aug 2005 16:12:58 - 1.82
+++ gw/smsc/smsc_smpp.c 27 Sep 2005 17:07:32 -
@@ -161,6 +161,7 @@
long connection_timeout;
long wait_ack;
int wait_ack_action;
+int submit_esm_class;
SMSCConn *conn;
} SMPP;
@@ -213,7 +214,7 @@
Octstr *my_number, int smpp_msg_id_type,
int autodetect_addr, Octstr *alt_charset,
Octstr *service_type, long connection_timeout,
- long wait_ack, int wait_ack_action)
+ long wait_ack, int wait_ack_action, int
submit_esm_class)
{
SMPP *smpp;
@@ -252,6 +253,7 @@
smpp->connection_timeout = connection_timeout;
smpp->wait_ack = wait_ack;
smpp->wait_ack_action = wait_ack_action;
+smpp->submit_esm_class = submit_esm_class;
return smpp;
}
@@ -667,7 +669,7 @@
* set the esm_class field
* default is store and forward, plus udh and rpi if requested
*/
-pdu->u.submit_sm.esm_class = ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE;
+pdu->u.submit_sm.esm_class = smpp->submit_esm_class;
if (octstr_len(msg->sms.udhdata))
pdu->u.submit_sm.esm_class = pdu->u.submit_sm.esm_class |
ESM_CLASS_SUBMIT_UDH_INDICATOR;
@@ -1758,6 +1760,7 @@
int autodetect_addr;
Octstr *alt_charset;
long connection_timeout, wait_ack, wait_ack_action;
+int submit_esm_class;
my_number = alt_charset = NULL;
transceiver_mode = 0;
@@ -1883,13 +1886,18 @@
if (wait_ack_action > 0x03 || wait_ack_action < 0)
panic(0, "SMPP: Invalid wait-ack-expire directive in configuration.");
+/* submit_esm_class */
+if (cfg_get_integer((long *)&submit_esm_class, grp,
octstr_imm("submit-esm-class")) == -1)
+ submit_esm_class = ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE;
+
smpp = smpp_create(conn, host, port, receive_port, system_type,
username, password, address_range,
source_addr_ton, source_addr_npi, dest_addr_ton,
dest_addr_npi, enquire_link_interval,
max_pending_submits, version, priority, my_number,
smpp_msg_id_type, autodetect_addr, alt_charset,
- service_type, connection_timeout, wait_ack,
wait_ack_action);
+ service_type, connection_timeout, wait_ack,
wait_ack_action,
+ submit_esm_class);
conn->data = smpp;
conn->name = octstr_format("SMPP:%S:%d/%d:%S:%S",
Index: gwlib/cfg.def
===
RCS file: /home/cvs/gateway/gwlib/cfg.def,v
retrieving revision 1.112
diff -a -u -r1.112 cfg.def
--- gwlib/cfg.def 21 Sep 2005 02:01:22 - 1.112
+++ gwlib/cfg.def 27 Sep 2005 17:07:35 -
@@ -328,6 +328,7 @@
OCTSTR(flow-control)
OCTSTR(wait-ack)
OCTSTR(wait-ack-expire)
+OCTSTR(submit-esm-class)
OCTSTR(no-sender)
OCTSTR(no-coding)
OCTSTR(window)
Re: datagram mode
Hillel wrote:
Hi,
Enver Altin gave a patch for datagram mode to help a fellow kannel user.
Will this be included in CVS or altered and then entered?
discussion on this is up again in the orginal message thread, see there.
I'm -1 on commiting the patch in the form Enver send it in. We need to add a
meta field layer in order to "pass" smsc specific values to the smsc module layer.
Stipe
mailto:stolj_{at}_wapme-group.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
Re: DATAGRAM MODE
Enver ALTIN wrote:
Hey,
On Mon, 2005-08-29 at 12:05 +0200, Alejandro Guerrieri wrote:
Count me in! (Now it's 2 Alejandro's ;) ) I've had to change the darn
ESM_CLASS to DEFAULT about a thousand times :)
I think general consensus is to prevent adding SMSC-specific parameters
to the sendsms interface, so I think this patch is a bit controversial
and needs to be properly designed before it gets committed.
yep, agreed. The patch is definetly _too_ SMPP centric in this case. At least
the way the sendsms interface is changed.
Maybe we can introduce a generic-purpose field and use it for passing
SMSC-specific parameters to the SMSCConn via sendsms? Maybe we can just
let it in, and change the behavior later? I'm not really sure which way
is better.
agree'ing again. This discussion is a flaming issue on the list. We need a
construct to abtractly "de-abstract" the sendsms interface parameters ;)
What does that mean? ;) ... now, actually the smsbox should hide "as much as
possible" the SMSC specific issues to the HTTP client/caller. In this case I
don't know how we can do that exactly.
But I _do_ agree that we need some kind of "meta" field that is passed
"unchanged/uninterpreted" from smsbox layer to bearerbox and hence to the
specific smsc implementation to let the smsc module itself decide how it should
use the information presented in the meta field.
How can this actually look like?
maybe something like
http:///sendsms?...&meta=XXX&;...
where the XXX value of the meta parameter is again urlencoded in order to be
parsed later on with a seperate key=value chain list.
More ideas on this?
Stipe
mailto:stolj_{at}_wapme-group.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
datagram mode
Hi, Enver Altin gave a patch for datagram mode to help a fellow kannel user. Will this be included in CVS or altered and then entered? Rgds Date: Sat, 27 Aug 2005 15:21:40 +0300 From: Enver ALTIN <[EMAIL PROTECTED]> Subject: Re: DATAGRAM MODE To: users@kannel.org Cc: devel@kannel.org Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-15" Hey, On Sat, 2005-08-27 at 04:12 -0600, Alejandro Ramirez wrote: > I really need to set up a broadcast, but telco is asking me to send > the messages with ESM CLASS of DATAGRAM MODE. I've read in the mailing > list and I've changed the line 638 of the code of smsc_smpp.c to the > corresponding type. > > How ever when I try to send a SMS it STILL goes out with the ESM CLASS > of STORE & Forward??? > > Do i need to change the code somewhere else?? Apply the attached patch against CVS HEAD. It implements the submission_mode sendsms CGI variable so you can set the esm_class field of SMPP to one of: #define ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE0x #define ESM_CLASS_SUBMIT_DATAGRAM_MODE0x0001 #define ESM_CLASS_SUBMIT_FORWARD_MODE 0x0002 #define ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE 0x0003 via the sendsms CGI interface. Something like this to use datagram mode should work: http://localhost:10001/cgi-bin/sendsms?user=test&password=test&from= 1234&to=1234&text=testing&submission_mode=1 -HTH -- .O. ..O Enver ALTIN | http://skyblue.gen.tr/ OOO Software developer @ Parkyeri | http://www.parkyeri.com/
Re: [PATCH] mysql_real_escape_string() usage in gw/dlr_mysql.c
Peter Christensen wrote:
Under all circumstances, the patch is better than the one I was forced
to make myself in a hurry when I encountered the problem. I ended up not
using the real_escape version because I didn't have time to dig into how
the DB pool was working, and I didn't use the Octstr struct.
This is also why I didn't offered you my own patch. You would probably
spend more time fixing my patch, than writing your own :D
But it is good to see that fixes are posted this fast. With certain
other projects, it may take months before you even get a response!
Best regards
Hi Peter,
now, we don't claim to respond directly as I did on this issue. ;) It depends on
free time, and priority of the issue itself.
Now, as Rene stated it wouldn't be a problem to pull on the database pool in
ensuring that the mysql_real_escape_string() can be called. This would fix the
glitchy issue that we pass the DBPoolConn struct up to the next calling level.
I'll re-code things here and post a patch for voting.
Stipe
mailto:stolj_{at}_wapme-group.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
RE: [PATCH] mysql_real_escape_string() usage in gw/dlr_mysql.c
Is there no CSAT. The owner can't take out the time to remove my name from the
list. Although I have got a confirmation mail, that I have been unsubscribed,
but still all messages come to me. I hope I have founf a bug !!!
Regards
Gaurav
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Christensen
Sent: Tuesday, September 27, 2005 4:22 PM
To: Stipe Tolj
Cc: Kannel Development list; Rene Kluwen
Subject: Re: [PATCH] mysql_real_escape_string() usage in gw/dlr_mysql.c
Hi,
Under all circumstances, the patch is better than the one I was forced
to make myself in a hurry when I encountered the problem. I ended up not
using the real_escape version because I didn't have time to dig into how
the DB pool was working, and I didn't use the Octstr struct.
This is also why I didn't offered you my own patch. You would probably
spend more time fixing my patch, than writing your own :D
But it is good to see that fixes are posted this fast. With certain
other projects, it may take months before you even get a response!
Best regards
Peter Christensen
(ungod in the bug report system)
Stipe Tolj wrote:
> Rene Kluwen wrote:
>>
>> IMHO consuming DBPoolConns is not a bad thing. After all, that is why the
>> pool even exist. So consuming and producing sql connections is not so
>> expensive.
>
> ok, that's true. The main issue is that in some circumstances you may
> need 2 connections for "one-and-the-same" job, where 1 would be enought.
> Think of thread overlays. Now, on the other hand I agree and actually we
> shouldn't make life inside dlr_mysql too hard in order to pass mysql
> connection structs to lower function call layers.
>
>> In your patch: Where exactly do you escpape the parameters to the sql
>> string? I couldnt find that so quick.
>
> I use mysql_real_escape_string() within gw/dlr_mysql.c:mysql_escape().
>
>> In most of the Chimit code, we use something like this:
>>
>> Octstr *sql = octstr_sql_format("SELECT * from table where pk = '%s'",
>> PrimaryKey);
>>
>> The function octstr_sql_format is crafted so that before replacing the
>> value
>> of PrimaryKey on the place that says %s in the format string,
>> automatically
>> it is sql-escaped.
>> This way, you never have to worry about escaping stuff - everything goes
>> automagically. This a clean and generic solution that generates little
>> coding effort.
>
> yep, +1 on this approach... but I'd see the octstr_sql_format() renamed
> to mysql_octstr_format() in order to semantically scope this to the
> mysql layer and not fitting it to the gwlib/ itself.
>
> Another thing. It seems to me that you use "only" mysql_escape_string()
> from the mysql client lib here, right? You don't use
> mysql_real_escapee_string() which implies that you aren't aware of the
> charset encoding and still the escaping "could fail". At least most of
> the significant projects using the mysql client lib changed to call the
> mysql_real_... function instead of the other one. Even the mysql docs
> advice this to do.
>
> The whole dilema about the previously needed DBPoolConn wouldn't be
> necessary if we "simply" pick the mysql_escape_string() instead of the
> sophisticated one ;)
>
> Stipe
>
> mailto:stolj_{at}_wapme-group.de
> ---
> Wapme Systems AG
>
> Vogelsanger Weg 80
> 40470 Düsseldorf, NRW, Germany
>
> phone: +49.211.74845.0
> fax: +49.211.74845.299
>
> mailto:info_{at}_wapme-systems.de
> http://www.wapme-systems.de/
> ---
>
DISCLAIMER:
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE
COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact the
sender by email and delete all copies; your cooperation in this regard is
appreciated.
Re: [PATCH] mysql_real_escape_string() usage in gw/dlr_mysql.c
Hi,
Under all circumstances, the patch is better than the one I was forced
to make myself in a hurry when I encountered the problem. I ended up not
using the real_escape version because I didn't have time to dig into how
the DB pool was working, and I didn't use the Octstr struct.
This is also why I didn't offered you my own patch. You would probably
spend more time fixing my patch, than writing your own :D
But it is good to see that fixes are posted this fast. With certain
other projects, it may take months before you even get a response!
Best regards
Peter Christensen
(ungod in the bug report system)
Stipe Tolj wrote:
Rene Kluwen wrote:
IMHO consuming DBPoolConns is not a bad thing. After all, that is why the
pool even exist. So consuming and producing sql connections is not so
expensive.
ok, that's true. The main issue is that in some circumstances you may
need 2 connections for "one-and-the-same" job, where 1 would be enought.
Think of thread overlays. Now, on the other hand I agree and actually we
shouldn't make life inside dlr_mysql too hard in order to pass mysql
connection structs to lower function call layers.
In your patch: Where exactly do you escpape the parameters to the sql
string? I couldnt find that so quick.
I use mysql_real_escape_string() within gw/dlr_mysql.c:mysql_escape().
In most of the Chimit code, we use something like this:
Octstr *sql = octstr_sql_format("SELECT * from table where pk = '%s'",
PrimaryKey);
The function octstr_sql_format is crafted so that before replacing the
value
of PrimaryKey on the place that says %s in the format string,
automatically
it is sql-escaped.
This way, you never have to worry about escaping stuff - everything goes
automagically. This a clean and generic solution that generates little
coding effort.
yep, +1 on this approach... but I'd see the octstr_sql_format() renamed
to mysql_octstr_format() in order to semantically scope this to the
mysql layer and not fitting it to the gwlib/ itself.
Another thing. It seems to me that you use "only" mysql_escape_string()
from the mysql client lib here, right? You don't use
mysql_real_escapee_string() which implies that you aren't aware of the
charset encoding and still the escaping "could fail". At least most of
the significant projects using the mysql client lib changed to call the
mysql_real_... function instead of the other one. Even the mysql docs
advice this to do.
The whole dilema about the previously needed DBPoolConn wouldn't be
necessary if we "simply" pick the mysql_escape_string() instead of the
sophisticated one ;)
Stipe
mailto:stolj_{at}_wapme-group.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---
