Re: [PATCH] custom MO Parameters for smsc-http
Ok, here's a new version of my patch to add support for custom MO
parameters on the generic http-smsc.
New features:
1. Support for setting the numeric response code for successful and
failed requests (as it is now, it always returns 202 HTTP_ACCEPTED).
2. Support for setting the text response for successful requests
(right now it returns Sent.).
3. Some code cleanups (extra lines, parameter expansion after
authorization).
4. Documentation.
http://www.blogalex.com/archives/192
I can commit if no objections.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 01/06/2009, at 22:50, Alexander Malysh wrote:
Hi,
here some comments...
in generic_receive_sms you first receive all values than converts it
and only
after this done check authorization. Make no sense... first check
auth then convert anything.
+else if (from == NULL || to == NULL || text == NULL) {
+
+error(0, HTTP[%s]: Insufficient args,
why extra line?
I think retmsg should also be configurable. Because not all gateways
will accept 'Sent' as response.
I think even HTTP error code for not accepted MOs/DLRs should be
configurable.
Thanks,
Alex
P.S. And userguide part would be nice ;)
Am 28.05.2009 um 23:00 schrieb Alejandro Guerrieri:
HI,
I've finished my patch to configure the parameter names for MO on
the generic http-smsc.
To use it you just add a few entries on the smsc definition, only
with the parameters you want to rename.
e.g:
generic-param-from = phoneNumber
generic-param-to = shortCode
generic-param-text = message
More details and the patch here:
http://www.blogalex.com/archives/171
Of course I'm writing the userguide part if this goes forward :)
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
LMT extensions
Hello, Any have some experience with connection to LMT operator in Latvia with proprietary SMPP extensions for DLR and billing reports? I found previous thread about it, but with no decisions..:( Kind regards, Martynas - Hi, Am I right that LMT uses reserved command ids there? If yes, then in my opinion it may be useful to implement some API for adding vendor specific SMPP commands processing as DSO and after this LMT extension as such DSO :-) Illimar Reinbusch - Telejazz.com wrote: LMT uses SMPP procol with some additions to it for billing and DLR purpose. * *For example:* * **LMT_REPORT – Contains information regarding the result of the processing and execution of the SUBMIT_SM command;* *LMT_GEN_CODE_RESP – Contains information regarding the result of the processing and execution of the LMT_GEN_CODE command** LMT_VERIFY_CODE_RESP – Contains information regarding the result of the processing and execution of the LMT_ VERIFY_CODE command; * *LMT_REPORT_RESP – contains information regarding the results of the LMT_REPORT command’s execution;* *LMT_GEN_CODE – requests to generate access information for the Service provider’s public resource, if authorization is made according to the procedure outlined in Art.3.7. and 3.8. of the Addendum No.2 to this Contract;* *LMT_VERIFY_CODE – requests to verify the access information provided by the Client for the public resource; Illimar Hi, what is LMT extention? Could you please provide some links? Illimar Reinbusch - Telejazz.com wrote: Have somebody implemented it or its new to Kannel. Would Kannel be interested adding support for it to Kannel if someone (me) would write it? Illimar Jurijs Cerepanovs wrote: Illimar Reinbusch - Telejazz.com wrote: Current implementation needs patch for kannel - it's simply to rewrite smpp connector for understanding LMT_REPORT e.t.c proprietary packets. Hi Has anybody implemented or added new protocol to support Latvia LMT operator SMPP protocol with LMT extentsions? Would u suggest adding to to current SMPP development or add new protocol based on SMPP implementation? Thanks, Illimar -- Michael Bochkaryov www.netstyle.com.ua
Re: ota_compiler.c patch
Hi, if I look through the code, Niko is right. Stipe could you .confirm this? Thanks, Alex Am 08.06.2009 um 22:09 schrieb Nikos Balkanas: Dear Stipe, On 2008/10/22 Rev 1.16 you reordered the INLINE attributes in ota_compiler.c. That broke the code in ota_compiler.c that relied on INLINE to be the last available option, if no prior matches are found. I hope you don't mind, i reverted back your changes, so that i can close a few tickets. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Cc: tom...@megalogika.lt; Pai Peng sipai...@gmail.com; Julien Buratto julien.bura...@gmail.com Sent: Monday, June 08, 2009 10:57 PM Subject: ota_compiler.c patch Hi, Actually i was mistakenly looking at the wrong place. wap- provisioningdoc has being supported all along. However, an incompletely tested feature at some point had an undesirable side effect. Let me know also if you would prefer text to take as value the name of an xml file, instead of a huge urlencoded string. this would align it more with the documentation. I know I do. I have no way of testing the code, except running it through the debugger, so please test it and let me know how it goes. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org; Pai Peng sipai...@gmail.com Sent: Monday, June 08, 2009 11:03 AM Subject: Re: sendota problems Oops! Forgot to ask. Can't you use a characteristic-list xml document to do your job? Kannel fully supports those! BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org; Pai Peng sipai...@gmail.com Sent: Monday, June 08, 2009 6:11 AM Subject: Re: sendota problems Hi Julien, I looked it up and it is not trivial. As it stands kannel supports only the Nokia OTA characteristic-list specs. It doesn't support the wap-provisioningdoc specs. As such a complete reworking of the ota-compiler would be needed to accomodate it. Since I am lacking ota development/testing environment, and is only of marginal interest to me, I am sorry but I cannot pursue it further. What I can do is, to make a patch, so that kannel prints an error when it detects such a document and drops it. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org Sent: Saturday, June 06, 2009 9:19 AM Subject: Re: sendota problems Not, unfortunately. I was going crazy all this time at work, but I just finished. I will look at it over this weekend. BR, Nikos - Original Message - From: Julien Buratto julien.bura...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org Sent: Thursday, May 28, 2009 3:16 PM Subject: Re: sendota problems Hi Nikos, where you able to fix the issue ? 2009/3/17 Nikos Balkanas nbalka...@gmail.com: Hi, There seems to be an incombatibility between kannel's wbxml and Nokia's. I intend to fix it, but in a month or so. In the meantime you might want to compile the message manually, as described by Pai Peng. BR, Nikos - Original Message - From: Tomas Verbaitis tom...@megalogika.lt To: us...@kannel.org Sent: Monday, March 16, 2009 1:24 PM Subject: sendota problems Hello, I want to configure synchronization for Nokia 6070 mobile phone. My program generates this XML provisioning document: ?xml version=1.0? !DOCTYPE wap-provisioningdoc PUBLIC -//WAPFORUM//DTD PROV 1.0//EN http://www.wapforum.org/DTD/prov.dtd; wap-provisioningdoc characteristic type=BOOTSTRAP parm name=NAME value=SKLADDEVEL/ /characteristic characteristic type=APPLICATION parm name=APPID value=w5/ parm name=TO-NAPID value=INTERNET / parm name=NAME value=SKLADDEVEL/ parm name=ADDR value=http://megalogika.stp.lt/funambol/ds/ characteristic type=RESOURCE parm name=URI value=card/ parm name=NAME value=Contacts DB/ parm name=AACCEPT value=text/x-vcard/ /characteristic characteristic type=RESOURCE parm name=URI value=cal/ parm name=NAME value=Calendar/ parm name=AACCEPT value=text/x-vcalendar/ /characteristic characteristic type=RESOURCE parm name=URI value=notes/ parm name=NAME value=Notes/ parm name=AACCEPT value=text/plain/ /characteristic characteristic type=APPAUTH parm name=AAUTHNAME value=funUsrVe/ parm name=AAUTHSECRET value=funPassVe/ /characteristic /characteristic /wap-provisioningdoc When i send it via Kannel's /sendota, via this request: /cgi-bin/sendota?password=##username=##type=oma- settingssec=USERPINpin=1234to=%2B37069953201text=%3C%3Fxml +version%3D%221.0%22%3F%3E%0A%3C%21DOCTYPE+wap-provisioningdoc +PUBLIC+%22-%2F%2FWAPFORUM%2F%2FDTD+PROV+1.0%2F%2FEN%22%0A %22http%3A%2F%2Fwww.wapforum.org%2FDTD%2Fprov.dtd%22%3E%0A
Re: LMT extensions
Hi, without their Spec is this impossible to say if Kannel can handle this... Please provide Spec. Thanks, Alex Am 09.06.2009 um 10:11 schrieb V: Hello, Any have some experience with connection to LMT operator in Latvia with proprietary SMPP extensions for DLR and billing reports? I found previous thread about it, but with no decisions..:( Kind regards, Martynas - Hi, Am I right that LMT uses reserved command ids there? If yes, then in my opinion it may be useful to implement some API for adding vendor specific SMPP commands processing as DSO and after this LMT extension as such DSO :-) Illimar Reinbusch - Telejazz.com wrote: LMT uses SMPP procol with some additions to it for billing and DLR purpose. * *For example:* * **LMT_REPORT – Contains information regarding the result of the processing and execution of the SUBMIT_SM command;* *LMT_GEN_CODE_RESP – Contains information regarding the result of the processing and execution of the LMT_GEN_CODE command** LMT_VERIFY_CODE_RESP – Contains information regarding the result of the processing and execution of the LMT_ VERIFY_CODE command; * *LMT_REPORT_RESP – contains information regarding the results of the LMT_REPORT command’s execution;* *LMT_GEN_CODE – requests to generate access information for the Service provider’s public resource, if authorization is made according to the procedure outlined in Art.3.7. and 3.8. of the Addendum No.2 to this Contract;* *LMT_VERIFY_CODE – requests to verify the access information provided by the Client for the public resource; Illimar Hi, what is LMT extention? Could you please provide some links? Illimar Reinbusch - Telejazz.com wrote: Have somebody implemented it or its new to Kannel. Would Kannel be interested adding support for it to Kannel if someone (me) would write it? Illimar Jurijs Cerepanovs wrote: Illimar Reinbusch - Telejazz.com wrote: Current implementation needs patch for kannel - it's simply to rewrite smpp connector for understanding LMT_REPORT e.t.c proprietary packets. Hi Has anybody implemented or added new protocol to support Latvia LMT operator SMPP protocol with LMT extentsions? Would u suggest adding to to current SMPP development or add new protocol based on SMPP implementation? Thanks, Illimar -- Michael Bochkaryov www.netstyle.com.ua
Re: [PATCH] custom MO Parameters for smsc-http
Hi,
Seems you don't handle charset at all. Do you assume to receive UTF-8
in any case? I don't think it's
applicable to generic interface. At least alt-charset should be taken
in account...
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in DLR storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid != NULL) {
+/* we got a DLR, and we don't require additional values */
+Msg *dlrmsg;
hmm this check is not complete. it should be udh_len + msgdata_len but
msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh) MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long, rejected,
+ octstr_get_cstr(conn-id));
+retmsg = octstr_create(UDH field is too long, rejected);
+retstatus = fm-status_error;
+}
why do you always load generic config options ?
static void generic_send_sms(SMSCConn *conn, Msg *sms)
{
@@ -1635,6 +1934,7 @@
cfg_get_bool(conndata-no_sep, cfg, octstr_imm(no-sep));
conndata-proxy = cfg_get(cfg, octstr_imm(system-id));
conndata-alt_charset = cfg_get(cfg, octstr_imm(alt-charset));
+conndata-fieldmap = generic_get_field_map(cfg);
--- conndata-fieldmap = NULL:
if (conndata-send_url == NULL)
panic(0, HTTP[%s]: Sending not allowed. No 'send-url'
specified.,
@@ -1693,7 +1993,7 @@
octstr_get_cstr(conn-id));
goto error;
}
---conndata-fieldmap = generic_get_field_map(cfg);
-conndata-receive_sms = kannel_receive_sms; /* emulate
sendsms interface */
+conndata-receive_sms = generic_receive_sms; /* emulate
sendsms interface */
conndata-send_sms = generic_send_sms;
conndata-parse_reply = generic_parse_reply;
Thanks,
Alex
Am 09.06.2009 um 10:14 schrieb Alejandro Guerrieri:
Ok, here's a new version of my patch to add support for custom MO
parameters on the generic http-smsc.
New features:
1. Support for setting the numeric response code for successful and
failed requests (as it is now, it always returns 202 HTTP_ACCEPTED).
2. Support for setting the text response for successful requests
(right now it returns Sent.).
3. Some code cleanups (extra lines, parameter expansion after
authorization).
4. Documentation.
http://www.blogalex.com/archives/192
I can commit if no objections.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 01/06/2009, at 22:50, Alexander Malysh wrote:
Hi,
here some comments...
in generic_receive_sms you first receive all values than converts
it and only
after this done check authorization. Make no sense... first check
auth then convert anything.
+else if (from == NULL || to == NULL || text == NULL) {
+
+error(0, HTTP[%s]: Insufficient args,
why extra line?
I think retmsg should also be configurable. Because not all
gateways will accept 'Sent' as response.
I think even HTTP error code for not accepted MOs/DLRs should be
configurable.
Thanks,
Alex
P.S. And userguide part would be nice ;)
Am 28.05.2009 um 23:00 schrieb Alejandro Guerrieri:
HI,
I've finished my patch to configure the parameter names for MO on
the generic http-smsc.
To use it you just add a few entries on the smsc definition, only
with the parameters you want to rename.
e.g:
generic-param-from = phoneNumber
generic-param-to = shortCode
generic-param-text = message
More details and the patch here:
http://www.blogalex.com/archives/171
Of course I'm writing the userguide part if this goes forward :)
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
Re: [PATCH] custom MO Parameters for smsc-http
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to receive
UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset should be
taken in account...
I'm not adding anything new here, the MO handling is built on the
original code for kannel_receive_sms (which was the default interface
for MO on the generic interface anyway). There's no charset handling
in there either. I agree it makes sense to have charset handling,
since an http interface should be as flexible as possible, but is it a
showstopper at this point?
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in DLR
storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid != NULL) {
+/* we got a DLR, and we don't require additional values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm this check is not complete. it should be udh_len + msgdata_len
but msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh) MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long, rejected,
+ octstr_get_cstr(conn-id));
+retmsg = octstr_create(UDH field is too long, rejected);
+retstatus = fm-status_error;
+}
Idem... this is from kannel_receive_sms as well. If it's wrong here,
then it's wrong on the kannel smsc as well.
why do you always load generic config options ?
static void generic_send_sms(SMSCConn *conn, Msg *sms)
{
@@ -1635,6 +1934,7 @@
cfg_get_bool(conndata-no_sep, cfg, octstr_imm(no-sep));
conndata-proxy = cfg_get(cfg, octstr_imm(system-id));
conndata-alt_charset = cfg_get(cfg, octstr_imm(alt-charset));
+conndata-fieldmap = generic_get_field_map(cfg);
--- conndata-fieldmap = NULL:
if (conndata-send_url == NULL)
panic(0, HTTP[%s]: Sending not allowed. No 'send-url'
specified.,
@@ -1693,7 +1993,7 @@
octstr_get_cstr(conn-id));
goto error;
}
---conndata-fieldmap = generic_get_field_map(cfg);
-conndata-receive_sms = kannel_receive_sms; /* emulate
sendsms interface */
+conndata-receive_sms = generic_receive_sms; /* emulate
sendsms interface */
conndata-send_sms = generic_send_sms;
conndata-parse_reply = generic_parse_reply;
True, it's a waste of CPU cycles if you're using other smsc-types
instead. Fixing it.
Thanks,
Alex
Am 09.06.2009 um 10:14 schrieb Alejandro Guerrieri:
Ok, here's a new version of my patch to add support for custom MO
parameters on the generic http-smsc.
New features:
1. Support for setting the numeric response code for successful and
failed requests (as it is now, it always returns 202 HTTP_ACCEPTED).
2. Support for setting the text response for successful requests
(right now it returns Sent.).
3. Some code cleanups (extra lines, parameter expansion after
authorization).
4. Documentation.
http://www.blogalex.com/archives/192
I can commit if no objections.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 01/06/2009, at 22:50, Alexander Malysh wrote:
Hi,
here some comments...
in generic_receive_sms you first receive all values than converts
it and only
after this done check authorization. Make no sense... first check
auth then convert anything.
+else if (from == NULL || to == NULL || text == NULL) {
+
+error(0, HTTP[%s]: Insufficient args,
why extra line?
I think retmsg should also be configurable. Because not all
gateways will accept 'Sent' as response.
I think even HTTP error code for not accepted MOs/DLRs should be
configurable.
Thanks,
Alex
P.S. And userguide part would be nice ;)
Am 28.05.2009 um 23:00 schrieb Alejandro Guerrieri:
HI,
I've finished my patch to configure the parameter names for MO on
the generic http-smsc.
To use it you just add a few entries on the smsc definition, only
with the parameters you want to rename.
e.g:
generic-param-from = phoneNumber
generic-param-to = shortCode
generic-param-text = message
More details and the patch here:
http://www.blogalex.com/archives/171
Of course I'm writing the userguide part if this goes forward :)
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
Re: [PATCH] custom MO Parameters for smsc-http
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to receive
UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset should be
taken in account...
I'm not adding anything new here, the MO handling is built on the
original code for kannel_receive_sms (which was the default
interface for MO on the generic interface anyway). There's no
charset handling in there either. I agree it makes sense to have
charset handling, since an http interface should be as flexible as
possible, but is it a showstopper at this point?
It is not really show stopper but if it will not be added now it will
remain so for ages. It is not a problem for kannel_receive_sms because
it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in DLR
storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid != NULL) {
+/* we got a DLR, and we don't require additional values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR. Could you
please fix both interfaces?
hmm this check is not complete. it should be udh_len + msgdata_len
but msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh) MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long, rejected,
+ octstr_get_cstr(conn-id));
+retmsg = octstr_create(UDH field is too long, rejected);
+retstatus = fm-status_error;
+}
Idem... this is from kannel_receive_sms as well. If it's wrong here,
then it's wrong on the kannel smsc as well.
Hmm seems, I'm wrong here. This check checks for the right UDH but
allows long MO messages.
why do you always load generic config options ?
static void generic_send_sms(SMSCConn *conn, Msg *sms)
{
@@ -1635,6 +1934,7 @@
cfg_get_bool(conndata-no_sep, cfg, octstr_imm(no-sep));
conndata-proxy = cfg_get(cfg, octstr_imm(system-id));
conndata-alt_charset = cfg_get(cfg, octstr_imm(alt-charset));
+conndata-fieldmap = generic_get_field_map(cfg);
--- conndata-fieldmap = NULL:
if (conndata-send_url == NULL)
panic(0, HTTP[%s]: Sending not allowed. No 'send-url'
specified.,
@@ -1693,7 +1993,7 @@
octstr_get_cstr(conn-id));
goto error;
}
---conndata-fieldmap = generic_get_field_map(cfg);
-conndata-receive_sms = kannel_receive_sms; /* emulate
sendsms interface */
+conndata-receive_sms = generic_receive_sms; /* emulate
sendsms interface */
conndata-send_sms = generic_send_sms;
conndata-parse_reply = generic_parse_reply;
True, it's a waste of CPU cycles if you're using other smsc-types
instead. Fixing it.
Thanks,
Alex
Am 09.06.2009 um 10:14 schrieb Alejandro Guerrieri:
Ok, here's a new version of my patch to add support for custom MO
parameters on the generic http-smsc.
New features:
1. Support for setting the numeric response code for successful
and failed requests (as it is now, it always returns 202
HTTP_ACCEPTED).
2. Support for setting the text response for successful requests
(right now it returns Sent.).
3. Some code cleanups (extra lines, parameter expansion after
authorization).
4. Documentation.
http://www.blogalex.com/archives/192
I can commit if no objections.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 01/06/2009, at 22:50, Alexander Malysh wrote:
Hi,
here some comments...
in generic_receive_sms you first receive all values than converts
it and only
after this done check authorization. Make no sense... first check
auth then convert anything.
+else if (from == NULL || to == NULL || text == NULL) {
+
+error(0, HTTP[%s]: Insufficient args,
why extra line?
I think retmsg should also be configurable. Because not all
gateways will accept 'Sent' as response.
I think even HTTP error code for not accepted MOs/DLRs should be
configurable.
Thanks,
Alex
P.S. And userguide part would be nice ;)
Am 28.05.2009 um 23:00 schrieb Alejandro Guerrieri:
HI,
I've finished my patch to configure the parameter names for MO
on the generic http-smsc.
To use it you just add a few entries on the smsc definition,
only with the parameters you want to rename.
e.g:
generic-param-from = phoneNumber
generic-param-to = shortCode
generic-param-text = message
More details and the patch here:
http://www.blogalex.com/archives/171
Of course I'm writing the userguide part if this goes forward :)
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
Re: [PATCH] custom MO Parameters for smsc-http
Alex,
Regarding the charsets, I agree it's better to tackle it now that
leave it for later (aka, never ;) ).
I'm fixing the charset issue and the dlr bugs and resending later.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:17, Alexander Malysh wrote:
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to receive
UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset should be
taken in account...
I'm not adding anything new here, the MO handling is built on the
original code for kannel_receive_sms (which was the default
interface for MO on the generic interface anyway). There's no
charset handling in there either. I agree it makes sense to have
charset handling, since an http interface should be as flexible as
possible, but is it a showstopper at this point?
It is not really show stopper but if it will not be added now it
will remain so for ages. It is not a problem for kannel_receive_sms
because it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in DLR
storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid != NULL) {
+/* we got a DLR, and we don't require additional values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR. Could you
please fix both interfaces?
hmm this check is not complete. it should be udh_len + msgdata_len
but msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh) MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long, rejected,
+ octstr_get_cstr(conn-id));
+retmsg = octstr_create(UDH field is too long, rejected);
+retstatus = fm-status_error;
+}
Idem... this is from kannel_receive_sms as well. If it's wrong
here, then it's wrong on the kannel smsc as well.
Hmm seems, I'm wrong here. This check checks for the right UDH but
allows long MO messages.
why do you always load generic config options ?
static void generic_send_sms(SMSCConn *conn, Msg *sms)
{
@@ -1635,6 +1934,7 @@
cfg_get_bool(conndata-no_sep, cfg, octstr_imm(no-sep));
conndata-proxy = cfg_get(cfg, octstr_imm(system-id));
conndata-alt_charset = cfg_get(cfg, octstr_imm(alt-charset));
+conndata-fieldmap = generic_get_field_map(cfg);
--- conndata-fieldmap = NULL:
if (conndata-send_url == NULL)
panic(0, HTTP[%s]: Sending not allowed. No 'send-url'
specified.,
@@ -1693,7 +1993,7 @@
octstr_get_cstr(conn-id));
goto error;
}
---conndata-fieldmap = generic_get_field_map(cfg);
-conndata-receive_sms = kannel_receive_sms; /* emulate
sendsms interface */
+conndata-receive_sms = generic_receive_sms; /* emulate
sendsms interface */
conndata-send_sms = generic_send_sms;
conndata-parse_reply = generic_parse_reply;
True, it's a waste of CPU cycles if you're using other smsc-types
instead. Fixing it.
Thanks,
Alex
Am 09.06.2009 um 10:14 schrieb Alejandro Guerrieri:
Ok, here's a new version of my patch to add support for custom MO
parameters on the generic http-smsc.
New features:
1. Support for setting the numeric response code for successful
and failed requests (as it is now, it always returns 202
HTTP_ACCEPTED).
2. Support for setting the text response for successful requests
(right now it returns Sent.).
3. Some code cleanups (extra lines, parameter expansion after
authorization).
4. Documentation.
http://www.blogalex.com/archives/192
I can commit if no objections.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 01/06/2009, at 22:50, Alexander Malysh wrote:
Hi,
here some comments...
in generic_receive_sms you first receive all values than
converts it and only
after this done check authorization. Make no sense... first
check auth then convert anything.
+else if (from == NULL || to == NULL || text == NULL) {
+
+error(0, HTTP[%s]: Insufficient args,
why extra line?
I think retmsg should also be configurable. Because not all
gateways will accept 'Sent' as response.
I think even HTTP error code for not accepted MOs/DLRs should be
configurable.
Thanks,
Alex
P.S. And userguide part would be nice ;)
Am 28.05.2009 um 23:00 schrieb Alejandro Guerrieri:
HI,
I've finished my patch to configure the parameter names for MO
on the generic http-smsc.
To use it you just add a few entries on the smsc definition,
only with the parameters you want to rename.
e.g:
generic-param-from = phoneNumber
generic-param-to =
Re: [PATCH] custom MO Parameters for smsc-http
Am 09.06.2009 um 11:23 schrieb Alejandro Guerrieri:
Alex,
Regarding the charsets, I agree it's better to tackle it now that
leave it for later (aka, never ;) ).
I'm fixing the charset issue and the dlr bugs and resending later.
thanks alex!
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:17, Alexander Malysh wrote:
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to receive
UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset should be
taken in account...
I'm not adding anything new here, the MO handling is built on the
original code for kannel_receive_sms (which was the default
interface for MO on the generic interface anyway). There's no
charset handling in there either. I agree it makes sense to have
charset handling, since an http interface should be as flexible as
possible, but is it a showstopper at this point?
It is not really show stopper but if it will not be added now it
will remain so for ages. It is not a problem for kannel_receive_sms
because it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of
code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in DLR
storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid != NULL) {
+/* we got a DLR, and we don't require additional values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR. Could
you please fix both interfaces?
hmm this check is not complete. it should be udh_len +
msgdata_len but msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh) MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long, rejected,
+ octstr_get_cstr(conn-id));
+retmsg = octstr_create(UDH field is too long, rejected);
+retstatus = fm-status_error;
+}
Idem... this is from kannel_receive_sms as well. If it's wrong
here, then it's wrong on the kannel smsc as well.
Hmm seems, I'm wrong here. This check checks for the right UDH but
allows long MO messages.
why do you always load generic config options ?
static void generic_send_sms(SMSCConn *conn, Msg *sms)
{
@@ -1635,6 +1934,7 @@
cfg_get_bool(conndata-no_sep, cfg, octstr_imm(no-sep));
conndata-proxy = cfg_get(cfg, octstr_imm(system-id));
conndata-alt_charset = cfg_get(cfg, octstr_imm(alt-charset));
+conndata-fieldmap = generic_get_field_map(cfg);
--- conndata-fieldmap = NULL:
if (conndata-send_url == NULL)
panic(0, HTTP[%s]: Sending not allowed. No 'send-url'
specified.,
@@ -1693,7 +1993,7 @@
octstr_get_cstr(conn-id));
goto error;
}
---conndata-fieldmap = generic_get_field_map(cfg);
-conndata-receive_sms = kannel_receive_sms; /* emulate
sendsms interface */
+conndata-receive_sms = generic_receive_sms; /* emulate
sendsms interface */
conndata-send_sms = generic_send_sms;
conndata-parse_reply = generic_parse_reply;
True, it's a waste of CPU cycles if you're using other smsc-types
instead. Fixing it.
Thanks,
Alex
Am 09.06.2009 um 10:14 schrieb Alejandro Guerrieri:
Ok, here's a new version of my patch to add support for custom
MO parameters on the generic http-smsc.
New features:
1. Support for setting the numeric response code for successful
and failed requests (as it is now, it always returns 202
HTTP_ACCEPTED).
2. Support for setting the text response for successful requests
(right now it returns Sent.).
3. Some code cleanups (extra lines, parameter expansion after
authorization).
4. Documentation.
http://www.blogalex.com/archives/192
I can commit if no objections.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 01/06/2009, at 22:50, Alexander Malysh wrote:
Hi,
here some comments...
in generic_receive_sms you first receive all values than
converts it and only
after this done check authorization. Make no sense... first
check auth then convert anything.
+else if (from == NULL || to == NULL || text == NULL) {
+
+error(0, HTTP[%s]: Insufficient args,
why extra line?
I think retmsg should also be configurable. Because not all
gateways will accept 'Sent' as response.
I think even HTTP error code for not accepted MOs/DLRs should
be configurable.
Thanks,
Alex
P.S. And userguide part would be nice ;)
Am 28.05.2009 um 23:00 schrieb Alejandro Guerrieri:
HI,
I've finished my patch to configure the parameter names for MO
on the generic http-smsc.
To use it you just add a few entries on the smsc definition,
only with the parameters you want to
Re: LMT extensions
Hi, LMT uses SMPP meta-data optional parameters, its easy to implement it using meta-data build. LMT additionally uses two specific PDU's (LMT_REPORT and LMT_REPORT_RESP) what must be programmed directly into Kannel (those are actually LMT specific DLR PDU's and can be mapped to DLR requests in Kannel) We are using cvs-meta-data build with LMT patch, works correctly. Illimar Hi, without their Spec is this impossible to say if Kannel can handle this... Please provide Spec. Thanks, Alex Am 09.06.2009 um 10:11 schrieb V: Hello, Any have some experience with connection to LMT operator in Latvia with proprietary SMPP extensions for DLR and billing reports? I found previous thread about it, but with no decisions..:( Kind regards, Martynas - Hi, Am I right that LMT uses reserved command ids there? If yes, then in my opinion it may be useful to implement some API for adding vendor specific SMPP commands processing as DSO and after this LMT extension as such DSO :-) Illimar Reinbusch - Telejazz.com wrote: LMT uses SMPP procol with some additions to it for billing and DLR purpose. * *For example:* * **LMT_REPORT – Contains information regarding the result of the processing and execution of the SUBMIT_SM command;* *LMT_GEN_CODE_RESP – Contains information regarding the result of the processing and execution of the LMT_GEN_CODE command** LMT_VERIFY_CODE_RESP – Contains information regarding the result of the processing and execution of the LMT_ VERIFY_CODE command; * *LMT_REPORT_RESP – contains information regarding the results of the LMT_REPORT command’s execution;* *LMT_GEN_CODE – requests to generate access information for the Service provider’s public resource, if authorization is made according to the procedure outlined in Art.3.7. and 3.8. of the Addendum No.2 to this Contract;* *LMT_VERIFY_CODE – requests to verify the access information provided by the Client for the public resource; Illimar Hi, what is LMT extention? Could you please provide some links? Illimar Reinbusch - Telejazz.com wrote: Have somebody implemented it or its new to Kannel. Would Kannel be interested adding support for it to Kannel if someone (me) would write it? Illimar Jurijs Cerepanovs wrote: Illimar Reinbusch - Telejazz.com wrote: Current implementation needs patch for kannel - it's simply to rewrite smpp connector for understanding LMT_REPORT e.t.c proprietary packets. Hi Has anybody implemented or added new protocol to support Latvia LMT operator SMPP protocol with LMT extentsions? Would u suggest adding to to current SMPP development or add new protocol based on SMPP implementation? Thanks, Illimar -- Michael Bochkaryov www.netstyle.com.ua
Re: LMT extensions
Am 09.06.2009 um 11:32 schrieb Illimar Reinbusch: Hi, LMT uses SMPP meta-data optional parameters, its easy to implement it using meta-data build. LMT additionally uses two specific PDU's (LMT_REPORT and LMT_REPORT_RESP) what must be programmed directly into Kannel (those are actually LMT specific DLR PDU's and can be mapped to DLR requests in Kannel) uuuhhh, why do they need new PDUs? Is deliver_sm not enough seems their technicals didn't read SMPP spec or missing some pages in SMPP spec ;) Thanks, Alex We are using cvs-meta-data build with LMT patch, works correctly. Illimar Hi, without their Spec is this impossible to say if Kannel can handle this... Please provide Spec. Thanks, Alex Am 09.06.2009 um 10:11 schrieb V: Hello, Any have some experience with connection to LMT operator in Latvia with proprietary SMPP extensions for DLR and billing reports? I found previous thread about it, but with no decisions..:( Kind regards, Martynas - Hi, Am I right that LMT uses reserved command ids there? If yes, then in my opinion it may be useful to implement some API for adding vendor specific SMPP commands processing as DSO and after this LMT extension as such DSO :-) Illimar Reinbusch - Telejazz.com wrote: LMT uses SMPP procol with some additions to it for billing and DLR purpose. * *For example:* * **LMT_REPORT – Contains information regarding the result of the processing and execution of the SUBMIT_SM command;* *LMT_GEN_CODE_RESP – Contains information regarding the result of the processing and execution of the LMT_GEN_CODE command** LMT_VERIFY_CODE_RESP – Contains information regarding the result of the processing and execution of the LMT_ VERIFY_CODE command; * *LMT_REPORT_RESP – contains information regarding the results of the LMT_REPORT command’s execution;* *LMT_GEN_CODE – requests to generate access information for the Service provider’s public resource, if authorization is made according to the procedure outlined in Art.3.7. and 3.8. of the Addendum No.2 to this Contract;* *LMT_VERIFY_CODE – requests to verify the access information provided by the Client for the public resource; Illimar Hi, what is LMT extention? Could you please provide some links? Illimar Reinbusch - Telejazz.com wrote: Have somebody implemented it or its new to Kannel. Would Kannel be interested adding support for it to Kannel if someone (me) would write it? Illimar Jurijs Cerepanovs wrote: Illimar Reinbusch - Telejazz.com wrote: Current implementation needs patch for kannel - it's simply to rewrite smpp connector for understanding LMT_REPORT e.t.c proprietary packets. Hi Has anybody implemented or added new protocol to support Latvia LMT operator SMPP protocol with LMT extentsions? Would u suggest adding to to current SMPP development or add new protocol based on SMPP implementation? Thanks, Illimar -- Michael Bochkaryov www.netstyle.com.ua
Re: LMT extensions
Hello, Yes, we already run kannel with meta-data/tlv support (cvs branch). But, it's strange, why LMT use some PDU, that are non standart. On what conditions we could get that patch? regards, Martynas Hi, LMT uses SMPP meta-data optional parameters, its easy to implement it using meta-data build. LMT additionally uses two specific PDU's (LMT_REPORT and LMT_REPORT_RESP) what must be programmed directly into Kannel (those are actually LMT specific DLR PDU's and can be mapped to DLR requests in Kannel) We are using cvs-meta-data build with LMT patch, works correctly. Illimar Hi, without their Spec is this impossible to say if Kannel can handle this... Please provide Spec. Thanks, Alex Am 09.06.2009 um 10:11 schrieb V: Hello, Any have some experience with connection to LMT operator in Latvia with proprietary SMPP extensions for DLR and billing reports? I found previous thread about it, but with no decisions..:( Kind regards, Martynas - Hi, Am I right that LMT uses reserved command ids there? If yes, then in my opinion it may be useful to implement some API for adding vendor specific SMPP commands processing as DSO and after this LMT extension as such DSO :-) Illimar Reinbusch - Telejazz.com wrote: LMT uses SMPP procol with some additions to it for billing and DLR purpose. * *For example:* * **LMT_REPORT – Contains information regarding the result of the processing and execution of the SUBMIT_SM command;* *LMT_GEN_CODE_RESP – Contains information regarding the result of the processing and execution of the LMT_GEN_CODE command** LMT_VERIFY_CODE_RESP – Contains information regarding the result of the processing and execution of the LMT_ VERIFY_CODE command; * *LMT_REPORT_RESP – contains information regarding the results of the LMT_REPORT command’s execution;* *LMT_GEN_CODE – requests to generate access information for the Service provider’s public resource, if authorization is made according to the procedure outlined in Art.3.7. and 3.8. of the Addendum No.2 to this Contract;* *LMT_VERIFY_CODE – requests to verify the access information provided by the Client for the public resource; Illimar Hi, what is LMT extention? Could you please provide some links? Illimar Reinbusch - Telejazz.com wrote: Have somebody implemented it or its new to Kannel. Would Kannel be interested adding support for it to Kannel if someone (me) would write it? Illimar Jurijs Cerepanovs wrote: Illimar Reinbusch - Telejazz.com wrote: Current implementation needs patch for kannel - it's simply to rewrite smpp connector for understanding LMT_REPORT e.t.c proprietary packets. Hi Has anybody implemented or added new protocol to support Latvia LMT operator SMPP protocol with LMT extentsions? Would u suggest adding to to current SMPP development or add new protocol based on SMPP implementation? Thanks, Illimar -- Michael Bochkaryov www.netstyle.com.ua
Re: ota_compiler.c patch
Hi, I've applied the patch on my cvs env, tested sendota and had same behaviour as i had with 1.4.1, so it's basically a works for me. Thank you Nikos last word to Stipe Julien 2009/6/9 Alexander Malysh amal...@kannel.org: Hi, if I look through the code, Niko is right. Stipe could you .confirm this? Thanks, Alex Am 08.06.2009 um 22:09 schrieb Nikos Balkanas: Dear Stipe, On 2008/10/22 Rev 1.16 you reordered the INLINE attributes in ota_compiler.c. That broke the code in ota_compiler.c that relied on INLINE to be the last available option, if no prior matches are found. I hope you don't mind, i reverted back your changes, so that i can close a few tickets. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Cc: tom...@megalogika.lt; Pai Peng sipai...@gmail.com; Julien Buratto julien.bura...@gmail.com Sent: Monday, June 08, 2009 10:57 PM Subject: ota_compiler.c patch Hi, Actually i was mistakenly looking at the wrong place. wap-provisioningdoc has being supported all along. However, an incompletely tested feature at some point had an undesirable side effect. Let me know also if you would prefer text to take as value the name of an xml file, instead of a huge urlencoded string. this would align it more with the documentation. I know I do. I have no way of testing the code, except running it through the debugger, so please test it and let me know how it goes. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org; Pai Peng sipai...@gmail.com Sent: Monday, June 08, 2009 11:03 AM Subject: Re: sendota problems Oops! Forgot to ask. Can't you use a characteristic-list xml document to do your job? Kannel fully supports those! BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org; Pai Peng sipai...@gmail.com Sent: Monday, June 08, 2009 6:11 AM Subject: Re: sendota problems Hi Julien, I looked it up and it is not trivial. As it stands kannel supports only the Nokia OTA characteristic-list specs. It doesn't support the wap-provisioningdoc specs. As such a complete reworking of the ota-compiler would be needed to accomodate it. Since I am lacking ota development/testing environment, and is only of marginal interest to me, I am sorry but I cannot pursue it further. What I can do is, to make a patch, so that kannel prints an error when it detects such a document and drops it. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org Sent: Saturday, June 06, 2009 9:19 AM Subject: Re: sendota problems Not, unfortunately. I was going crazy all this time at work, but I just finished. I will look at it over this weekend. BR, Nikos - Original Message - From: Julien Buratto julien.bura...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org Sent: Thursday, May 28, 2009 3:16 PM Subject: Re: sendota problems Hi Nikos, where you able to fix the issue ? 2009/3/17 Nikos Balkanas nbalka...@gmail.com: Hi, There seems to be an incombatibility between kannel's wbxml and Nokia's. I intend to fix it, but in a month or so. In the meantime you might want to compile the message manually, as described by Pai Peng. BR, Nikos - Original Message - From: Tomas Verbaitis tom...@megalogika.lt To: us...@kannel.org Sent: Monday, March 16, 2009 1:24 PM Subject: sendota problems Hello, I want to configure synchronization for Nokia 6070 mobile phone. My program generates this XML provisioning document: ?xml version=1.0? !DOCTYPE wap-provisioningdoc PUBLIC -//WAPFORUM//DTD PROV 1.0//EN http://www.wapforum.org/DTD/prov.dtd; wap-provisioningdoc characteristic type=BOOTSTRAP parm name=NAME value=SKLADDEVEL/ /characteristic characteristic type=APPLICATION parm name=APPID value=w5/ parm name=TO-NAPID value=INTERNET / parm name=NAME value=SKLADDEVEL/ parm name=ADDR value=http://megalogika.stp.lt/funambol/ds/ characteristic type=RESOURCE parm name=URI value=card/ parm name=NAME value=Contacts DB/ parm name=AACCEPT value=text/x-vcard/ /characteristic characteristic type=RESOURCE parm name=URI value=cal/ parm name=NAME value=Calendar/ parm name=AACCEPT value=text/x-vcalendar/ /characteristic characteristic type=RESOURCE parm name=URI value=notes/ parm name=NAME value=Notes/ parm name=AACCEPT value=text/plain/ /characteristic characteristic type=APPAUTH parm name=AAUTHNAME value=funUsrVe/ parm name=AAUTHSECRET value=funPassVe/ /characteristic /characteristic /wap-provisioningdoc When i send it via Kannel's /sendota, via this request:
Re: [PATCH] custom MO Parameters for smsc-http
Ok, done!
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params1.patch
I've fixed the dlr-url bug _only_ on the generic part. If no
objections, I'm doing a second patch to fix it on the kannel smsc
(since it's in fact a separate issue).
I've also fixed a small glitch on the dlrmsg response code (I was
using the error status code for successful submits as well).
Last but not least, I've added url translation to the response
message, so now you can include escape codes on the response, which
may come handy on many cases (for example, to return kannel's message
id on the requests). Userguide part updated accordingly.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:27, Alexander Malysh wrote:
Am 09.06.2009 um 11:23 schrieb Alejandro Guerrieri:
Alex,
Regarding the charsets, I agree it's better to tackle it now that
leave it for later (aka, never ;) ).
I'm fixing the charset issue and the dlr bugs and resending later.
thanks alex!
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:17, Alexander Malysh wrote:
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to receive
UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset should be
taken in account...
I'm not adding anything new here, the MO handling is built on the
original code for kannel_receive_sms (which was the default
interface for MO on the generic interface anyway). There's no
charset handling in there either. I agree it makes sense to have
charset handling, since an http interface should be as flexible
as possible, but is it a showstopper at this point?
It is not really show stopper but if it will not be added now it
will remain so for ages. It is not a problem for
kannel_receive_sms because it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of
code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in DLR
storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid != NULL) {
+/* we got a DLR, and we don't require additional values
*/
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR. Could
you please fix both interfaces?
hmm this check is not complete. it should be udh_len +
msgdata_len but msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh) MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long, rejected,
+ octstr_get_cstr(conn-id));
+retmsg = octstr_create(UDH field is too long,
rejected);
+retstatus = fm-status_error;
+}
Idem... this is from kannel_receive_sms as well. If it's wrong
here, then it's wrong on the kannel smsc as well.
Hmm seems, I'm wrong here. This check checks for the right UDH but
allows long MO messages.
why do you always load generic config options ?
static void generic_send_sms(SMSCConn *conn, Msg *sms)
{
@@ -1635,6 +1934,7 @@
cfg_get_bool(conndata-no_sep, cfg, octstr_imm(no-sep));
conndata-proxy = cfg_get(cfg, octstr_imm(system-id));
conndata-alt_charset = cfg_get(cfg, octstr_imm(alt-charset));
+conndata-fieldmap = generic_get_field_map(cfg);
--- conndata-fieldmap = NULL:
if (conndata-send_url == NULL)
panic(0, HTTP[%s]: Sending not allowed. No 'send-url'
specified.,
@@ -1693,7 +1993,7 @@
octstr_get_cstr(conn-id));
goto error;
}
---conndata-fieldmap = generic_get_field_map(cfg);
-conndata-receive_sms = kannel_receive_sms; /* emulate
sendsms interface */
+conndata-receive_sms = generic_receive_sms; /* emulate
sendsms interface */
conndata-send_sms = generic_send_sms;
conndata-parse_reply = generic_parse_reply;
True, it's a waste of CPU cycles if you're using other smsc-types
instead. Fixing it.
Thanks,
Alex
Am 09.06.2009 um 10:14 schrieb Alejandro Guerrieri:
Ok, here's a new version of my patch to add support for custom
MO parameters on the generic http-smsc.
New features:
1. Support for setting the numeric response code for successful
and failed requests (as it is now, it always returns 202
HTTP_ACCEPTED).
2. Support for setting the text response for successful
requests (right now it returns Sent.).
3. Some code cleanups (extra lines, parameter expansion after
authorization).
4. Documentation.
http://www.blogalex.com/archives/192
I can commit if no objections.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 01/06/2009, at 22:50, Alexander Malysh wrote:
Hi,
here some comments...
in generic_receive_sms you first receive
Re: ota_compiler.c patch
Thanx, What about setting text to an external xml file, as is in manual. Any interest in that? BR, Nikos - Original Message - From: Julien Buratto julien.bura...@gmail.com To: Alexander Malysh amal...@kannel.org Cc: kannel_dev_mailinglist Devel devel@kannel.org Sent: Tuesday, June 09, 2009 1:36 PM Subject: Re: ota_compiler.c patch Hi, I've applied the patch on my cvs env, tested sendota and had same behaviour as i had with 1.4.1, so it's basically a works for me. Thank you Nikos last word to Stipe Julien 2009/6/9 Alexander Malysh amal...@kannel.org: Hi, if I look through the code, Niko is right. Stipe could you .confirm this? Thanks, Alex Am 08.06.2009 um 22:09 schrieb Nikos Balkanas: Dear Stipe, On 2008/10/22 Rev 1.16 you reordered the INLINE attributes in ota_compiler.c. That broke the code in ota_compiler.c that relied on INLINE to be the last available option, if no prior matches are found. I hope you don't mind, i reverted back your changes, so that i can close a few tickets. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Cc: tom...@megalogika.lt; Pai Peng sipai...@gmail.com; Julien Buratto julien.bura...@gmail.com Sent: Monday, June 08, 2009 10:57 PM Subject: ota_compiler.c patch Hi, Actually i was mistakenly looking at the wrong place. wap-provisioningdoc has being supported all along. However, an incompletely tested feature at some point had an undesirable side effect. Let me know also if you would prefer text to take as value the name of an xml file, instead of a huge urlencoded string. this would align it more with the documentation. I know I do. I have no way of testing the code, except running it through the debugger, so please test it and let me know how it goes. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org; Pai Peng sipai...@gmail.com Sent: Monday, June 08, 2009 11:03 AM Subject: Re: sendota problems Oops! Forgot to ask. Can't you use a characteristic-list xml document to do your job? Kannel fully supports those! BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org; Pai Peng sipai...@gmail.com Sent: Monday, June 08, 2009 6:11 AM Subject: Re: sendota problems Hi Julien, I looked it up and it is not trivial. As it stands kannel supports only the Nokia OTA characteristic-list specs. It doesn't support the wap-provisioningdoc specs. As such a complete reworking of the ota-compiler would be needed to accomodate it. Since I am lacking ota development/testing environment, and is only of marginal interest to me, I am sorry but I cannot pursue it further. What I can do is, to make a patch, so that kannel prints an error when it detects such a document and drops it. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org Sent: Saturday, June 06, 2009 9:19 AM Subject: Re: sendota problems Not, unfortunately. I was going crazy all this time at work, but I just finished. I will look at it over this weekend. BR, Nikos - Original Message - From: Julien Buratto julien.bura...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org Sent: Thursday, May 28, 2009 3:16 PM Subject: Re: sendota problems Hi Nikos, where you able to fix the issue ? 2009/3/17 Nikos Balkanas nbalka...@gmail.com: Hi, There seems to be an incombatibility between kannel's wbxml and Nokia's. I intend to fix it, but in a month or so. In the meantime you might want to compile the message manually, as described by Pai Peng. BR, Nikos - Original Message - From: Tomas Verbaitis tom...@megalogika.lt To: us...@kannel.org Sent: Monday, March 16, 2009 1:24 PM Subject: sendota problems Hello, I want to configure synchronization for Nokia 6070 mobile phone. My program generates this XML provisioning document: ?xml version=1.0? !DOCTYPE wap-provisioningdoc PUBLIC -//WAPFORUM//DTD PROV 1.0//EN http://www.wapforum.org/DTD/prov.dtd; wap-provisioningdoc characteristic type=BOOTSTRAP parm name=NAME value=SKLADDEVEL/ /characteristic characteristic type=APPLICATION parm name=APPID value=w5/ parm name=TO-NAPID value=INTERNET / parm name=NAME value=SKLADDEVEL/ parm name=ADDR value=http://megalogika.stp.lt/funambol/ds/ characteristic type=RESOURCE parm name=URI value=card/ parm name=NAME value=Contacts DB/ parm name=AACCEPT value=text/x-vcard/ /characteristic characteristic type=RESOURCE parm name=URI value=cal/ parm name=NAME value=Calendar/ parm name=AACCEPT value=text/x-vcalendar/ /characteristic characteristic type=RESOURCE parm name=URI value=notes/ parm name=NAME value=Notes/ parm name=AACCEPT value=text/plain/ /characteristic
Re: [PATCH] custom MO Parameters for smsc-http
only one last thing:
+msg-sms.account = octstr_duplicate(account);
+msg-sms.binfo = octstr_duplicate(binfo);
+if (ret == -1) {
+retmsg = octstr_create(Not accepted);
+retstatus = fm-status_error;
+} else {
+retmsg = urltrans_fill_escape_codes(fm-message_sent, msg);
+retstatus = fm-status_sent;
+}
+ret = bb_smscconn_receive(conn, msg);
+}
are you sure you want check ret before bb_smscconn_receive ? ;)
Thanks,
Alex
Am 09.06.2009 um 13:23 schrieb Alejandro Guerrieri:
Ok, done!
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params1.patch
I've fixed the dlr-url bug _only_ on the generic part. If no
objections, I'm doing a second patch to fix it on the kannel smsc
(since it's in fact a separate issue).
I've also fixed a small glitch on the dlrmsg response code (I was
using the error status code for successful submits as well).
Last but not least, I've added url translation to the response
message, so now you can include escape codes on the response, which
may come handy on many cases (for example, to return kannel's
message id on the requests). Userguide part updated accordingly.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:27, Alexander Malysh wrote:
Am 09.06.2009 um 11:23 schrieb Alejandro Guerrieri:
Alex,
Regarding the charsets, I agree it's better to tackle it now that
leave it for later (aka, never ;) ).
I'm fixing the charset issue and the dlr bugs and resending later.
thanks alex!
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:17, Alexander Malysh wrote:
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to receive
UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset should be
taken in account...
I'm not adding anything new here, the MO handling is built on
the original code for kannel_receive_sms (which was the default
interface for MO on the generic interface anyway). There's no
charset handling in there either. I agree it makes sense to have
charset handling, since an http interface should be as flexible
as possible, but is it a showstopper at this point?
It is not really show stopper but if it will not be added now it
will remain so for ages. It is not a problem for
kannel_receive_sms because it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of
code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in DLR
storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid != NULL) {
+/* we got a DLR, and we don't require additional
values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR. Could
you please fix both interfaces?
hmm this check is not complete. it should be udh_len +
msgdata_len but msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh) MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long, rejected,
+ octstr_get_cstr(conn-id));
+retmsg = octstr_create(UDH field is too long,
rejected);
+retstatus = fm-status_error;
+}
Idem... this is from kannel_receive_sms as well. If it's wrong
here, then it's wrong on the kannel smsc as well.
Hmm seems, I'm wrong here. This check checks for the right UDH
but allows long MO messages.
why do you always load generic config options ?
static void generic_send_sms(SMSCConn *conn, Msg *sms)
{
@@ -1635,6 +1934,7 @@
cfg_get_bool(conndata-no_sep, cfg, octstr_imm(no-sep));
conndata-proxy = cfg_get(cfg, octstr_imm(system-id));
conndata-alt_charset = cfg_get(cfg, octstr_imm(alt-charset));
+conndata-fieldmap = generic_get_field_map(cfg);
--- conndata-fieldmap = NULL:
if (conndata-send_url == NULL)
panic(0, HTTP[%s]: Sending not allowed. No 'send-url'
specified.,
@@ -1693,7 +1993,7 @@
octstr_get_cstr(conn-id));
goto error;
}
---conndata-fieldmap = generic_get_field_map(cfg);
-conndata-receive_sms = kannel_receive_sms; /* emulate
sendsms interface */
+conndata-receive_sms = generic_receive_sms; /*
emulate sendsms interface */
conndata-send_sms = generic_send_sms;
conndata-parse_reply = generic_parse_reply;
True, it's a waste of CPU cycles if you're using other smsc-
types instead. Fixing it.
Thanks,
Alex
Am 09.06.2009 um 10:14 schrieb Alejandro Guerrieri:
Ok, here's a new version of my patch to add support for custom
MO parameters on the generic http-smsc.
New features:
1. Support for
Re: ota_compiler.c patch
Hi again, patch commited to cvs. Thanks, Alex P.S. @Niko: could you point me to related bug reports in redmine? Am 09.06.2009 um 14:33 schrieb Nikos Balkanas: Thanx, What about setting text to an external xml file, as is in manual. Any interest in that? BR, Nikos - Original Message - From: Julien Buratto julien.bura...@gmail.com To: Alexander Malysh amal...@kannel.org Cc: kannel_dev_mailinglist Devel devel@kannel.org Sent: Tuesday, June 09, 2009 1:36 PM Subject: Re: ota_compiler.c patch Hi, I've applied the patch on my cvs env, tested sendota and had same behaviour as i had with 1.4.1, so it's basically a works for me. Thank you Nikos last word to Stipe Julien 2009/6/9 Alexander Malysh amal...@kannel.org: Hi, if I look through the code, Niko is right. Stipe could you .confirm this? Thanks, Alex Am 08.06.2009 um 22:09 schrieb Nikos Balkanas: Dear Stipe, On 2008/10/22 Rev 1.16 you reordered the INLINE attributes in ota_compiler.c. That broke the code in ota_compiler.c that relied on INLINE to be the last available option, if no prior matches are found. I hope you don't mind, i reverted back your changes, so that i can close a few tickets. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Cc: tom...@megalogika.lt; Pai Peng sipai...@gmail.com; Julien Buratto julien.bura...@gmail.com Sent: Monday, June 08, 2009 10:57 PM Subject: ota_compiler.c patch Hi, Actually i was mistakenly looking at the wrong place. wap- provisioningdoc has being supported all along. However, an incompletely tested feature at some point had an undesirable side effect. Let me know also if you would prefer text to take as value the name of an xml file, instead of a huge urlencoded string. this would align it more with the documentation. I know I do. I have no way of testing the code, except running it through the debugger, so please test it and let me know how it goes. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org; Pai Peng sipai...@gmail.com Sent: Monday, June 08, 2009 11:03 AM Subject: Re: sendota problems Oops! Forgot to ask. Can't you use a characteristic-list xml document to do your job? Kannel fully supports those! BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org; Pai Peng sipai...@gmail.com Sent: Monday, June 08, 2009 6:11 AM Subject: Re: sendota problems Hi Julien, I looked it up and it is not trivial. As it stands kannel supports only the Nokia OTA characteristic- list specs. It doesn't support the wap-provisioningdoc specs. As such a complete reworking of the ota-compiler would be needed to accomodate it. Since I am lacking ota development/testing environment, and is only of marginal interest to me, I am sorry but I cannot pursue it further. What I can do is, to make a patch, so that kannel prints an error when it detects such a document and drops it. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Julien Buratto julien.bura...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org Sent: Saturday, June 06, 2009 9:19 AM Subject: Re: sendota problems Not, unfortunately. I was going crazy all this time at work, but I just finished. I will look at it over this weekend. BR, Nikos - Original Message - From: Julien Buratto julien.bura...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: tom...@megalogika.lt; us...@kannel.org Sent: Thursday, May 28, 2009 3:16 PM Subject: Re: sendota problems Hi Nikos, where you able to fix the issue ? 2009/3/17 Nikos Balkanas nbalka...@gmail.com: Hi, There seems to be an incombatibility between kannel's wbxml and Nokia's. I intend to fix it, but in a month or so. In the meantime you might want to compile the message manually, as described by Pai Peng. BR, Nikos - Original Message - From: Tomas Verbaitis tom...@megalogika.lt To: us...@kannel.org Sent: Monday, March 16, 2009 1:24 PM Subject: sendota problems Hello, I want to configure synchronization for Nokia 6070 mobile phone. My program generates this XML provisioning document: ?xml version=1.0? !DOCTYPE wap-provisioningdoc PUBLIC -//WAPFORUM//DTD PROV 1.0//EN http://www.wapforum.org/DTD/prov.dtd; wap-provisioningdoc characteristic type=BOOTSTRAP parm name=NAME value=SKLADDEVEL/ /characteristic characteristic type=APPLICATION parm name=APPID value=w5/ parm name=TO-NAPID value=INTERNET / parm name=NAME value=SKLADDEVEL/ parm name=ADDR value=http://megalogika.stp.lt/funambol/ ds/ characteristic type=RESOURCE parm name=URI value=card/ parm name=NAME value=Contacts DB/ parm name=AACCEPT value=text/x-vcard/ /characteristic characteristic type=RESOURCE parm name=URI value=cal/ parm name=NAME
Re: [PATCH] custom MO Parameters for smsc-http
Yes, I have to move that afterwards, otherwise the
urltrans_fill_escape_codes call would panic:
2009-06-09 12:46:13 [15580] [6] PANIC: gwlib/octstr.c:2488:
seems_valid_real: Assertion `ostr-len = 0' failed. (Called from
gwlib/octstr.c:1552:octstr_split_words.)
...
2009-06-09 12:46:13 [15580] [6] PANIC: 0
bearerbox 0x0009136d gw_panic + 253
2009-06-09 12:46:13 [15580] [6] PANIC: 1
bearerbox 0x000925de log_thread_to + 750
2009-06-09 12:46:13 [15580] [6] PANIC: 2
bearerbox 0x0009b360 octstr_split_words + 48
2009-06-09 12:46:13 [15580] [6] PANIC: 3
bearerbox 0x000191e2
urltrans_fill_escape_codes + 114
2009-06-09 12:46:13 [15580] [6] PANIC: 4
bearerbox 0x0005d91b smsc_fake_create + 21803
Probably the bb_smscconn_receive call destroys the msg structure?
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:16, Alexander Malysh wrote:
only one last thing:
+msg-sms.account = octstr_duplicate(account);
+msg-sms.binfo = octstr_duplicate(binfo);
+if (ret == -1) {
+retmsg = octstr_create(Not accepted);
+retstatus = fm-status_error;
+} else {
+retmsg = urltrans_fill_escape_codes(fm-message_sent,
msg);
+retstatus = fm-status_sent;
+}
+ret = bb_smscconn_receive(conn, msg);
+}
are you sure you want check ret before bb_smscconn_receive ? ;)
Thanks,
Alex
Am 09.06.2009 um 13:23 schrieb Alejandro Guerrieri:
Ok, done!
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params1.patch
I've fixed the dlr-url bug _only_ on the generic part. If no
objections, I'm doing a second patch to fix it on the kannel smsc
(since it's in fact a separate issue).
I've also fixed a small glitch on the dlrmsg response code (I was
using the error status code for successful submits as well).
Last but not least, I've added url translation to the response
message, so now you can include escape codes on the response, which
may come handy on many cases (for example, to return kannel's
message id on the requests). Userguide part updated accordingly.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:27, Alexander Malysh wrote:
Am 09.06.2009 um 11:23 schrieb Alejandro Guerrieri:
Alex,
Regarding the charsets, I agree it's better to tackle it now that
leave it for later (aka, never ;) ).
I'm fixing the charset issue and the dlr bugs and resending later.
thanks alex!
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:17, Alexander Malysh wrote:
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to
receive UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset should
be taken in account...
I'm not adding anything new here, the MO handling is built on
the original code for kannel_receive_sms (which was the default
interface for MO on the generic interface anyway). There's no
charset handling in there either. I agree it makes sense to
have charset handling, since an http interface should be as
flexible as possible, but is it a showstopper at this point?
It is not really show stopper but if it will not be added now it
will remain so for ages. It is not a problem for
kannel_receive_sms because it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of
code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in DLR
storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid !=
NULL) {
+/* we got a DLR, and we don't require additional
values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR. Could
you please fix both interfaces?
hmm this check is not complete. it should be udh_len +
msgdata_len but msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh) MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long, rejected,
+ octstr_get_cstr(conn-id));
+retmsg = octstr_create(UDH field is too long,
rejected);
+retstatus = fm-status_error;
+}
Idem... this is from kannel_receive_sms as well. If it's wrong
here, then it's wrong on the kannel smsc as well.
Hmm seems, I'm wrong here. This check checks for the right UDH
but allows long MO messages.
why do you always load generic config options ?
static void generic_send_sms(SMSCConn *conn, Msg *sms)
{
@@ -1635,6 +1934,7 @@
cfg_get_bool(conndata-no_sep,
Re: [PATCH] custom MO Parameters for smsc-http
Oh, yes, sorry :D
I'd rather duplicate the msg...
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:38, Alejandro Guerrieri wrote:
Yes, I have to move that afterwards, otherwise the
urltrans_fill_escape_codes call would panic:
2009-06-09 12:46:13 [15580] [6] PANIC: gwlib/octstr.c:2488:
seems_valid_real: Assertion `ostr-len = 0' failed. (Called from
gwlib/octstr.c:1552:octstr_split_words.)
...
2009-06-09 12:46:13 [15580] [6] PANIC: 0
bearerbox 0x0009136d gw_panic + 253
2009-06-09 12:46:13 [15580] [6] PANIC: 1
bearerbox 0x000925de log_thread_to + 750
2009-06-09 12:46:13 [15580] [6] PANIC: 2
bearerbox 0x0009b360 octstr_split_words + 48
2009-06-09 12:46:13 [15580] [6] PANIC: 3
bearerbox 0x000191e2
urltrans_fill_escape_codes + 114
2009-06-09 12:46:13 [15580] [6] PANIC: 4
bearerbox 0x0005d91b smsc_fake_create +
21803
Probably the bb_smscconn_receive call destroys the msg structure?
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:16, Alexander Malysh wrote:
only one last thing:
+msg-sms.account = octstr_duplicate(account);
+msg-sms.binfo = octstr_duplicate(binfo);
+if (ret == -1) {
+retmsg = octstr_create(Not accepted);
+retstatus = fm-status_error;
+} else {
+retmsg = urltrans_fill_escape_codes(fm-message_sent,
msg);
+retstatus = fm-status_sent;
+}
+ret = bb_smscconn_receive(conn, msg);
+}
are you sure you want check ret before bb_smscconn_receive ? ;)
Thanks,
Alex
Am 09.06.2009 um 13:23 schrieb Alejandro Guerrieri:
Ok, done!
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params1.patch
I've fixed the dlr-url bug _only_ on the generic part. If no
objections, I'm doing a second patch to fix it on the kannel smsc
(since it's in fact a separate issue).
I've also fixed a small glitch on the dlrmsg response code (I was
using the error status code for successful submits as well).
Last but not least, I've added url translation to the response
message, so now you can include escape codes on the response,
which may come handy on many cases (for example, to return
kannel's message id on the requests). Userguide part updated
accordingly.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:27, Alexander Malysh wrote:
Am 09.06.2009 um 11:23 schrieb Alejandro Guerrieri:
Alex,
Regarding the charsets, I agree it's better to tackle it now
that leave it for later (aka, never ;) ).
I'm fixing the charset issue and the dlr bugs and resending later.
thanks alex!
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:17, Alexander Malysh wrote:
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to
receive UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset should
be taken in account...
I'm not adding anything new here, the MO handling is built on
the original code for kannel_receive_sms (which was the
default interface for MO on the generic interface anyway).
There's no charset handling in there either. I agree it makes
sense to have charset handling, since an http interface should
be as flexible as possible, but is it a showstopper at this
point?
It is not really show stopper but if it will not be added now
it will remain so for ages. It is not a problem for
kannel_receive_sms because it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of
code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in DLR
storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid !=
NULL) {
+/* we got a DLR, and we don't require additional
values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR.
Could you please fix both interfaces?
hmm this check is not complete. it should be udh_len +
msgdata_len but msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh)
MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long, rejected,
+ octstr_get_cstr(conn-id));
+retmsg = octstr_create(UDH field is too long,
rejected);
+retstatus = fm-status_error;
+}
Idem... this is from kannel_receive_sms as well. If it's wrong
here, then it's wrong on the kannel smsc as well.
Hmm seems, I'm wrong here. This check checks for the right UDH
but allows long MO messages.
Re: [PATCH] custom MO Parameters for smsc-http
ups fixed :D
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params2.patch
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:40, Alejandro Guerrieri wrote:
Oh, yes, sorry :D
I'd rather duplicate the msg...
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:38, Alejandro Guerrieri wrote:
Yes, I have to move that afterwards, otherwise the
urltrans_fill_escape_codes call would panic:
2009-06-09 12:46:13 [15580] [6] PANIC: gwlib/octstr.c:2488:
seems_valid_real: Assertion `ostr-len = 0' failed. (Called from
gwlib/octstr.c:1552:octstr_split_words.)
...
2009-06-09 12:46:13 [15580] [6] PANIC: 0
bearerbox 0x0009136d gw_panic + 253
2009-06-09 12:46:13 [15580] [6] PANIC: 1
bearerbox 0x000925de log_thread_to + 750
2009-06-09 12:46:13 [15580] [6] PANIC: 2
bearerbox 0x0009b360 octstr_split_words +
48
2009-06-09 12:46:13 [15580] [6] PANIC: 3
bearerbox 0x000191e2
urltrans_fill_escape_codes + 114
2009-06-09 12:46:13 [15580] [6] PANIC: 4
bearerbox 0x0005d91b smsc_fake_create +
21803
Probably the bb_smscconn_receive call destroys the msg structure?
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:16, Alexander Malysh wrote:
only one last thing:
+msg-sms.account = octstr_duplicate(account);
+msg-sms.binfo = octstr_duplicate(binfo);
+if (ret == -1) {
+retmsg = octstr_create(Not accepted);
+retstatus = fm-status_error;
+} else {
+retmsg = urltrans_fill_escape_codes(fm-message_sent,
msg);
+retstatus = fm-status_sent;
+}
+ret = bb_smscconn_receive(conn, msg);
+}
are you sure you want check ret before bb_smscconn_receive ? ;)
Thanks,
Alex
Am 09.06.2009 um 13:23 schrieb Alejandro Guerrieri:
Ok, done!
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params1.patch
I've fixed the dlr-url bug _only_ on the generic part. If no
objections, I'm doing a second patch to fix it on the kannel smsc
(since it's in fact a separate issue).
I've also fixed a small glitch on the dlrmsg response code (I was
using the error status code for successful submits as well).
Last but not least, I've added url translation to the response
message, so now you can include escape codes on the response,
which may come handy on many cases (for example, to return
kannel's message id on the requests). Userguide part updated
accordingly.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:27, Alexander Malysh wrote:
Am 09.06.2009 um 11:23 schrieb Alejandro Guerrieri:
Alex,
Regarding the charsets, I agree it's better to tackle it now
that leave it for later (aka, never ;) ).
I'm fixing the charset issue and the dlr bugs and resending
later.
thanks alex!
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:17, Alexander Malysh wrote:
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to
receive UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset should
be taken in account...
I'm not adding anything new here, the MO handling is built on
the original code for kannel_receive_sms (which was the
default interface for MO on the generic interface anyway).
There's no charset handling in there either. I agree it makes
sense to have charset handling, since an http interface
should be as flexible as possible, but is it a showstopper at
this point?
It is not really show stopper but if it will not be added now
it will remain so for ages. It is not a problem for
kannel_receive_sms because it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of
code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in DLR
storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid !=
NULL) {
+/* we got a DLR, and we don't require additional
values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR.
Could you please fix both interfaces?
hmm this check is not complete. it should be udh_len +
msgdata_len but msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh)
MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long, rejected,
+ octstr_get_cstr(conn-id));
+retmsg = octstr_create(UDH field is too long,
rejected);
+retstatus = fm-status_error;
+}
Re: [PATCH] custom MO Parameters for smsc-http
now it's perfect ;)
would you like to commit or should I commit it?
Thanks,
Alex
Am 09.06.2009 um 16:06 schrieb Alejandro Guerrieri:
ups fixed :D
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params2.patch
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:40, Alejandro Guerrieri wrote:
Oh, yes, sorry :D
I'd rather duplicate the msg...
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:38, Alejandro Guerrieri wrote:
Yes, I have to move that afterwards, otherwise the
urltrans_fill_escape_codes call would panic:
2009-06-09 12:46:13 [15580] [6] PANIC: gwlib/octstr.c:2488:
seems_valid_real: Assertion `ostr-len = 0' failed. (Called from
gwlib/octstr.c:1552:octstr_split_words.)
...
2009-06-09 12:46:13 [15580] [6] PANIC: 0
bearerbox 0x0009136d gw_panic + 253
2009-06-09 12:46:13 [15580] [6] PANIC: 1
bearerbox 0x000925de log_thread_to + 750
2009-06-09 12:46:13 [15580] [6] PANIC: 2
bearerbox 0x0009b360 octstr_split_words
+ 48
2009-06-09 12:46:13 [15580] [6] PANIC: 3
bearerbox 0x000191e2
urltrans_fill_escape_codes + 114
2009-06-09 12:46:13 [15580] [6] PANIC: 4
bearerbox 0x0005d91b smsc_fake_create +
21803
Probably the bb_smscconn_receive call destroys the msg structure?
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:16, Alexander Malysh wrote:
only one last thing:
+msg-sms.account = octstr_duplicate(account);
+msg-sms.binfo = octstr_duplicate(binfo);
+if (ret == -1) {
+retmsg = octstr_create(Not accepted);
+retstatus = fm-status_error;
+} else {
+retmsg = urltrans_fill_escape_codes(fm-
message_sent, msg);
+retstatus = fm-status_sent;
+}
+ret = bb_smscconn_receive(conn, msg);
+}
are you sure you want check ret before bb_smscconn_receive ? ;)
Thanks,
Alex
Am 09.06.2009 um 13:23 schrieb Alejandro Guerrieri:
Ok, done!
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params1.patch
I've fixed the dlr-url bug _only_ on the generic part. If no
objections, I'm doing a second patch to fix it on the kannel
smsc (since it's in fact a separate issue).
I've also fixed a small glitch on the dlrmsg response code (I
was using the error status code for successful submits as well).
Last but not least, I've added url translation to the response
message, so now you can include escape codes on the response,
which may come handy on many cases (for example, to return
kannel's message id on the requests). Userguide part updated
accordingly.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:27, Alexander Malysh wrote:
Am 09.06.2009 um 11:23 schrieb Alejandro Guerrieri:
Alex,
Regarding the charsets, I agree it's better to tackle it now
that leave it for later (aka, never ;) ).
I'm fixing the charset issue and the dlr bugs and resending
later.
thanks alex!
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:17, Alexander Malysh wrote:
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to
receive UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset
should be taken in account...
I'm not adding anything new here, the MO handling is built
on the original code for kannel_receive_sms (which was the
default interface for MO on the generic interface anyway).
There's no charset handling in there either. I agree it
makes sense to have charset handling, since an http
interface should be as flexible as possible, but is it a
showstopper at this point?
It is not really show stopper but if it will not be added now
it will remain so for ages. It is not a problem for
kannel_receive_sms because it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of
code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in
DLR storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid !=
NULL) {
+/* we got a DLR, and we don't require additional
values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR.
Could you please fix both interfaces?
hmm this check is not complete. it should be udh_len +
msgdata_len but msgdata_len depends in coding...
+else if (udh != NULL octstr_len(udh)
MAX_SMS_OCTETS) {
+error(0, HTTP[%s]: UDH field is too long,
rejected,
+
Re: [PATCH] custom MO Parameters for smsc-http
I'll do it, no problem.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 16:30, Alexander Malysh wrote:
now it's perfect ;)
would you like to commit or should I commit it?
Thanks,
Alex
Am 09.06.2009 um 16:06 schrieb Alejandro Guerrieri:
ups fixed :D
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params2.patch
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:40, Alejandro Guerrieri wrote:
Oh, yes, sorry :D
I'd rather duplicate the msg...
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:38, Alejandro Guerrieri wrote:
Yes, I have to move that afterwards, otherwise the
urltrans_fill_escape_codes call would panic:
2009-06-09 12:46:13 [15580] [6] PANIC: gwlib/octstr.c:2488:
seems_valid_real: Assertion `ostr-len = 0' failed. (Called from
gwlib/octstr.c:1552:octstr_split_words.)
...
2009-06-09 12:46:13 [15580] [6] PANIC: 0
bearerbox 0x0009136d gw_panic + 253
2009-06-09 12:46:13 [15580] [6] PANIC: 1
bearerbox 0x000925de log_thread_to + 750
2009-06-09 12:46:13 [15580] [6] PANIC: 2
bearerbox 0x0009b360 octstr_split_words
+ 48
2009-06-09 12:46:13 [15580] [6] PANIC: 3
bearerbox 0x000191e2
urltrans_fill_escape_codes + 114
2009-06-09 12:46:13 [15580] [6] PANIC: 4
bearerbox 0x0005d91b smsc_fake_create +
21803
Probably the bb_smscconn_receive call destroys the msg structure?
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:16, Alexander Malysh wrote:
only one last thing:
+msg-sms.account = octstr_duplicate(account);
+msg-sms.binfo = octstr_duplicate(binfo);
+if (ret == -1) {
+retmsg = octstr_create(Not accepted);
+retstatus = fm-status_error;
+} else {
+retmsg = urltrans_fill_escape_codes(fm-
message_sent, msg);
+retstatus = fm-status_sent;
+}
+ret = bb_smscconn_receive(conn, msg);
+}
are you sure you want check ret before bb_smscconn_receive ? ;)
Thanks,
Alex
Am 09.06.2009 um 13:23 schrieb Alejandro Guerrieri:
Ok, done!
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params1.patch
I've fixed the dlr-url bug _only_ on the generic part. If no
objections, I'm doing a second patch to fix it on the kannel
smsc (since it's in fact a separate issue).
I've also fixed a small glitch on the dlrmsg response code (I
was using the error status code for successful submits as
well).
Last but not least, I've added url translation to the response
message, so now you can include escape codes on the response,
which may come handy on many cases (for example, to return
kannel's message id on the requests). Userguide part updated
accordingly.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:27, Alexander Malysh wrote:
Am 09.06.2009 um 11:23 schrieb Alejandro Guerrieri:
Alex,
Regarding the charsets, I agree it's better to tackle it now
that leave it for later (aka, never ;) ).
I'm fixing the charset issue and the dlr bugs and resending
later.
thanks alex!
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:17, Alexander Malysh wrote:
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to
receive UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset
should be taken in account...
I'm not adding anything new here, the MO handling is built
on the original code for kannel_receive_sms (which was the
default interface for MO on the generic interface anyway).
There's no charset handling in there either. I agree it
makes sense to have charset handling, since an http
interface should be as flexible as possible, but is it a
showstopper at this point?
It is not really show stopper but if it will not be added
now it will remain so for ages. It is not a problem for
kannel_receive_sms because it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of
code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in
DLR storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid !=
NULL) {
+/* we got a DLR, and we don't require additional
values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR.
Could you please fix both interfaces?
hmm this check is not complete. it should be udh_len +
msgdata_len but msgdata_len depends in coding...
+else if
RE: [PATCH] custom MO Parameters for smsc-http
Hi Alejandro , I work with Hervé who posted to this list the 25th of May (Claro http communication). It seems the patch you've done on the generic part could be very useful for us to manage our communications with Claro. It could be better than a specific implementation for Claro. However, I don't understand how your patch manages a DLR: In generic_receive_sms(), you call dlr_find() (line 1674 of the patched source) to retrieve a previous record stored in the DLR storage. It seems fine except that dlr_add() is never called in generic_parse_reply(), so I guess dlr_find() will always return NULL. Am I wrong??? In fact, when we submit a MT SMS to Claro with this request http://retail.mds.claro.com.br/MSE/api?profile=pwd=mode=assync-deliveryANUM=BNUM=1234567TEXT=test we get a HTTP code 200 with this body: ?xml version=1.0 encoding=UTF-8 ? mse-response status-code0/status-code profileprofleID/profile transaction-id1020606201622668099/transaction-id /mse-response So I guess that the transaction-id should be used in generic_parse_reply() to call dlr_add(). Unfortunately, the current implementation does not allow to manage such an id, it only allows to search if the request was successful or not through the regex. If all my hypothesis are right... :-) I could try to patch generic_parse_reply() to manage also the id through another regex. It will be my first Kannel patch! ;-) If you prefer to do it, no problem, just let me know. If I'm wrong, please clarify how it works. Regards, Franck
Re: [PATCH] custom MO Parameters for smsc-http
Franck, The dlr part is inherited from the kannel smsc format. In the actual implementation there's no way to grab the remote message id from a request, and it'd make a lot of sense to be able to do it. I can try adding it, but don't refrain to do it so yourself if you feel the urge (you'll learn a lot about the code in the process!). Opinions? -- Alejandro Guerrieri aguerri...@kannel.org On 09/06/2009, at 17:47, Franck LAMASUTA wrote: Hi Alejandro , I work with Hervé who posted to this list the 25th of May (Claro http communication). It seems the patch you've done on the generic part could be very useful for us to manage our communications with Claro. It could be better than a specific implementation for Claro. However, I don't understand how your patch manages a DLR: In generic_receive_sms(), you call dlr_find() (line 1674 of the patched source) to retrieve a previous record stored in the DLR storage. It seems fine except that dlr_add() is never called in generic_parse_reply(), so I guess dlr_find() will always return NULL. Am I wrong??? In fact, when we submit a MT SMS to Claro with this request http://retail.mds.claro.com.br/MSE/api?profile=pwd=mode=assync-deliveryANUM=BNUM=1234567TEXT=test we get a HTTP code 200 with this body: ?xml version=1.0 encoding=UTF-8 ? mse-response status-code0/status-code profileprofleID/profile transaction-id1020606201622668099/transaction-id /mse-response So I guess that the transaction-id should be used in generic_parse_reply() to call dlr_add(). Unfortunately, the current implementation does not allow to manage such an id, it only allows to search if the request was successful or not through the regex. If all my hypothesis are right... :-) I could try to patch generic_parse_reply() to manage also the id through another regex. It will be my first Kannel patch! ;-) If you prefer to do it, no problem, just let me know. If I'm wrong, please clarify how it works. Regards, Franck
Re: [PATCH] custom MO Parameters for smsc-http
Am 09.06.2009 um 17:55 schrieb Alejandro Guerrieri: Franck, The dlr part is inherited from the kannel smsc format. In the actual implementation there's no way to grab the remote message id from a request, and it'd make a lot of sense to be able to do it. I can try adding it, but don't refrain to do it so yourself if you feel the urge (you'll learn a lot about the code in the process!). yep, Alex is right here :) and we need more contributors :) Opinions? -- Alejandro Guerrieri aguerri...@kannel.org On 09/06/2009, at 17:47, Franck LAMASUTA wrote: Hi Alejandro , I work with Hervé who posted to this list the 25th of May (Claro http communication). It seems the patch you've done on the generic part could be very useful for us to manage our communications with Claro. It could be better than a specific implementation for Claro. However, I don't understand how your patch manages a DLR: In generic_receive_sms(), you call dlr_find() (line 1674 of the patched source) to retrieve a previous record stored in the DLR storage. It seems fine except that dlr_add() is never called in generic_parse_reply(), so I guess dlr_find() will always return NULL. Am I wrong??? In fact, when we submit a MT SMS to Claro with this request http://retail.mds.claro.com.br/MSE/api?profile=pwd=mode=assync-deliveryANUM=BNUM=1234567TEXT=test we get a HTTP code 200 with this body: ?xml version=1.0 encoding=UTF-8 ? mse-response status-code0/status-code profileprofleID/profile transaction-id1020606201622668099/transaction-id /mse-response So I guess that the transaction-id should be used in generic_parse_reply() to call dlr_add(). Unfortunately, the current implementation does not allow to manage such an id, it only allows to search if the request was successful or not through the regex. If all my hypothesis are right... :-) I could try to patch generic_parse_reply() to manage also the id through another regex. It will be my first Kannel patch! ;-) If you prefer to do it, no problem, just let me know. If I'm wrong, please clarify how it works. Regards, Franck
Re: [PATCH] custom MO Parameters for smsc-http
Commited to CVS.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 16:30, Alexander Malysh wrote:
now it's perfect ;)
would you like to commit or should I commit it?
Thanks,
Alex
Am 09.06.2009 um 16:06 schrieb Alejandro Guerrieri:
ups fixed :D
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params2.patch
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:40, Alejandro Guerrieri wrote:
Oh, yes, sorry :D
I'd rather duplicate the msg...
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:38, Alejandro Guerrieri wrote:
Yes, I have to move that afterwards, otherwise the
urltrans_fill_escape_codes call would panic:
2009-06-09 12:46:13 [15580] [6] PANIC: gwlib/octstr.c:2488:
seems_valid_real: Assertion `ostr-len = 0' failed. (Called from
gwlib/octstr.c:1552:octstr_split_words.)
...
2009-06-09 12:46:13 [15580] [6] PANIC: 0
bearerbox 0x0009136d gw_panic + 253
2009-06-09 12:46:13 [15580] [6] PANIC: 1
bearerbox 0x000925de log_thread_to + 750
2009-06-09 12:46:13 [15580] [6] PANIC: 2
bearerbox 0x0009b360 octstr_split_words
+ 48
2009-06-09 12:46:13 [15580] [6] PANIC: 3
bearerbox 0x000191e2
urltrans_fill_escape_codes + 114
2009-06-09 12:46:13 [15580] [6] PANIC: 4
bearerbox 0x0005d91b smsc_fake_create +
21803
Probably the bb_smscconn_receive call destroys the msg structure?
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 15:16, Alexander Malysh wrote:
only one last thing:
+msg-sms.account = octstr_duplicate(account);
+msg-sms.binfo = octstr_duplicate(binfo);
+if (ret == -1) {
+retmsg = octstr_create(Not accepted);
+retstatus = fm-status_error;
+} else {
+retmsg = urltrans_fill_escape_codes(fm-
message_sent, msg);
+retstatus = fm-status_sent;
+}
+ret = bb_smscconn_receive(conn, msg);
+}
are you sure you want check ret before bb_smscconn_receive ? ;)
Thanks,
Alex
Am 09.06.2009 um 13:23 schrieb Alejandro Guerrieri:
Ok, done!
http://www.blogalex.com/wp-content/uploads/2009/06/kannel-http-mo-params1.patch
I've fixed the dlr-url bug _only_ on the generic part. If no
objections, I'm doing a second patch to fix it on the kannel
smsc (since it's in fact a separate issue).
I've also fixed a small glitch on the dlrmsg response code (I
was using the error status code for successful submits as
well).
Last but not least, I've added url translation to the response
message, so now you can include escape codes on the response,
which may come handy on many cases (for example, to return
kannel's message id on the requests). Userguide part updated
accordingly.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:27, Alexander Malysh wrote:
Am 09.06.2009 um 11:23 schrieb Alejandro Guerrieri:
Alex,
Regarding the charsets, I agree it's better to tackle it now
that leave it for later (aka, never ;) ).
I'm fixing the charset issue and the dlr bugs and resending
later.
thanks alex!
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 11:17, Alexander Malysh wrote:
Am 09.06.2009 um 11:05 schrieb Alejandro Guerrieri:
Alex,
Commenting inline below.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 10:44, Alexander Malysh wrote:
Hi,
Seems you don't handle charset at all. Do you assume to
receive UTF-8 in any case? I don't think it's
applicable to generic interface. At least alt-charset
should be taken in account...
I'm not adding anything new here, the MO handling is built
on the original code for kannel_receive_sms (which was the
default interface for MO on the generic interface anyway).
There's no charset handling in there either. I agree it
makes sense to have charset handling, since an http
interface should be as flexible as possible, but is it a
showstopper at this point?
It is not really show stopper but if it will not be added
now it will remain so for ages. It is not a problem for
kannel_receive_sms because it's
well defined interface to smsbox which uses UTF-8.
I would prefer to see it implemented (there only few line of
code ;) )
some comments to patch below...
why is dlrurl required for DLR? We have dlrurl stored in
DLR storage...
+}
+else if (dlrurl != NULL dlrmask != 0 dlrmid !=
NULL) {
+/* we got a DLR, and we don't require additional
values */
+Msg *dlrmsg;
Idem... why is it needed for the kannel interface then?
hmm, seems both buggy then. We don't need dlr-url for DLR.
Could you please fix both interfaces?
hmm this check is not complete. it should be udh_len +
msgdata_len but msgdata_len depends in coding...
+else if (udh !=
Re: Kannel not load balancing after restart and messages get stuck inqueue
Dear Alvaro, I just managed to finish with my responsibilities, not on April 10, as I was hoping. Meanwhile, I haven't heard from you in a while, and I hope you are enjoying your vacations. Here is a patch to gw/bearerbox.c and gw/bb_smscconn.c, that doesn't start the sms_router, until all smscs (except the FAKE) are ACTIVE. If I am not mistaken, bearerbox will not start unless all smscs are available. So this is inline with this philosophy. I have tested it to the extend that it doesn't break anything, please let me know if it solves your problem. BR, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Sent: Tuesday, March 31, 2009 4:56 PM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos No problem. I undestand we are on a best effort support XD and this is not a critical issue. Thanks Alvaro |-| EnvΓe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el PerΓΊ, MΓ©xico y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com 2009/3/31 Nikos Balkanas nbalka...@gmail.com: Hi Alvaro, Thanx for reminding me. Unfortunately I am still working very hard on my project. I will be finished by the 10th of April. Sorry about that and I hope I am not causing you trouble. I put a reminder on my PC not to forget. BR, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com; kannel users us...@kannel.org Sent: Tuesday, March 31, 2009 10:17 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos Had you chance to review this? Regards Alvaro |-| EnvΞ“Βe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el PerΞ“Ξ�, MΓ©xico y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Β Β Β Β Β Β Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com 2009/3/10 Nikos Balkanas nbalka...@gmail.com: Hi, I am working on something very important right now. Could you give me a ping in 2 weeks or so, if no one has addressed it? Thanx, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: seikath seik...@gmail.com; kannel users us...@kannel.org Sent: Wednesday, March 11, 2009 5:29 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos for 1... still looking at data/logs... nothing so far. for 2... You are right: SMSC connections: id1 Ξ’ Ξ’ AT2[id1] (online 323s, rcvd 48, sent 48, failed 0, queued 265 msgs) id2 Ξ’ Ξ’ AT2[id2] (online 314s, rcvd 0, sent 0, failed 0, queued 0 msgs) id3 Ξ’ Ξ’ AT2[id3] (online 314s, rcvd 0, sent 0, failed 0, queued 0 msgs) id4 Ξ’ Ξ’ AT2[id4] (online 314s, rcvd 0, sent 0, failed 0, queued 0 msgs) id5 Ξ’ Ξ’ AT2[id5] (online 314s, rcvd 0, sent 0, failed 0, queued 0 msgs) All messages in queue for smsc-id id_op1 were asigned to the 1st available smsc that has allowed-smsc=id_op1 I'm not developer but think this behavior shall be modified so kannel will be able to maximize/optimize its resources available. Some sort of recalculation of Ξ’ the better route for messages each x time Regards Alvaro |-| EnvΞ�β€�Ξ’Βe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el PerΞ�β€�Ξ� , MΞ�β€�Ξ’Β©xico y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Ξ’ Ξ’ Ξ’ Ξ’ Ξ’ Ξ’ Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com On Tue, Mar 10, 2009 at 8:57 PM, Nikos Balkanas nbalka...@gmail.com wrote: Hi, These are some heavy questions dude. (1) SMS shoudn't get stuck like that so that they require restart. Anything in the logs? (2) I could speculate why this happens, but without looking at the source code it would be guesswork. My guess would be that it involves the timing needed at startup to designate SMScs as active. Probably this is done by way of configuration order (i.e. id1, id2, etc.). The first active one gets the queue. Bearerbox router checks in every 30. BR, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: seikath seik...@gmail.com Cc: kannel users us...@kannel.org Sent: Wednesday, March 11, 2009 3:41 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue No, I'm using mysql for dlr storage since otherwise dlr are lost on kannel restart
[PATCH] utils/mtabatch.c
Hi, This is a simple patch to mtbatch, that if left as is should core dump. BR, Nikos mtbatch.diff Description: Binary data
[PATCH] [SQLBOX] Allow building with sqlite3 3.5
Hi, first message to the list, first patch :)
It's a simple one, it turns out sqlite3 has sqlite3_prepare_v2 in
versions = 3.5 (if google didn't lie to me) so, this patch only use it if
available.
It's against the lastest stable.
Hope to help.
Damián Viano(Des).
--- sqlbox-0.7.2/gw/sqlbox_sqlite3.c 2009-05-19 12:08:35.0 -0300
+++ sqlbox-0.7.2_des/gw/sqlbox_sqlite3.c 2009-06-09 11:14:09.0 -0300
@@ -53,7 +53,11 @@
debug(SQLBOX, 0, sql: %s, octstr_get_cstr(sql));
#endif
+#ifdef sqlite3_prepare_v2
res = sqlite3_prepare_v2(conn-conn, octstr_get_cstr(sql), -1, stmt, NULL);
+#else
+res = sqlite3_prepare(conn-conn, octstr_get_cstr(sql), -1, stmt, NULL);
+#endif
if (res != SQLITE_OK) {
error(0, SQLITE3: Could not compile query: %s, sqlite3_errmsg(conn-conn));
return NULL;
[PATCH] [SQLBOX] Implement batch processing
Hi:
Another one for sqlbox. This is based on
http://www.magicom-bcn.net/kannel/sqlbox-standalone-multi-20080227.patch by
Alejandro Guerrieri, but avoiding the situation where if we die in the middle
of a batch we lose messages. In this implementation worst case scenario we
repeat a message.
I've only implemented the batch processing for msyql, since that's what I use,
but everything is in place to implement the same for the rest of the db
backends.
Also I think it would be ok to cleanup the single-message processing from
gw/sqlbox.c once every backend implement the batch processing (which is a lot
more performant and tunable, I could come up with some numbers if needed).
There is a small comment to make about the List *msgids parameter, please note
that this parameter is completely backend controlled to allow backends using
multiple keys or things even weirder, gw/sqlbox.c only cares about calling
gw_sql_batch_msg_done with the corresponding component from the list (which is
assumed is in the exact same order of the List *msgs parameter).
It's no biggie (note that around 50% of mysql_fetch_batch() in sqlbox_mysql.c
is the same msg processing of mysql_fetch_msg() [1]) but helps performance a
great
deal.
diffstat sqlbox-0.7.2-batch_processing.patch
sqlbox-cfg.def |1
sqlbox.c | 30 -
sqlbox_mssql.c |2 +
sqlbox_mysql.c | 76
+++
sqlbox_mysql.h |5 +++
sqlbox_oracle.c |2 +
sqlbox_pgsql.c |2 +
sqlbox_sdb.c |2 +
sqlbox_sql.h |4 ++
sqlbox_sqlite.c |2 +
sqlbox_sqlite3.c |2 +
11 files changed, 127 insertions(+), 1 deletion(-)
Comments, corrections, commits ;) welcome
Again, this diff is against current stable, let me know if it needs updating.
Damián Viano(Des).
[1] Yeah, I know that phrase calls for a function but that wouldn't make sense
if we drop the single message processing code
diff -Nura -x '.*' sqlbox-0.7.2/gw/sqlbox.c sqlbox-0.7.2_des/gw/sqlbox.c
--- sqlbox-0.7.2/gw/sqlbox.c 2009-05-19 12:08:35.0 -0300
+++ sqlbox-0.7.2_des/gw/sqlbox.c 2009-06-08 17:47:49.0 -0300
@@ -86,6 +86,7 @@
static Octstr *box_allow_ip;
static Octstr *box_deny_ip;
static Octstr *global_sender;
+static long limit_per_cycle;
#ifndef HAVE_MSSQL
#ifndef HAVE_MYSQL
@@ -105,6 +106,7 @@
Octstr *sqlbox_id;
#define SLEEP_BETWEEN_SELECTS 1.0
+#define DEFAULT_LIMIT_PER_CYCLE 10
typedef struct _boxc {
Connection*smsbox_connection;
@@ -528,6 +530,7 @@
Boxc *boxc;
int fd;
Msg *msg;
+List *msgs, *msgids;
boxc = gw_malloc(sizeof(Boxc));
boxc-bearerbox_connection = connect_to_bearerbox_real(bearerbox_host, bearerbox_port, bearerbox_port_ssl, NULL /* bb_our_host */);
@@ -545,8 +548,28 @@
identify_to_bearerbox(boxc);
+if (gw_sql_fetch_batch != NULL) {
+ msgs = gwlist_create();
+ msgids = gwlist_create();
+}
+
while (sqlbox_status == SQL_RUNNING) {
-if ((msg = gw_sql_fetch_msg()) != NULL) {
+if (gw_sql_fetch_batch != NULL) {
+debug(sqlbox, 0, sql_to_bearerbox: using batch processing, limit: %ld, limit_per_cycle);
+if (gw_sql_fetch_batch(msgs, msgids, limit_per_cycle) == 0)
+gwthread_sleep(SLEEP_BETWEEN_SELECTS);
+while ((msg = gwlist_consume(msgs)) != NULL ) {
+if (global_sender != NULL (msg-sms.sender == NULL || octstr_len(msg-sms.sender) == 0)) {
+msg-sms.sender = octstr_duplicate(global_sender);
+}
+send_msg(boxc-bearerbox_connection, boxc, msg);
+gw_sql_save_msg(msg, octstr_imm(MT));
+gw_sql_batch_msg_done(gwlist_consume(msgids));
+}
+gw_assert(gwlist_len(msgids) == 0);
+}
+else if (gw_sql_fetch_batch == NULL (msg = gw_sql_fetch_msg()) != NULL) {
+debug(sqlbox, 0, sql_to_bearerbox: using single message processing, limit: %ld, limit_per_cycle);
if (global_sender != NULL (msg-sms.sender == NULL || octstr_len(msg-sms.sender) == 0)) {
msg-sms.sender = octstr_duplicate(global_sender);
}
@@ -685,6 +708,11 @@
if (cfg_get_integer(sqlbox_port, grp, octstr_imm(smsbox-port)) == -1)
sqlbox_port = 13005;
+
+/* setup limit per cycle */
+if (cfg_get_integer(limit_per_cycle, grp, octstr_imm(limit-per-cycle)) == -1)
+limit_per_cycle = DEFAULT_LIMIT_PER_CYCLE;
+
/* setup logfile stuff */
logfile = cfg_get(grp, octstr_imm(log-file));
diff -Nura -x '.*' sqlbox-0.7.2/gw/sqlbox-cfg.def sqlbox-0.7.2_des/gw/sqlbox-cfg.def
--- sqlbox-0.7.2/gw/sqlbox-cfg.def 2008-11-03 17:33:15.0 -0200
+++ sqlbox-0.7.2_des/gw/sqlbox-cfg.def 2009-06-08 15:09:07.0 -0300
@@ -21,4 +21,5 @@
OCTSTR(ssl-server-cert-file)
OCTSTR(ssl-server-key-file)
OCTSTR(ssl-trusted-ca-file)
+
[PATCH] Guaranteed throughput smsc-independent
Hi list:
I've seen kannel not respect throughput at all, at least with the
fakesmsc
and looking around find the following bug:
http://redmine.kannel.org/issues/show/332
With the following patch attached:
http://redmine.kannel.org/attachments/104/332-emi_patch_ack_v3.txt
Inspired by that one, I've implemented a smsc-independent throughput patch. The
idea is to enforce the throughput from the beaberbox side instead of having to
implement the same login in every smsc. This is possible due to the
bb_smscconn_sent() and bb_smscconn_send_failed() callbacks from the smscs
implementation. They MUST call one of this callbacks after sending a message
either successfully(_sent) or with failure(_failed), so we can make them sleep
there, making sure they NEVER go over the configured throughput.
There's only one downside to this smsc-independent approach which is that we
don't, and can't (without cluttering the interface, AFAIK) know how much time
the smsc takes in actually sending the sms, so we assume it takes nothing, this
would, practically give us a somewhat smaller real throughput, but I though
that's better than the previous behaviour (which for me, flooded the smsc).
I've only tested this with fakesmsc so far, and only commented out the previous
throughput implementation in that smsc, doing the rest is trivial and I can do
it (or anyone else can), but this first iteration is to gather opinions about
this approach.
Once again the patch is against the current stable release, I can update it if
needed, just let me know.
Again I would love comments, questions, commits, rants, whatever :)
For reference:
diffstat kannel-1.4.3-throughput.patch
bb_smscconn.c| 46 ++
smsc/smsc_fake.c |9 +++--
smscconn_p.h |2 ++
3 files changed, 55 insertions(+), 2 deletions(-)
Hope to help.
Damián Viano(Des).
P.D.: Also there's an info line in smsc_fake.c to count the number of sms,
which should be removed from the final version, is only there for debugging
purposes.
diff -Nura gateway-1.4.3.orig/gw/bb_smscconn.c gateway-1.4.3-des/gw/bb_smscconn.c
--- gateway-1.4.3.orig/gw/bb_smscconn.c 2009-06-03 14:58:43.0 -0300
+++ gateway-1.4.3-des/gw/bb_smscconn.c 2009-06-04 16:47:00.0 -0300
@@ -250,6 +250,13 @@
void bb_smscconn_sent(SMSCConn *conn, Msg *sms, Octstr *reply)
{
+struct timeval qos_slept;
+double delay;
+
+/* update last sent time independently of the reply to ensure QOS*/
+/* FIXME: split msg should be acoounted for the number of splited msgs?*/
+gettimeofday(conn-last_mt_microtime, 0);
+
if (sms-sms.split_parts != NULL) {
handle_split(conn, sms, SMSCCONN_SUCCESS);
octstr_destroy(reply);
@@ -282,11 +289,34 @@
msg_destroy(sms);
octstr_destroy(reply);
+
+if (conn-throughput 0) { /* enforce QOS */
+delay = 1.0 / conn-throughput;
+debug(bb.smscconn, 0, BB[%s]: QOS: Throughput detected, we need to sleep %fsec, octstr_get_cstr(conn-id?conn-id:conn-name), delay);
+
+do { /* guaranteed sleep to ensure QOS even if we are awaken in during the sleep*/
+gwthread_sleep(delay);
+gettimeofday(qos_slept, 0);
+} /* store in delay the amount of time we still need to sleep and if this is 0 continue sleeping*/
+ while (0 (delay = conn-last_mt_microtime.tv_sec
+ + (double) conn-last_mt_microtime.tv_usec / 100 /* start of function */
+ + 1.0 / conn-throughput /* + total delay needed */
+ - (qos_slept.tv_sec + (double) qos_slept.tv_usec / 100))); /* - actual time */
+
+debug(bb.smscconn, 0, BB[%s]: QOS: Sleep done, octstr_get_cstr(conn-id?conn-id:conn-name));
+}
}
void bb_smscconn_send_failed(SMSCConn *conn, Msg *sms, int reason, Octstr *reply)
{
+struct timeval qos_slept;
+double delay;
+
+/* update last sent time independently of the reply to ensure QOS*/
+/* FIXME: split msg should be acoounted for the number of splited msgs?*/
+gettimeofday(conn-last_mt_microtime, 0);
+
if (sms-sms.split_parts != NULL) {
handle_split(conn, sms, reason);
octstr_destroy(reply);
@@ -352,6 +382,22 @@
}
octstr_destroy(reply);
+
+if (conn-throughput 0) { /* enforce QOS */
+delay = 1.0 / conn-throughput;
+debug(bb.smscconn, 0, BB[%s]: QOS: Throughput detected, we need to sleep %fsec, octstr_get_cstr(conn-id?conn-id:conn-name), delay);
+
+do { /* guaranteed sleep to ensure QOS even if we are awaken in during the sleep*/
+gwthread_sleep(delay);
+gettimeofday(qos_slept, 0);
+} /* store in delay the amount of time we still need to sleep and if this is 0 continue sleeping*/
+ while (0 (delay = conn-last_mt_microtime.tv_sec
Re: [PATCH] Guaranteed throughput smsc-independent
I will review in more detail when I get a moment, my concern here is that you are now sleeping at the bearerbox layer which could effect delivery to other SMSC's. The current throughput limits although the logic is per-smsc, they sleep within their own threads as to not delay any others. Have you addressed this scenario? 2009/6/9 Damián Viano damian.vi...@buongiorno.com Hi list: I've seen kannel not respect throughput at all, at least with the fakesmsc and looking around find the following bug: http://redmine.kannel.org/issues/show/332 With the following patch attached: http://redmine.kannel.org/attachments/104/332-emi_patch_ack_v3.txt Inspired by that one, I've implemented a smsc-independent throughput patch. The idea is to enforce the throughput from the beaberbox side instead of having to implement the same login in every smsc. This is possible due to the bb_smscconn_sent() and bb_smscconn_send_failed() callbacks from the smscs implementation. They MUST call one of this callbacks after sending a message either successfully(_sent) or with failure(_failed), so we can make them sleep there, making sure they NEVER go over the configured throughput. There's only one downside to this smsc-independent approach which is that we don't, and can't (without cluttering the interface, AFAIK) know how much time the smsc takes in actually sending the sms, so we assume it takes nothing, this would, practically give us a somewhat smaller real throughput, but I though that's better than the previous behaviour (which for me, flooded the smsc). I've only tested this with fakesmsc so far, and only commented out the previous throughput implementation in that smsc, doing the rest is trivial and I can do it (or anyone else can), but this first iteration is to gather opinions about this approach. Once again the patch is against the current stable release, I can update it if needed, just let me know. Again I would love comments, questions, commits, rants, whatever :) For reference: diffstat kannel-1.4.3-throughput.patch bb_smscconn.c| 46 ++ smsc/smsc_fake.c |9 +++-- smscconn_p.h |2 ++ 3 files changed, 55 insertions(+), 2 deletions(-) Hope to help. Damián Viano(Des). P.D.: Also there's an info line in smsc_fake.c to count the number of sms, which should be removed from the final version, is only there for debugging purposes. -- Donald Jackson http://www.ddj.co.za/ donaldjster(a)gmail.com
Re: [PATCH] Guaranteed throughput smsc-independent
Ignore my last mail! I see these will be called per thread :) 2009/6/9 Donald Jackson donaldjs...@gmail.com I will review in more detail when I get a moment, my concern here is that you are now sleeping at the bearerbox layer which could effect delivery to other SMSC's. The current throughput limits although the logic is per-smsc, they sleep within their own threads as to not delay any others. Have you addressed this scenario? 2009/6/9 Damián Viano damian.vi...@buongiorno.com Hi list: I've seen kannel not respect throughput at all, at least with the fakesmsc and looking around find the following bug: http://redmine.kannel.org/issues/show/332 With the following patch attached: http://redmine.kannel.org/attachments/104/332-emi_patch_ack_v3.txt Inspired by that one, I've implemented a smsc-independent throughput patch. The idea is to enforce the throughput from the beaberbox side instead of having to implement the same login in every smsc. This is possible due to the bb_smscconn_sent() and bb_smscconn_send_failed() callbacks from the smscs implementation. They MUST call one of this callbacks after sending a message either successfully(_sent) or with failure(_failed), so we can make them sleep there, making sure they NEVER go over the configured throughput. There's only one downside to this smsc-independent approach which is that we don't, and can't (without cluttering the interface, AFAIK) know how much time the smsc takes in actually sending the sms, so we assume it takes nothing, this would, practically give us a somewhat smaller real throughput, but I though that's better than the previous behaviour (which for me, flooded the smsc). I've only tested this with fakesmsc so far, and only commented out the previous throughput implementation in that smsc, doing the rest is trivial and I can do it (or anyone else can), but this first iteration is to gather opinions about this approach. Once again the patch is against the current stable release, I can update it if needed, just let me know. Again I would love comments, questions, commits, rants, whatever :) For reference: diffstat kannel-1.4.3-throughput.patch bb_smscconn.c| 46 ++ smsc/smsc_fake.c |9 +++-- smscconn_p.h |2 ++ 3 files changed, 55 insertions(+), 2 deletions(-) Hope to help. Damián Viano(Des). P.D.: Also there's an info line in smsc_fake.c to count the number of sms, which should be removed from the final version, is only there for debugging purposes. -- Donald Jackson http://www.ddj.co.za/ donaldjster(a)gmail.com -- Donald Jackson http://www.ddj.co.za/ donaldjster(a)gmail.com
Re: Kannel not load balancing after restart and messages get stuck inqueue
Hi Nikos, Sorry I haven't reviewed this whole thread in detail but was caught by .. bearerbox will not start unless all smscs are available. .. this worried me a bit. I'm concerned that in a DR scenario if 1 connection is down (and not coming up just yet) then I would like to be able to (re)start no problem (the other connections would start with this one remaining down .. trying to bind, etc). Is there not an alternative option in terms of (from init.d/startup perspective) start isolated, allowing some time (seconds) for the available connections to bind then setting the connections to active. Or have I missed the point here. Apologies if I'm muddying the water. I will try and follow more closely. Cheers, Alan Nikos Balkanas wrote: Dear Alvaro, I just managed to finish with my responsibilities, not on April 10, as I was hoping. Meanwhile, I haven't heard from you in a while, and I hope you are enjoying your vacations. Here is a patch to gw/bearerbox.c and gw/bb_smscconn.c, that doesn't start the sms_router, until all smscs (except the FAKE) are ACTIVE. If I am not mistaken, bearerbox will not start unless all smscs are available. So this is inline with this philosophy. I have tested it to the extend that it doesn't break anything, please let me know if it solves your problem. BR, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Sent: Tuesday, March 31, 2009 4:56 PM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos No problem. I undestand we are on a best effort support XD and this is not a critical issue. Thanks Alvaro |-| EnvΓe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el PerΓΊ, MΓ©xico y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com 2009/3/31 Nikos Balkanas nbalka...@gmail.com: Hi Alvaro, Thanx for reminding me. Unfortunately I am still working very hard on my project. I will be finished by the 10th of April. Sorry about that and I hope I am not causing you trouble. I put a reminder on my PC not to forget. BR, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com; kannel users us...@kannel.org Sent: Tuesday, March 31, 2009 10:17 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos Had you chance to review this? Regards Alvaro |-| EnvΞ“Βe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el PerΞ“Ξ�, MΓ©xico y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Β Β Β Β Β Β Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com 2009/3/10 Nikos Balkanas nbalka...@gmail.com: Hi, I am working on something very important right now. Could you give me a ping in 2 weeks or so, if no one has addressed it? Thanx, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: seikath seik...@gmail.com; kannel users us...@kannel.org Sent: Wednesday, March 11, 2009 5:29 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos for 1... still looking at data/logs... nothing so far. for 2... You are right: SMSC connections: id1 Ξ’ Ξ’ AT2[id1] (online 323s, rcvd 48, sent 48, failed 0, queued 265 msgs) id2 Ξ’ Ξ’ AT2[id2] (online 314s, rcvd 0, sent 0, failed 0, queued 0 msgs) id3 Ξ’ Ξ’ AT2[id3] (online 314s, rcvd 0, sent 0, failed 0, queued 0 msgs) id4 Ξ’ Ξ’ AT2[id4] (online 314s, rcvd 0, sent 0, failed 0, queued 0 msgs) id5 Ξ’ Ξ’ AT2[id5] (online 314s, rcvd 0, sent 0, failed 0, queued 0 msgs) All messages in queue for smsc-id id_op1 were asigned to the 1st available smsc that has allowed-smsc=id_op1 I'm not developer but think this behavior shall be modified so kannel will be able to maximize/optimize its resources available. Some sort of recalculation of Ξ’ the better route for messages each x time Regards Alvaro |-| EnvΞ�β€�Ξ’Βe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el PerΞ�β€�Ξ� , MΞ�β€�Ξ’Β©xico y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Ξ’ Ξ’ Ξ’ Ξ’ Ξ’ Ξ’ Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com On Tue, Mar 10, 2009 at 8:57 PM, Nikos Balkanas nbalka...@gmail.com wrote: Hi, These are some
Re: Kannel not load balancing after restart and messages get stuck inqueue
Hi Alan, If even 1 SMSc in configuration file fails to start, bearerbox will panic. There are several states to any SMSc, like connecting, going down, etc. Bearerbox expects all SMScs to be available on startup. The operative word is available. If a configured modem is not connected, that's a failure and you would have to take it off configuration to startup. After it starts, SMScs can go up or down. Isolated mode still needs SMScs for outgoing messages. The only mode that doesn't is Suspended. But i don't think that even this will startup without all SMScs available. Available is different than Active. Available means anything but Failed (Dead,etc.). An available SMSc could be down, or coming up or connecting. In this patch, router will wait to start until all SMScs become active. What is DR? BR, Nikos - Original Message - From: Alan McNatty a...@catalyst.net.nz To: Nikos Balkanas nbalka...@gmail.com Cc: Alvaro Cornejo cornejo.alv...@gmail.com; devel@kannel.org Sent: Wednesday, June 10, 2009 1:22 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos, Sorry I haven't reviewed this whole thread in detail but was caught by .. bearerbox will not start unless all smscs are available. .. this worried me a bit. I'm concerned that in a DR scenario if 1 connection is down (and not coming up just yet) then I would like to be able to (re)start no problem (the other connections would start with this one remaining down .. trying to bind, etc). Is there not an alternative option in terms of (from init.d/startup perspective) start isolated, allowing some time (seconds) for the available connections to bind then setting the connections to active. Or have I missed the point here. Apologies if I'm muddying the water. I will try and follow more closely. Cheers, Alan Nikos Balkanas wrote: Dear Alvaro, I just managed to finish with my responsibilities, not on April 10, as I was hoping. Meanwhile, I haven't heard from you in a while, and I hope you are enjoying your vacations. Here is a patch to gw/bearerbox.c and gw/bb_smscconn.c, that doesn't start the sms_router, until all smscs (except the FAKE) are ACTIVE. If I am not mistaken, bearerbox will not start unless all smscs are available. So this is inline with this philosophy. I have tested it to the extend that it doesn't break anything, please let me know if it solves your problem. BR, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Sent: Tuesday, March 31, 2009 4:56 PM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos No problem. I undestand we are on a best effort support XD and this is not a critical issue. Thanks Alvaro |-| EnvΞ“Βe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el PerΞ“Ξ�, MΓ©xico y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com 2009/3/31 Nikos Balkanas nbalka...@gmail.com: Hi Alvaro, Thanx for reminding me. Unfortunately I am still working very hard on my project. I will be finished by the 10th of April. Sorry about that and I hope I am not causing you trouble. I put a reminder on my PC not to forget. BR, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com; kannel users us...@kannel.org Sent: Tuesday, March 31, 2009 10:17 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos Had you chance to review this? Regards Alvaro |-| EnvΞ�β€�Ξ’Βe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el PerΞ�β€�Ξ�οΏ½, MΞ�β€�Ξ’Β©xico y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Ξ’ Ξ’ Ξ’ Ξ’ Ξ’ Ξ’ Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com 2009/3/10 Nikos Balkanas nbalka...@gmail.com: Hi, I am working on something very important right now. Could you give me a ping in 2 weeks or so, if no one has addressed it? Thanx, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Cc: seikath seik...@gmail.com; kannel users us...@kannel.org Sent: Wednesday, March 11, 2009 5:29 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos for 1... still looking at data/logs... nothing so far. for 2... You are right: SMSC connections: id1 Ξ�’ Ξ�’ AT2[id1] (online 323s, rcvd 48, sent 48, failed 0, queued 265 msgs) id2 Ξ�’ Ξ�’ AT2[id2] (online 314s, rcvd 0, sent 0, failed 0, queued 0
Re: Kannel not load balancing after restart and messages get stuck inqueue
Hi Nikos, OK, yeah I'm not about failure at start-up time. If an SMSC is off-line (SMPP timeout/retry during bind) kannel will start (simply config a bogus IP address for SMPP to test this out). An example is lets say we have 2 connections for load balancing. Now consider 1 smsc being taken offline (no tcp connection) as it is upgraded, we can still send through the other (this is also useful for DR - disaster recover, etc). So from my example above only 1 connection would be active the other in bind retry loop (wait X seconds, etc) - no tcp connection is established to smsc. If we re-started kannel it wouldn't be a good idea to wait for both links to become active before pushing messages out - this would mean waiting for the upgraded smsc to come back online, no? Again sorry if I'm talking at cross purposes here. Cheers, Alan Nikos Balkanas wrote: Hi Alan, If even 1 SMSc in configuration file fails to start, bearerbox will panic. There are several states to any SMSc, like connecting, going down, etc. Bearerbox expects all SMScs to be available on startup. The operative word is available. If a configured modem is not connected, that's a failure and you would have to take it off configuration to startup. After it starts, SMScs can go up or down. Isolated mode still needs SMScs for outgoing messages. The only mode that doesn't is Suspended. But i don't think that even this will startup without all SMScs available. Available is different than Active. Available means anything but Failed (Dead,etc.). An available SMSc could be down, or coming up or connecting. In this patch, router will wait to start until all SMScs become active. What is DR? BR, Nikos - Original Message - From: Alan McNatty a...@catalyst.net.nz To: Nikos Balkanas nbalka...@gmail.com Cc: Alvaro Cornejo cornejo.alv...@gmail.com; devel@kannel.org Sent: Wednesday, June 10, 2009 1:22 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos, Sorry I haven't reviewed this whole thread in detail but was caught by .. bearerbox will not start unless all smscs are available. .. this worried me a bit. I'm concerned that in a DR scenario if 1 connection is down (and not coming up just yet) then I would like to be able to (re)start no problem (the other connections would start with this one remaining down .. trying to bind, etc). Is there not an alternative option in terms of (from init.d/startup perspective) start isolated, allowing some time (seconds) for the available connections to bind then setting the connections to active. Or have I missed the point here. Apologies if I'm muddying the water. I will try and follow more closely. Cheers, Alan Nikos Balkanas wrote: Dear Alvaro, I just managed to finish with my responsibilities, not on April 10, as I was hoping. Meanwhile, I haven't heard from you in a while, and I hope you are enjoying your vacations. Here is a patch to gw/bearerbox.c and gw/bb_smscconn.c, that doesn't start the sms_router, until all smscs (except the FAKE) are ACTIVE. If I am not mistaken, bearerbox will not start unless all smscs are available. So this is inline with this philosophy. I have tested it to the extend that it doesn't break anything, please let me know if it solves your problem. BR, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com Sent: Tuesday, March 31, 2009 4:56 PM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos No problem. I undestand we are on a best effort support XD and this is not a critical issue. Thanks Alvaro |-| EnvΞ“Βe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el PerΞ“Ξ�, MΓ©xico y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com 2009/3/31 Nikos Balkanas nbalka...@gmail.com: Hi Alvaro, Thanx for reminding me. Unfortunately I am still working very hard on my project. I will be finished by the 10th of April. Sorry about that and I hope I am not causing you trouble. I put a reminder on my PC not to forget. BR, Nikos - Original Message - From: Alvaro Cornejo cornejo.alv...@gmail.com To: Nikos Balkanas nbalka...@gmail.com; kannel users us...@kannel.org Sent: Tuesday, March 31, 2009 10:17 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos Had you chance to review this? Regards Alvaro |-| EnvΞ�β€�Ξ’Βe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el
Re: Kannel not load balancing after restart and messages get stuck inqueue
Hi Nikos I'm still around here... I've been busy this lasts days... I wish I was on vacations ;-) Regarding this patch, -I didn't had time to test it- but seems to solve the issue making kannel hold the queue assignment until all smsc's are online. However I do agree with Alan in the fact that that solution is not suitable since there can be many scenarios where an smsc will not come online or might be delayed at kannel startup and this will delay all message traffic. I'll be for a solution where Kannel recalculate its queue(loadbalance) for a given destination when a new destination for the given route/destination is available/unavailable and not only at startup. Another option might be to make kannel have an intermediate queue that is not assigned to an smsc until the smsc queue is less than 5min on the spscific smsc. This way in case of a restart, the 1st smsc to be available will get a moderate queue and the rest of smsc's will loadbalace the rest of messages once. Would something like that might be possible? I fear that an approach like this one will require a big remake of kannel queue/load management and I doubt kannel team will go for it. Also I stick in the opinion that kannel shouldn't panic if it can't set active/enable an smsc on startup since there can be other smscs that can process messages for other routes/destinations. This issue is more important since the only workarroud is to edit kannel.conf comment the offending smsc and restart kannel and once the smsc is fixed, re-edit kannel.conf and restart kannel since so far, there is no way to make kannel reread the config file. Once I test the patch I'll let you know. Probably this weekend. Regards and THANKS for your time Support Alvaro |-| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.perusms.NET www.smsglobal.com.mx y www.pravcom.com On Tue, Jun 9, 2009 at 10:14 PM, Alan McNattya...@catalyst.net.nz wrote: Hi Nikos, OK, yeah I'm not about failure at start-up time. If an SMSC is off-line (SMPP timeout/retry during bind) kannel will start (simply config a bogus IP address for SMPP to test this out). An example is lets say we have 2 connections for load balancing. Now consider 1 smsc being taken offline (no tcp connection) as it is upgraded, we can still send through the other (this is also useful for DR - disaster recover, etc). So from my example above only 1 connection would be active the other in bind retry loop (wait X seconds, etc) - no tcp connection is established to smsc. If we re-started kannel it wouldn't be a good idea to wait for both links to become active before pushing messages out - this would mean waiting for the upgraded smsc to come back online, no? Again sorry if I'm talking at cross purposes here. Cheers, Alan Nikos Balkanas wrote: Hi Alan, If even 1 SMSc in configuration file fails to start, bearerbox will panic. There are several states to any SMSc, like connecting, going down, etc. Bearerbox expects all SMScs to be available on startup. The operative word is available. If a configured modem is not connected, that's a failure and you would have to take it off configuration to startup. After it starts, SMScs can go up or down. Isolated mode still needs SMScs for outgoing messages. The only mode that doesn't is Suspended. But i don't think that even this will startup without all SMScs available. Available is different than Active. Available means anything but Failed (Dead,etc.). An available SMSc could be down, or coming up or connecting. In this patch, router will wait to start until all SMScs become active. What is DR? BR, Nikos - Original Message - From: Alan McNatty a...@catalyst.net.nz To: Nikos Balkanas nbalka...@gmail.com Cc: Alvaro Cornejo cornejo.alv...@gmail.com; devel@kannel.org Sent: Wednesday, June 10, 2009 1:22 AM Subject: Re: Kannel not load balancing after restart and messages get stuck inqueue Hi Nikos, Sorry I haven't reviewed this whole thread in detail but was caught by .. bearerbox will not start unless all smscs are available. .. this worried me a bit. I'm concerned that in a DR scenario if 1 connection is down (and not coming up just yet) then I would like to be able to (re)start no problem (the other connections would start with this one remaining down .. trying to bind, etc). Is there not an alternative option in terms of (from init.d/startup perspective) start isolated, allowing some time (seconds) for the available connections to bind then setting the connections to active. Or have I missed the point here. Apologies if I'm muddying the water. I will try and follow more closely. Cheers, Alan Nikos Balkanas wrote: Dear Alvaro,
