Re: MT Message Ack
Hi, I am pretty sure they both wait for an ACK, according to architecture. Else they wouldn't work at all. Standard procedure for all smsbox clients is to resend the SMS if they don't receive an ACK from bb. BR, Nikos On Fri, Sep 2, 2011 at 6:19 AM, JAmes jam...@gmail.com wrote: Hi, I am wondering, when smsbox / sqlbox is connected to bearerbox and sends a MT sms, does smsbox / sqlbox wait for an ACK from BB? How does smsbox/sqlbox handle sms messages that BB doesn't ack? Regards, J
Re: MT Message Ack
Hi Alex, The setup is not necessarily limited to a single server. Bb could be to another server than smsbox, even to different physical locations. Communication could be TCP over WAN. Network can cause a lot of failures and lost packages, beyond TCP retransmission. Are not ACKs implemented in smsbox? I have not seen the sources, yet. BR, Nikos On Fri, Sep 2, 2011 at 2:32 PM, Alexander Malysh amal...@kannel.org wrote: Hi James, why do you need retry between smsbox and bearerbox? bearerbox gives ack immediately and if not this is some strange bug that should be fixed. Thanks, Alex Am 02.09.2011 um 11:32 schrieb JAmes: Hi Alex, So you need to restart smsbox for it to retry sending the message to bearerbox? Regards, J On Fri, Sep 2, 2011 at 3:58 PM, Alexander Malysh amal...@kannel.orgwrote: Hi, smsbox does resend only by restart. Thanks, Alex Am 02.09.2011 um 10:16 schrieb James: Thanks Nikos. Do you know the wait time before smsbox considers to resend the message? Regards, J On 02/09/2011, at 3:12 PM, Nikos Balkanas nbalka...@gmail.com wrote: Hi, I am pretty sure they both wait for an ACK, according to architecture. Else they wouldn't work at all. Standard procedure for all smsbox clients is to resend the SMS if they don't receive an ACK from bb. BR, Nikos On Fri, Sep 2, 2011 at 6:19 AM, JAmes jam...@gmail.com wrote: Hi, I am wondering, when smsbox / sqlbox is connected to bearerbox and sends a MT sms, does smsbox / sqlbox wait for an ACK from BB? How does smsbox/sqlbox handle sms messages that BB doesn't ack? Regards, J
Re: HTTP admin restart issues
That's how heartbeats are implemented. Even if smsbox is idle (i.e. no sms) heartbeats still go out every 30 and smsbox goes down. BR, Nikos On Wed, Aug 31, 2011 at 11:38 AM, Jacob Eiler jacob.ei...@apide.com wrote: Hi. Thank you for the feedback. On Tue, 2011-08-30 at 23:00 +0300, Nikos Balkanas wrote: 3. If bearerbox is in parachute mode and restarted for any reason, smsbox goes down and stays down. This is caused by failed heartbeats. It can be fixed by introducing a small delay witth retry in smsbox, if it realizes that bearerbox connectiuon is dropped. Actually the cause is the closing of the bearerbox-connection, causing read_from_bearerbox_real to return -1 and in turn the smsbox to shutdown.
Re: HTTP admin restart issues
Hi, I wouild like to add 1 more snag: 3. If bearerbox is in parachute mode and restarted for any reason, smsbox goes down and stays down. This is caused by failed heartbeats. It can be fixed by introducing a small delay witth retry in smsbox, if it realizes that bearerbox connectiuon is dropped. (1) Could you please post panic logs?I don't think it is due to the pid file. In my experience web restart fails always, because it doesn't preserve the original location and execvp() can't find the executable. Solution is to save original launch directory (i.e. /usr/local/bin) and then do a chdir() just before you call execvp. You see, after initialization, bearerbox runs from / and all relative paths are broken. This could include the pid file as well. (2). Same solution as in (3). Introduce a small delay to smsbox. However, for this you don't need to modify the sources, you can just delay it in the init script. BR, Nikos On Tue, Aug 30, 2011 at 4:20 PM, Jacob Eiler jacob.ei...@apide.com wrote: Hi. I am trying to use the http administration interface to restart Kannel, but there are a few snags and frankly I believe the current implementation is broken: 1. Restart does not work in combination with --pid-file If bearerbox (or smsbox) is started with --pid-file, then the restart will cause a panic. This is because the execvp call uses the same arguments (makes sense), but the attempt to write the pid-file in gwlib/utils.c#write_pid_file fails/panics as the file already exists. This could be fixed by removing the pid-file option from the command line arguments, but I am not sure if this is a good solution. 2. smsbox restarts before bearerbox has restarted In my experience the smsbox attempts to restart while the bearerbox is still in the final part of the shutdown. Consequently the smsbox attempts to bind to the bearerbox before the new bearerbox has opened the port. This causes smsbox to panic and never get up again. I am not sure how to fix this issue - any input? BR Jacob -- Jacob Eiler Apide ApS e: jacob.ei...@apide.com t: +45 2374 0486 w: apide.com
Re: Setting priority flag
I use vim. Adequate for small patches (0 - 3), but you can get in touble with larger ones. For a proper environment you need docbook dtd along with openjade. The docbook dtd is not proper XML and will cause problem in a regular XML editor. @Alex: Was my last wtls userguide patch OK, or did you help it along? BR, Nikos On Wed, Aug 24, 2011 at 2:22 AM, Juan Nin jua...@gmail.com wrote: On 8/23/11 1:59 PM, Alexander Malysh wrote: Hi, Am 22.08.2011 um 20:22 schrieb Juan Nin: Note that the user guide is wrong, it says 0 is the higher priority while it's the lowest and 3 is the highest fixed in SVN... Thanks Alex! This has been noted multiple times on the list, not sure why the docs have not been fixed though It would be faster if you made and posted patch... heh, was expecting this answer :) Long time ago I tried to edit the User Guide with Oxygen and other tools, in order to be able to send patches of it, but didn't work with any tool I used, all of them failed opening it due to syntax errors. I asked on the list how you guys were editing it, but never got a reply. So I ask again, what tool do you use/recommend for editing it so as to be able to modify it? Thanks in advance. Juan
Re: Making SMPP esm_class configurable?
Hi Alex, I don't agree that this should be left open to the user. A few may know what to do with the spec. However, a lot will play around with the values until they get them working. Consider that a user sets this to DATAGRAM, and kannel generates a store and forward pdu with DATAGRAM esm_class. It doesn't hurt kannel, but what about the SMSc that receives it? It could possibly generate a core dump if the implementation is widely different, resulting in loss of service. Do you really want to leave that open? BR, Nikos On Thu, Aug 18, 2011 at 11:31 AM, Alexander Malysh amal...@kannel.orgwrote: Hi Alan, sorry to write my response late (I was on vacation), but I don't think we need some restriction on configured esm-class. If we allow to change esm-class in the config, IMHO there is no need to restrict it's value, because the user know what he does. For cannel it's equal, which value to set as esm-class because kannel doesn't interpreting it. Thanks, Alex Am 15.08.2011 um 09:35 schrieb Alan McNatty: Thanks Nikos, That's good news since, thanks to Edgard for pointing out, I forgot to include gwlib/cfg.def in the patch. Updated patch attached. Cheers, Alan On Mon, 2011-08-15 at 04:29 +0300, Nikos Balkanas wrote: I guess Alex M is busy. There are a few patches prior to yours that wait for commission. Don't worry, he never misses a patch. He is the gateway maintainer. BR, Nikos On Mon, Aug 15, 2011 at 3:22 AM, Alan McNatty a...@catalyst.net.nz wrote: Thanks Rene, Can anyone with commit access give a final nod of acceptance? On Tue, 2011-08-09 at 21:08 +0200, Rene Kluwen wrote: +1 for me as well. From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Nikos Balkanas Sent: Tuesday, 09 August, 2011 02:11 To: Alan McNatty Cc: devel@kannel.org Subject: Re: Making SMPP esm_class configurable? Looks great! +1. Nikos On Tue, Aug 9, 2011 at 2:59 AM, Alan McNatty a...@catalyst.net.nz wrote: Thanks again Nikos, Yeah 0 and 3 are all I'm interested in - wasn't sure if others wanted support for non-compliant things. Made changes as you suggested - please check out the attached patch. Cheers, Alan On Mon, 2011-08-08 at 05:39 +0300, Nikos Balkanas wrote: Hi Alan, Currently kannel doesn't support more modes. Therefore test should more specific: else if (esm_class != SMPP_STORE... esm_class != DEFAULT...)) // use constants Also I see no need for panicking over a single smsc: error(0, SMPP: Invalid esm_class mode \5\ in configuration. Switching to \Store and Forward\); There are still many hexadecimal references to the userguide, and it doesn't restrict choices. Therefore, I suggest the following text: Value for esm_class according to the SMPP spec. Accepted values are 0 (Default smsc mode) and 3 (Store and Forward). Defaults to 3. HTH, Nikos On Mon, Aug 8, 2011 at 5:01 AM, Alan McNatty a...@catalyst.net.nz wrote: Thanks Nikos, See attached. Also just wanted to check thoughts the range check (possibly remove and leave it open?). i.e. +else if (esm_class 0x03 || esm_class 0) +panic(0, SMPP: Invalid esm_class directive in configuration.); On Mon, 2011-08-08 at 04:44 +0300, Nikos Balkanas wrote: Hi Alan, Patch looks good. userguide needs some changes: 1) Capitalize after periods (For example, For default mode) 2) In configuration the value should be integer, not hex (3 not 03). cfg_get_integer doesn't understand hex (0xA5). +1 Nikos On Mon, Aug 8, 2011 at 4:02 AM, Alan McNatty a...@catalyst.net.nz wrote: patch attached. Votes / comments, etc? On Wed, 2011-08-03 at 09:39 +1200, Alan McNatty wrote: Thanks Nikos/Alex for the feedback - I will work on config patch. On Tue, 2011-08-02 at 23:10 +0300, Nikos Balkanas wrote: Hi Alan, Just to clarify on what Alex says. Some other modes that the SMSc may support in default mode, are: Datagram: UDP based, immediate best effort high throughput transmition with no retried, validity period or storage. Similar to UDP. Forward: Single transaction based, for real-time applications, i.e. parking tickets, without storage, where result is returned in response. Kannel doesn't support those, only reliable store and forward. Therefore the default mode wouldn't
Re: Patch: wtls userguide
Hi Alex, These are actually different ones. Fixed them, too. As mentioned I cannot validate result since I can't install openjade in Solaris. So I am going through with your error reports. Hoping this is the last one, Nikos On Thu, Aug 18, 2011 at 11:11 AM, Alexander Malysh amal...@kannel.orgwrote: Hi Nikos, seems your patch didn't fixed it: jade:doc/userguide/userguide.tmp:2252:39:E: there is no attribute TITLE jade:doc/userguide/userguide.tmp:2279:9:E: end tag for LISTITEM omitted, but OMITTAG NO was specified jade:doc/userguide/userguide.tmp:2265:3: start tag was here jade:doc/userguide/userguide.tmp:2279:9:E: end tag for ORDEREDLIST omitted, but OMITTAG NO was specified jade:doc/userguide/userguide.tmp:2251:2: start tag was here jade:doc/userguide/userguide.tmp:2279:20:E: end tag for element LISTITEM which is not open jade:doc/userguide/userguide.tmp:2280:12:E: document type does not allow element LISTITEM here; missing one of ITEMIZEDLIST, ORDEREDLIST start-tag jade:doc/userguide/userguide.tmp:2298:9:E: end tag for element PARA which is not open jade:doc/userguide/userguide.tmp:2299:12:E: document type does not allow element LISTITEM here; missing one of ITEMIZEDLIST, ORDEREDLIST start-tag jade:doc/userguide/userguide.tmp:2306:14:E: end tag for element ORDEREDLIST which is not open jade:doc/userguide/userguide.tmp:2306:21:E: end tag for element PARA which is not open jade:doc/userguide/userguide.tmp:2318:6:E: document type does not allow element SECT1 here jade:doc/userguide/userguide.tmp:2358:9:E: end tag for PARA omitted, but OMITTAG NO was specified jade:doc/userguide/userguide.tmp:2308:1: start tag was here make: *** [doc/userguide/userguide.html] Error 1 Thanks, Alex Am 17.08.2011 um 05:47 schrieb Nikos Balkanas: Hi Alex, Any news? Still can't see it in the Userguide. BR, Nikos - Original Message - From: Nikos Balkanas To: Alexander Malysh Cc: Kannel Devel Sent: Sunday, August 07, 2011 3:13 AM Subject: Re: Patch: wtls userguide Hi Alex, I corrected everything by the eye using the docbook dtd and your error reporting. I fixed all the errors in your report. It seems to me valid by the dtd, however, I don't know how it looks (nested ordered lists). I was not able to validate, since a docbook validator would seriously change my environment. BR, Nikos On Sat, Aug 6, 2011 at 12:03 AM, Nikos Balkanas nbalka...@gmail.com wrote: My apologies for that. It is very difficult to build a docbook environment in Solaris. I have already fixed manually one problem in nested lists from the dtd, and have downloaded some docbook viewers for windows. As soon as i get the (free) licenses for them and verify the patch, I will submit again. BR, Nikos On Fri, Aug 5, 2011 at 11:52 AM, Alexander Malysh amal...@kannel.org wrote: Hi Nikos, could you please check your patch because it produce errors: jade:doc/userguide/userguide.tmp:2253:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2253:31:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2254:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2254:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2255:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2255:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2256:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2256:37:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2257:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2257:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2258:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2258:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2259:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2259:37:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2263:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2263:36:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2268:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2268:36:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2269:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2269:36:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2270:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2270:33:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2271:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2271:33:E: end tag
Re: Patch: wtls userguide
Sorry, forgot one error. Take this one. BR, Nikos On Fri, Aug 19, 2011 at 5:29 AM, Nikos Balkanas nbalka...@gmail.com wrote: Hi Alex, These are actually different ones. Fixed them, too. As mentioned I cannot validate result since I can't install openjade in Solaris. So I am going through with your error reports. Hoping this is the last one, Nikos On Thu, Aug 18, 2011 at 11:11 AM, Alexander Malysh amal...@kannel.orgwrote: Hi Nikos, seems your patch didn't fixed it: jade:doc/userguide/userguide.tmp:2252:39:E: there is no attribute TITLE jade:doc/userguide/userguide.tmp:2279:9:E: end tag for LISTITEM omitted, but OMITTAG NO was specified jade:doc/userguide/userguide.tmp:2265:3: start tag was here jade:doc/userguide/userguide.tmp:2279:9:E: end tag for ORDEREDLIST omitted, but OMITTAG NO was specified jade:doc/userguide/userguide.tmp:2251:2: start tag was here jade:doc/userguide/userguide.tmp:2279:20:E: end tag for element LISTITEM which is not open jade:doc/userguide/userguide.tmp:2280:12:E: document type does not allow element LISTITEM here; missing one of ITEMIZEDLIST, ORDEREDLIST start-tag jade:doc/userguide/userguide.tmp:2298:9:E: end tag for element PARA which is not open jade:doc/userguide/userguide.tmp:2299:12:E: document type does not allow element LISTITEM here; missing one of ITEMIZEDLIST, ORDEREDLIST start-tag jade:doc/userguide/userguide.tmp:2306:14:E: end tag for element ORDEREDLIST which is not open jade:doc/userguide/userguide.tmp:2306:21:E: end tag for element PARA which is not open jade:doc/userguide/userguide.tmp:2318:6:E: document type does not allow element SECT1 here jade:doc/userguide/userguide.tmp:2358:9:E: end tag for PARA omitted, but OMITTAG NO was specified jade:doc/userguide/userguide.tmp:2308:1: start tag was here make: *** [doc/userguide/userguide.html] Error 1 Thanks, Alex Am 17.08.2011 um 05:47 schrieb Nikos Balkanas: Hi Alex, Any news? Still can't see it in the Userguide. BR, Nikos - Original Message - From: Nikos Balkanas To: Alexander Malysh Cc: Kannel Devel Sent: Sunday, August 07, 2011 3:13 AM Subject: Re: Patch: wtls userguide Hi Alex, I corrected everything by the eye using the docbook dtd and your error reporting. I fixed all the errors in your report. It seems to me valid by the dtd, however, I don't know how it looks (nested ordered lists). I was not able to validate, since a docbook validator would seriously change my environment. BR, Nikos On Sat, Aug 6, 2011 at 12:03 AM, Nikos Balkanas nbalka...@gmail.com wrote: My apologies for that. It is very difficult to build a docbook environment in Solaris. I have already fixed manually one problem in nested lists from the dtd, and have downloaded some docbook viewers for windows. As soon as i get the (free) licenses for them and verify the patch, I will submit again. BR, Nikos On Fri, Aug 5, 2011 at 11:52 AM, Alexander Malysh amal...@kannel.org wrote: Hi Nikos, could you please check your patch because it produce errors: jade:doc/userguide/userguide.tmp:2253:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2253:31:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2254:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2254:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2255:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2255:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2256:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2256:37:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2257:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2257:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2258:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2258:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2259:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2259:37:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2263:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2263:36:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2268:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2268:36:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2269:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2269:36:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2270:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2270:33:E: end tag for LISTITEM which is not finished
Re: Making SMPP esm_class configurable?
Unfortunately, SMScs do not distinguish between newbies and seasoned kannel users. If they don't support an esm_class, then they will say so regardless who is on the other end. Sometimes cost doesn't justify switching an operator. Therefore, anyone could need to change this value, and people will start playing around with these, if they are left open. I see no harm in closing them down, to only what kannel supports. The reasoning behind making it numerical, is that if ever kannel decides to support another mode, upgrade would be easier. Otherwise I am fine with a boolean value. BR, Nikos On Fri, Aug 19, 2011 at 12:36 AM, Kenny ken.bell...@gmail.com wrote: Hi, I would naturally suggest we go for option *(a) *and allow users to set their values. Of course only advance users would want to work with this value anyway. My reason is simple, there is no much sense in creating a non-boolen config value and then limit users on what they put there. Truth is, I have already seen an SMSC requesting for a value other than 0 and 3. -- Regards Kenny On Thu, Aug 18, 2011 at 5:57 PM, Alexander Malysh amal...@kannel.orgwrote: Hi, I don't see this as issue. The user ether let it default or try to change in agreement with SMSC operator. If user will try some random values then operator will just shutdown his account. If you ask me, I don't see any need to allow changing default esm-class. But if we see buggy SMSCs that don't accept STORE FORWARD mode then I don't know what to expect here. Maybe some drunk developer implement SMS as datagram mode, who knows :-) We have 2 options: a) allow user to set any values and write in the docs that this may be dangerous b) we restrict user to only have two options 0 (default mode) and 3 (store forward), then boolean value should be enough Alex Am 18.08.2011 um 12:33 schrieb Nikos Balkanas: Hi Alex, I don't agree that this should be left open to the user. A few may know what to do with the spec. However, a lot will play around with the values until they get them working. Consider that a user sets this to DATAGRAM, and kannel generates a store and forward pdu with DATAGRAM esm_class. It doesn't hurt kannel, but what about the SMSc that receives it? It could possibly generate a core dump if the implementation is widely different, resulting in loss of service. Do you really want to leave that open? BR, Nikos On Thu, Aug 18, 2011 at 11:31 AM, Alexander Malysh amal...@kannel.orgwrote: Hi Alan, sorry to write my response late (I was on vacation), but I don't think we need some restriction on configured esm-class. If we allow to change esm-class in the config, IMHO there is no need to restrict it's value, because the user know what he does. For cannel it's equal, which value to set as esm-class because kannel doesn't interpreting it. Thanks, Alex Am 15.08.2011 um 09:35 schrieb Alan McNatty: Thanks Nikos, That's good news since, thanks to Edgard for pointing out, I forgot to include gwlib/cfg.def in the patch. Updated patch attached. Cheers, Alan On Mon, 2011-08-15 at 04:29 +0300, Nikos Balkanas wrote: I guess Alex M is busy. There are a few patches prior to yours that wait for commission. Don't worry, he never misses a patch. He is the gateway maintainer. BR, Nikos On Mon, Aug 15, 2011 at 3:22 AM, Alan McNatty a...@catalyst.net.nz wrote: Thanks Rene, Can anyone with commit access give a final nod of acceptance? On Tue, 2011-08-09 at 21:08 +0200, Rene Kluwen wrote: +1 for me as well. From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Nikos Balkanas Sent: Tuesday, 09 August, 2011 02:11 To: Alan McNatty Cc: devel@kannel.org Subject: Re: Making SMPP esm_class configurable? Looks great! +1. Nikos On Tue, Aug 9, 2011 at 2:59 AM, Alan McNatty a...@catalyst.net.nz wrote: Thanks again Nikos, Yeah 0 and 3 are all I'm interested in - wasn't sure if others wanted support for non-compliant things. Made changes as you suggested - please check out the attached patch. Cheers, Alan On Mon, 2011-08-08 at 05:39 +0300, Nikos Balkanas wrote: Hi Alan, Currently kannel doesn't support more modes. Therefore test should more specific: else if (esm_class != SMPP_STORE... esm_class != DEFAULT...)) // use constants Also I see no need for panicking over a single smsc: error(0, SMPP: Invalid esm_class mode \5\ in configuration. Switching to \Store and Forward\); There are still many hexadecimal references to the userguide, and it doesn't restrict choices. Therefore, I suggest the following text: Value for esm_class according to the SMPP spec. Accepted values are 0 (Default smsc mode) and 3 (Store and Forward). Defaults to 3
Re: panic inducing use of gwlist_extract_first in dlr_pgsql.c
Hi Alan,
I wholeheartedly agree. Consider the case that it cannot find a specific
DLR, everything else (DB, etc.) being fine, it shouldn't panic. This is the
normal behaviour with the other db drivers (not to panic), when people have
wrong msg-id-type, or dlr entry is lost upon bb restart, or SMSc sends in
DLR before the submit_sm_resp with the DLR-id.
The statement:
if (result == NULL...)
{
while(row = gwlist_extract_first(result)) - lock(result)
it doesn't make any sense at all. The faster it is replaced the better.
+1
BR,
Nikos
- Original Message -
From: Alan McNatty a...@catalyst.net.nz
To: Nikos Balkanas nbalka...@gmail.com
Cc: devel@kannel.org
Sent: Wednesday, August 10, 2011 12:08 PM
Subject: Re: panic inducing use of gwlist_extract_first in dlr_pgsql.c
Hi Nikos,
So do you agree that we should avoid panic'ing as a result of a
temporary situation (as outlined with db connection dropping)? That is -
the patch is good?
Cheers,
Alan
On Wed, 2011-08-10 at 11:03 +0300, Nikos Balkanas wrote:
That is a well known behavior. Bb crashes and stops responding to the
heartbeats that smsbox sends. As a result, smsbox logs in bearerbox
gone, shutting down and shuts down. The parent bb process should
handle heartbeats, not the child.
HTH,
Nikos
On Wed, Aug 10, 2011 at 9:56 AM, Alan McNatty a...@catalyst.net.nz
wrote:
Also note: a side effect of the current behaviour (panic when
DB
temporarily unavailable) when --parachute used at start-up is
that
smsbox will be shutdown as a result of the panic but bearerbox
will come
back online when the DB is available again (as the --parachute
keeps it
alive). The result being a running bearerbox without any
smsbox(es)
attached.
On Wed, 2011-08-10 at 16:51 +1200, Alan McNatty wrote:
Hi All,
I'm finding what I think is incorrect use of
gwlist_extract_first in the
postgres dlr implementations (it may also exist in others -
I've not
checked yet). The DLR methods issue 'error's when they fail
to return
results, etc but subsequent calls to gwlist_extract_first on
NULL lists
cause 'panic's.
What I'm testing is the situation when the DLR DB is
available on
start-up (we panic if it is not). If during during normal
operation the
database is shutdown or temporarily unavailable (network
issue, etc).
The select fail is an error but results in a panic.
2011-08-10 16:37:43 [18552] [3] ERROR: PGSQL: SELECT
count(*) FROM
dlr;
2011-08-10 16:37:43 [18552] [3] ERROR: PGSQL: FATAL:
terminating
connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
2011-08-10 16:37:43 [18552] [3] ERROR: PGSQL: Select failed!
2011-08-10 16:37:43 [18552] [3] ERROR: PGSQL: Could not get
count of DLR
table
2011-08-10 16:37:43 [18552] [3] PANIC: gwlib/list.c:309:
gwlist_extract_first: Assertion `list != NULL' failed.
2011-08-10 16:37:43 [18552] [3]
PANIC: /usr/sbin/bearerbox(gw_panic
+0x14b) [0x48b55b]
2011-08-10 16:37:43 [18552] [3]
PANIC: /usr/sbin/bearerbox(gwlist_extract_first+0x94)
[0x489874]
2011-08-10 16:37:43 [18552] [3] PANIC: /usr/sbin/bearerbox
[0x41e3d3]
2011-08-10 16:37:43 [18552] [3]
PANIC: /usr/sbin/bearerbox(bb_print_status+0x11d) [0x40edfd]
2011-08-10 16:37:43 [18552] [3] PANIC: /usr/sbin/bearerbox
[0x415075]
2011-08-10 16:37:43 [18552] [3] PANIC: /usr/sbin/bearerbox
[0x4823cf]
2011-08-10 16:37:43 [18552] [3] PANIC: /lib/libpthread.so.0
[0x2b0e670a9fc7]
2011-08-10 16:37:43 [18552] [3] PANIC: /lib/libc.so.6(clone
+0x6d)
[0x2b0e67a8664d]
The attached patch addresses this (for postgres
implementation only - I
can check the others if required). Once applied The result
on the status
page is ..
DLR: -1 queued, using pgsql storage
And when a DLR is received ...
2011-08-10 16:44:53 [18889] [11] ERROR: PGSQL: FATAL:
terminating
connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
2011-08-10 16:44:53 [18889] [11] ERROR: PGSQL: Select
failed!
2011-08-10 16:44:53 [18889] [11] DEBUG: no rows found
2011-08-10 16:44:53 [18889] [11] WARNING: DLR[pgsql]: DLR
Re: panic inducing use of gwlist_extract_first in dlr_pgsql.c
That is a well known behavior. Bb crashes and stops responding to the heartbeats that smsbox sends. As a result, smsbox logs in bearerbox gone, shutting down and shuts down. The parent bb process should handle heartbeats, not the child. HTH, Nikos On Wed, Aug 10, 2011 at 9:56 AM, Alan McNatty a...@catalyst.net.nz wrote: Also note: a side effect of the current behaviour (panic when DB temporarily unavailable) when --parachute used at start-up is that smsbox will be shutdown as a result of the panic but bearerbox will come back online when the DB is available again (as the --parachute keeps it alive). The result being a running bearerbox without any smsbox(es) attached. On Wed, 2011-08-10 at 16:51 +1200, Alan McNatty wrote: Hi All, I'm finding what I think is incorrect use of gwlist_extract_first in the postgres dlr implementations (it may also exist in others - I've not checked yet). The DLR methods issue 'error's when they fail to return results, etc but subsequent calls to gwlist_extract_first on NULL lists cause 'panic's. What I'm testing is the situation when the DLR DB is available on start-up (we panic if it is not). If during during normal operation the database is shutdown or temporarily unavailable (network issue, etc). The select fail is an error but results in a panic. 2011-08-10 16:37:43 [18552] [3] ERROR: PGSQL: SELECT count(*) FROM dlr; 2011-08-10 16:37:43 [18552] [3] ERROR: PGSQL: FATAL: terminating connection due to administrator command server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. 2011-08-10 16:37:43 [18552] [3] ERROR: PGSQL: Select failed! 2011-08-10 16:37:43 [18552] [3] ERROR: PGSQL: Could not get count of DLR table 2011-08-10 16:37:43 [18552] [3] PANIC: gwlib/list.c:309: gwlist_extract_first: Assertion `list != NULL' failed. 2011-08-10 16:37:43 [18552] [3] PANIC: /usr/sbin/bearerbox(gw_panic +0x14b) [0x48b55b] 2011-08-10 16:37:43 [18552] [3] PANIC: /usr/sbin/bearerbox(gwlist_extract_first+0x94) [0x489874] 2011-08-10 16:37:43 [18552] [3] PANIC: /usr/sbin/bearerbox [0x41e3d3] 2011-08-10 16:37:43 [18552] [3] PANIC: /usr/sbin/bearerbox(bb_print_status+0x11d) [0x40edfd] 2011-08-10 16:37:43 [18552] [3] PANIC: /usr/sbin/bearerbox [0x415075] 2011-08-10 16:37:43 [18552] [3] PANIC: /usr/sbin/bearerbox [0x4823cf] 2011-08-10 16:37:43 [18552] [3] PANIC: /lib/libpthread.so.0 [0x2b0e670a9fc7] 2011-08-10 16:37:43 [18552] [3] PANIC: /lib/libc.so.6(clone+0x6d) [0x2b0e67a8664d] The attached patch addresses this (for postgres implementation only - I can check the others if required). Once applied The result on the status page is .. DLR: -1 queued, using pgsql storage And when a DLR is received ... 2011-08-10 16:44:53 [18889] [11] ERROR: PGSQL: FATAL: terminating connection due to administrator command server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. 2011-08-10 16:44:53 [18889] [11] ERROR: PGSQL: Select failed! 2011-08-10 16:44:53 [18889] [11] DEBUG: no rows found 2011-08-10 16:44:53 [18889] [11] WARNING: DLR[pgsql]: DLR from SMSCFOO for DST02x not found. 2011-08-10 16:44:53 [18889] [11] ERROR: SMPP[FOO]: got DLR but could not find message or was not interested in it id534001841355 dst02x, type1 Cheers, Alan
Re: Making SMPP esm_class configurable?
Looks great! +1. Nikos On Tue, Aug 9, 2011 at 2:59 AM, Alan McNatty a...@catalyst.net.nz wrote: Thanks again Nikos, Yeah 0 and 3 are all I'm interested in - wasn't sure if others wanted support for non-compliant things. Made changes as you suggested - please check out the attached patch. Cheers, Alan On Mon, 2011-08-08 at 05:39 +0300, Nikos Balkanas wrote: Hi Alan, Currently kannel doesn't support more modes. Therefore test should more specific: else if (esm_class != SMPP_STORE... esm_class != DEFAULT...)) // use constants Also I see no need for panicking over a single smsc: error(0, SMPP: Invalid esm_class mode \5\ in configuration. Switching to \Store and Forward\); There are still many hexadecimal references to the userguide, and it doesn't restrict choices. Therefore, I suggest the following text: Value for esm_class according to the SMPP spec. Accepted values are 0 (Default smsc mode) and 3 (Store and Forward). Defaults to 3. HTH, Nikos On Mon, Aug 8, 2011 at 5:01 AM, Alan McNatty a...@catalyst.net.nz wrote: Thanks Nikos, See attached. Also just wanted to check thoughts the range check (possibly remove and leave it open?). i.e. +else if (esm_class 0x03 || esm_class 0) +panic(0, SMPP: Invalid esm_class directive in configuration.); On Mon, 2011-08-08 at 04:44 +0300, Nikos Balkanas wrote: Hi Alan, Patch looks good. userguide needs some changes: 1) Capitalize after periods (For example, For default mode) 2) In configuration the value should be integer, not hex (3 not 03). cfg_get_integer doesn't understand hex (0xA5). +1 Nikos On Mon, Aug 8, 2011 at 4:02 AM, Alan McNatty a...@catalyst.net.nz wrote: patch attached. Votes / comments, etc? On Wed, 2011-08-03 at 09:39 +1200, Alan McNatty wrote: Thanks Nikos/Alex for the feedback - I will work on config patch. On Tue, 2011-08-02 at 23:10 +0300, Nikos Balkanas wrote: Hi Alan, Just to clarify on what Alex says. Some other modes that the SMSc may support in default mode, are: Datagram: UDP based, immediate best effort high throughput transmition with no retried, validity period or storage. Similar to UDP. Forward: Single transaction based, for real-time applications, i.e. parking tickets, without storage, where result is returned in response. Kannel doesn't support those, only reliable store and forward. Therefore the default mode wouldn't be appropriate. Configuration would be fine for those buggy SMScs, that do store and forward, but do not accept it as an option. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Alan McNatty a...@catalyst.net.nz Cc: Nikos Balkanas nbalka...@gmail.com; de...@vm1.kannel.org Sent: Tuesday, August 02, 2011 12:29 PM Subject: Re: Making SMPP esm_class configurable? Hi, please don't change default because we want that SMSC _store_ and _forward_ our message that is what we also tell SMSC. This works in 99% cases but sometimes buggy SMSCs don't accept this and rejects messages. Please keep default as is and make config option for buggy SMSCs. Thanks, Alex Am 02.08.2011 um 06:11 schrieb Alan McNatty: Sorry that should be ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE. Index: gw/smsc/smsc_smpp.c
Re: Making SMPP esm_class configurable?
Hi Alan, Patch looks good. userguide needs some changes: 1) Capitalize after periods (For example, For default mode) 2) In configuration the value should be integer, not hex (3 not 03). cfg_get_integer doesn't understand hex (0xA5). +1 Nikos On Mon, Aug 8, 2011 at 4:02 AM, Alan McNatty a...@catalyst.net.nz wrote: patch attached. Votes / comments, etc? On Wed, 2011-08-03 at 09:39 +1200, Alan McNatty wrote: Thanks Nikos/Alex for the feedback - I will work on config patch. On Tue, 2011-08-02 at 23:10 +0300, Nikos Balkanas wrote: Hi Alan, Just to clarify on what Alex says. Some other modes that the SMSc may support in default mode, are: Datagram: UDP based, immediate best effort high throughput transmition with no retried, validity period or storage. Similar to UDP. Forward: Single transaction based, for real-time applications, i.e. parking tickets, without storage, where result is returned in response. Kannel doesn't support those, only reliable store and forward. Therefore the default mode wouldn't be appropriate. Configuration would be fine for those buggy SMScs, that do store and forward, but do not accept it as an option. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Alan McNatty a...@catalyst.net.nz Cc: Nikos Balkanas nbalka...@gmail.com; de...@vm1.kannel.org Sent: Tuesday, August 02, 2011 12:29 PM Subject: Re: Making SMPP esm_class configurable? Hi, please don't change default because we want that SMSC _store_ and _forward_ our message that is what we also tell SMSC. This works in 99% cases but sometimes buggy SMSCs don't accept this and rejects messages. Please keep default as is and make config option for buggy SMSCs. Thanks, Alex Am 02.08.2011 um 06:11 schrieb Alan McNatty: Sorry that should be ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE. Index: gw/smsc/smsc_smpp.c === --- gw/smsc/smsc_smpp.c (revision 4913) +++ gw/smsc/smsc_smpp.c (working copy) @@ -876,7 +876,7 @@ * set the esm_class field * default is store and forward, plus udh and rpi if requested */ -pdu-u.submit_sm.esm_class = ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE; +pdu-u.submit_sm.esm_class = ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE; if (octstr_len(msg-sms.udhdata)) pdu-u.submit_sm.esm_class = pdu-u.submit_sm.esm_class | ESM_CLASS_SUBMIT_UDH_INDICATOR; On Tue, 2011-08-02 at 15:59 +1200, Alan McNatty wrote: Hi Nikos, You mean simply change the default: Index: gw/smsc/smsc_smpp.c === --- gw/smsc/smsc_smpp.c (revision 4913) +++ gw/smsc/smsc_smpp.c (working copy) @@ -876,7 +876,7 @@ * set the esm_class field * default is store and forward, plus udh and rpi if requested */ -pdu-u.submit_sm.esm_class = ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE; +pdu-u.submit_sm.esm_class = ESM_CLASS_DEFAULT_SMSC_MODE; if (octstr_len(msg-sms.udhdata)) pdu-u.submit_sm.esm_class = pdu-u.submit_sm.esm_class | ESM_CLASS_SUBMIT_UDH_INDICATOR; Anyone think we should have a config option? Or just happy to run with he above. I need to test myself but is this likely to be a compatibility breaker for anyone? Cheers, Alan On Mon, 2011-08-01 at 07:13 +0300, Nikos Balkanas wrote: Hi Alan, According to the spec SMPP 5.0, p 125, ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE is the default esm class. That part should be patched in. As far as making it configurable, I have no objections to it. A few people over the years have had to manually patch it in. BR, Nikos - Original Message - From: Alan McNatty a...@catalyst.net.nz To: devel@kannel.org Sent: Monday, August 01, 2011 6:21 AM Subject: Making SMPP esm_class configurable? Hi All, I found a thread on this from back in Feb 2005 (having received a query from provided now myself) .. last word by Alejandro and a lukewarm (+0 - +1) comment from Stipe about committing if patch provided. I would provide a config patch if anyone would vote in it's favour? Consider: gw/smsc/smsc_smpp.c 875 /* 876 * set the esm_class field 877 * default is store and forward, plus udh and rpi if requested 878 */ 879 pdu-u.submit_sm.esm_class = ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE; But the 'default' is surely ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE, no? Cheers, Alan
Re: Making SMPP esm_class configurable?
Hi Alan, Currently kannel doesn't support more modes. Therefore test should more specific: else if (esm_class != SMPP_STORE... esm_class != DEFAULT...)) // use constants Also I see no need for panicking over a single smsc: error(0, SMPP: Invalid esm_class mode \5\ in configuration. Switching to \Store and Forward\); There are still many hexadecimal references to the userguide, and it doesn't restrict choices. Therefore, I suggest the following text: Value for esm_class according to the SMPP spec. Accepted values are 0 (Default smsc mode) and 3 (Store and Forward). Defaults to 3. HTH, Nikos On Mon, Aug 8, 2011 at 5:01 AM, Alan McNatty a...@catalyst.net.nz wrote: Thanks Nikos, See attached. Also just wanted to check thoughts the range check (possibly remove and leave it open?). i.e. +else if (esm_class 0x03 || esm_class 0) +panic(0, SMPP: Invalid esm_class directive in configuration.); On Mon, 2011-08-08 at 04:44 +0300, Nikos Balkanas wrote: Hi Alan, Patch looks good. userguide needs some changes: 1) Capitalize after periods (For example, For default mode) 2) In configuration the value should be integer, not hex (3 not 03). cfg_get_integer doesn't understand hex (0xA5). +1 Nikos On Mon, Aug 8, 2011 at 4:02 AM, Alan McNatty a...@catalyst.net.nz wrote: patch attached. Votes / comments, etc? On Wed, 2011-08-03 at 09:39 +1200, Alan McNatty wrote: Thanks Nikos/Alex for the feedback - I will work on config patch. On Tue, 2011-08-02 at 23:10 +0300, Nikos Balkanas wrote: Hi Alan, Just to clarify on what Alex says. Some other modes that the SMSc may support in default mode, are: Datagram: UDP based, immediate best effort high throughput transmition with no retried, validity period or storage. Similar to UDP. Forward: Single transaction based, for real-time applications, i.e. parking tickets, without storage, where result is returned in response. Kannel doesn't support those, only reliable store and forward. Therefore the default mode wouldn't be appropriate. Configuration would be fine for those buggy SMScs, that do store and forward, but do not accept it as an option. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Alan McNatty a...@catalyst.net.nz Cc: Nikos Balkanas nbalka...@gmail.com; de...@vm1.kannel.org Sent: Tuesday, August 02, 2011 12:29 PM Subject: Re: Making SMPP esm_class configurable? Hi, please don't change default because we want that SMSC _store_ and _forward_ our message that is what we also tell SMSC. This works in 99% cases but sometimes buggy SMSCs don't accept this and rejects messages. Please keep default as is and make config option for buggy SMSCs. Thanks, Alex Am 02.08.2011 um 06:11 schrieb Alan McNatty: Sorry that should be ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE. Index: gw/smsc/smsc_smpp.c === --- gw/smsc/smsc_smpp.c (revision 4913) +++ gw/smsc/smsc_smpp.c (working copy) @@ -876,7 +876,7 @@ * set the esm_class field * default is store and forward, plus udh and rpi if requested */ -pdu-u.submit_sm.esm_class = ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE; +pdu-u.submit_sm.esm_class = ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE; if (octstr_len(msg-sms.udhdata)) pdu-u.submit_sm.esm_class = pdu-u.submit_sm.esm_class | ESM_CLASS_SUBMIT_UDH_INDICATOR; On Tue, 2011-08-02 at 15:59 +1200, Alan McNatty wrote: Hi Nikos, You mean simply change the default: Index: gw/smsc/smsc_smpp.c === --- gw/smsc/smsc_smpp.c (revision 4913) +++ gw/smsc/smsc_smpp.c (working copy) @@ -876,7 +876,7 @@ * set the esm_class field * default is store and forward, plus udh and rpi if requested */ -pdu-u.submit_sm.esm_class
Re: Patch: wtls userguide
Hi Alex, I corrected everything by the eye using the docbook dtd and your error reporting. I fixed all the errors in your report. It seems to me valid by the dtd, however, I don't know how it looks (nested ordered lists). I was not able to validate, since a docbook validator would seriously change my environment. BR, Nikos On Sat, Aug 6, 2011 at 12:03 AM, Nikos Balkanas nbalka...@gmail.com wrote: My apologies for that. It is very difficult to build a docbook environment in Solaris. I have already fixed manually one problem in nested lists from the dtd, and have downloaded some docbook viewers for windows. As soon as i get the (free) licenses for them and verify the patch, I will submit again. BR, Nikos On Fri, Aug 5, 2011 at 11:52 AM, Alexander Malysh amal...@kannel.orgwrote: Hi Nikos, could you please check your patch because it produce errors: jade:doc/userguide/userguide.tmp:2253:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2253:31:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2254:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2254:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2255:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2255:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2256:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2256:37:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2257:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2257:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2258:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2258:32:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2259:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2259:37:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2263:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2263:36:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2268:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2268:36:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2269:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2269:36:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2270:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2270:33:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2271:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2271:33:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2272:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2272:36:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2276:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2276:35:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2277:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2277:44:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2278:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2278:37:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2279:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2279:37:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2280:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2280:34:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2285:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2285:34:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2289:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2289:38:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2290:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2290:38:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2291:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2291:37:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2292:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2292:33:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2293:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2293:33:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2294:16
Re: Patch: wtls userguide
/userguide.tmp:2296:39:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2297:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2297:44:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2306:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2306:53:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2307:16:E: character data is not allowed here jade:doc/userguide/userguide.tmp:2309:53:E: end tag for LISTITEM which is not finished jade:doc/userguide/userguide.tmp:2363:7:E: end tag for TBODY omitted, but OMITTAG NO was specified jade:doc/userguide/userguide.tmp:2339:2: start tag was here jade:doc/userguide/userguide.tmp:2363:7:E: end tag for TGROUP omitted, but OMITTAG NO was specified jade:doc/userguide/userguide.tmp:2331:2: start tag was here jade:doc/userguide/userguide.tmp:2363:7:E: end tag for TABLE omitted, but OMITTAG NO was specified jade:doc/userguide/userguide.tmp:2329:1: start tag was here make: *** [doc/userguide/userguide.html] Error 1 Am 02.08.2011 um 21:15 schrieb Nikos Balkanas: Gladly, here you go ;-) Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Kannel Devel de...@vm1.kannel.org Sent: Tuesday, August 02, 2011 12:31 PM Subject: Re: Patch: wtls userguide Hi Nikos, sorry I missed this patch. Could you please resend? Thanks, Alex Am 31.07.2011 um 00:13 schrieb Nikos Balkanas: Hi Alex, Any news? Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Alexander Malysh amal...@kannel.org Cc: devel@kannel.org; Armindo Antunes armindo.antu...@gmail.com Sent: Friday, July 22, 2011 3:37 PM Subject: Re: Patch: wtls userguide Hi, This is an update. Forgot listing of supported ciphers. Maybe it should go to an Appendix. What do you think? BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Alexander Malysh amal...@kannel.org Cc: devel@kannel.org; Armindo Antunes armindo.antu...@gmail.com Sent: Friday, July 22, 2011 12:39 AM Subject: Patch: wtls userguide Hi Alex, A long overdue wtls section for the userguide. Adds another section for wtls and another Appendix for certificate generation. BR, Nikos userguide.diff
Re: Patch: wtls userguide
Gladly, here you go ;-) Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Kannel Devel de...@vm1.kannel.org Sent: Tuesday, August 02, 2011 12:31 PM Subject: Re: Patch: wtls userguide Hi Nikos, sorry I missed this patch. Could you please resend? Thanks, Alex Am 31.07.2011 um 00:13 schrieb Nikos Balkanas: Hi Alex, Any news? Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Alexander Malysh amal...@kannel.org Cc: devel@kannel.org; Armindo Antunes armindo.antu...@gmail.com Sent: Friday, July 22, 2011 3:37 PM Subject: Re: Patch: wtls userguide Hi, This is an update. Forgot listing of supported ciphers. Maybe it should go to an Appendix. What do you think? BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Alexander Malysh amal...@kannel.org Cc: devel@kannel.org; Armindo Antunes armindo.antu...@gmail.com Sent: Friday, July 22, 2011 12:39 AM Subject: Patch: wtls userguide Hi Alex, A long overdue wtls section for the userguide. Adds another section for wtls and another Appendix for certificate generation. BR, Nikos userguide.diff Description: Binary data
Patch: wap/wtls_statesupport.c
Hi Alex, This is a small patch to wtls. Fixes a problem with debug log output when large MAC names are used. Credits for both the patch and the bug go to Armindo Antunes, armindo.antu...@gmail.com. BR, Nikos wtls_statesupport.diff Description: Binary data
Re: Making SMPP esm_class configurable?
Hi Alan, According to the spec SMPP 5.0, p 125, ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE is the default esm class. That part should be patched in. As far as making it configurable, I have no objections to it. A few people over the years have had to manually patch it in. BR, Nikos - Original Message - From: Alan McNatty a...@catalyst.net.nz To: devel@kannel.org Sent: Monday, August 01, 2011 6:21 AM Subject: Making SMPP esm_class configurable? Hi All, I found a thread on this from back in Feb 2005 (having received a query from provided now myself) .. last word by Alejandro and a lukewarm (+0 - +1) comment from Stipe about committing if patch provided. I would provide a config patch if anyone would vote in it's favour? Consider: gw/smsc/smsc_smpp.c 875 /* 876 * set the esm_class field 877 * default is store and forward, plus udh and rpi if requested 878 */ 879 pdu-u.submit_sm.esm_class = ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE; But the 'default' is surely ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE, no? Cheers, Alan
Re: Patch: wtls userguide
Hi Alex, Any news? Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Alexander Malysh amal...@kannel.org Cc: devel@kannel.org; Armindo Antunes armindo.antu...@gmail.com Sent: Friday, July 22, 2011 3:37 PM Subject: Re: Patch: wtls userguide Hi, This is an update. Forgot listing of supported ciphers. Maybe it should go to an Appendix. What do you think? BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Alexander Malysh amal...@kannel.org Cc: devel@kannel.org; Armindo Antunes armindo.antu...@gmail.com Sent: Friday, July 22, 2011 12:39 AM Subject: Patch: wtls userguide Hi Alex, A long overdue wtls section for the userguide. Adds another section for wtls and another Appendix for certificate generation. BR, Nikos
Re: Kannel 1.5.0 compilation
Hi Alex,
Thanks for the fast response.
Solaris 10 has both /usr/include/syslog.h and /usr/include/sys/syslog.h,
where it defines constants. This is update 8, which is very recent. However,
as in some of the other include files, there are some discrepancies, and
CODE is missing. Now Solaris has System V stewardship, while Linux is based
more on BSD.
Solaris defines syslog.h as:
#define _SYSLOG_H
Therefore your patch will take out all syslog.h definitions in Solaris,
which is an overkill, since syslog worked fine in Solaris before CODE.
I would suggest, that it is handled in the configuration script and
gw-config.h like the discrepancy in gethostbyname. It would be a much
simpler patch, just to define there CODE if it is not defined.
BR,
Nikos
- Original Message -
From: Alexander Malysh amal...@kannel.org
To: Nikos Balkanas nbalka...@gmail.com
Cc: de...@vm1.kannel.org
Sent: Saturday, July 23, 2011 1:08 PM
Subject: Re: Kannel 1.5.0 compilation
Hi,
CODE is defined in syslog.h. Does Solaris don't have syslog.h?
Please try attached patch.
Thanks,
Alex
Am 22.07.2011 um 21:29 schrieb Nikos Balkanas:
Hi,
I am getting this trying to build latest kannel svn in Solaris:
gwlib/log.c:155: error: syntax error before CODE
gwlib/log.c:155:
/*
* Decode the syslog name to its int value
*/
static int decode(char *name, CODE *facilities)
{
register CODE *c;
Where is this CODE defined? Couldn't find it anywhere in kannel sources
and is not a C primitive type. Is it a Linux thingie?
BR,
Nikos
Re: Kannel 1.5.0 compilation
Hi,
Actually you already applied the patch to the svn, so it still has problems:
HAVE_SYSLOG is defined from configuration for Solaris.
Additionally there is no SYSLOG_NAMES defined in Solaris headers.
So apart from CODE you would need facilitynames as well. And not all
constants defined in facilitynames in Linux are defined in Solaris.
Therefore my suggestion for a simple fix will not work.
By #undef HAVE_SYSLOG in gwlib/log.c, everything compiles clean. So
configuration needs to be fixed as well at this point. This means that
syslog fucntionality that used to work in Solaris, is not any more, and
possibly other *nix OSs as well. I think that qualifies it as a broken
feature.
Let me know if you need any extra input from Solaris,
Nikos
- Original Message -
From: Nikos Balkanas nbalka...@gmail.com
To: Alexander Malysh amal...@kannel.org
Cc: devel@kannel.org
Sent: Saturday, July 23, 2011 4:04 PM
Subject: Re: Kannel 1.5.0 compilation
Hi Alex,
Thanks for the fast response.
Solaris 10 has both /usr/include/syslog.h and /usr/include/sys/syslog.h,
where it defines constants. This is update 8, which is very recent.
However, as in some of the other include files, there are some
discrepancies, and CODE is missing. Now Solaris has System V stewardship,
while Linux is based more on BSD.
Solaris defines syslog.h as:
#define _SYSLOG_H
Therefore your patch will take out all syslog.h definitions in Solaris,
which is an overkill, since syslog worked fine in Solaris before CODE.
I would suggest, that it is handled in the configuration script and
gw-config.h like the discrepancy in gethostbyname. It would be a much
simpler patch, just to define there CODE if it is not defined.
BR,
Nikos
- Original Message -
From: Alexander Malysh amal...@kannel.org
To: Nikos Balkanas nbalka...@gmail.com
Cc: de...@vm1.kannel.org
Sent: Saturday, July 23, 2011 1:08 PM
Subject: Re: Kannel 1.5.0 compilation
Hi,
CODE is defined in syslog.h. Does Solaris don't have syslog.h?
Please try attached patch.
Thanks,
Alex
Am 22.07.2011 um 21:29 schrieb Nikos Balkanas:
Hi,
I am getting this trying to build latest kannel svn in Solaris:
gwlib/log.c:155: error: syntax error before CODE
gwlib/log.c:155:
/*
* Decode the syslog name to its int value
*/
static int decode(char *name, CODE *facilities)
{
register CODE *c;
Where is this CODE defined? Couldn't find it anywhere in kannel sources
and is not a C primitive type. Is it a Linux thingie?
BR,
Nikos
Re: Patch: wtls userguide
Hi, This is an update. Forgot listing of supported ciphers. Maybe it should go to an Appendix. What do you think? BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Alexander Malysh amal...@kannel.org Cc: devel@kannel.org; Armindo Antunes armindo.antu...@gmail.com Sent: Friday, July 22, 2011 12:39 AM Subject: Patch: wtls userguide Hi Alex, A long overdue wtls section for the userguide. Adds another section for wtls and another Appendix for certificate generation. BR, Nikos userguide.diff Description: Binary data
Kannel 1.5.0 compilation
Hi,
I am getting this trying to build latest kannel svn in Solaris:
gwlib/log.c:155: error: syntax error before CODE
gwlib/log.c:155:
/*
* Decode the syslog name to its int value
*/
static int decode(char *name, CODE *facilities)
{
register CODE *c;
Where is this CODE defined? Couldn't find it anywhere in kannel sources and
is not a C primitive type. Is it a Linux thingie?
BR,
Nikos
Patch: wtls userguide
Hi Alex, A long overdue wtls section for the userguide. Adds another section for wtls and another Appendix for certificate generation. BR, Nikos userguide.diff Description: Binary data
Re: receiving incoming messages
Hi Please do not use devel for such questions,. Use users. BR, Nikos - Original Message - From: Amirali Shambayati amirali.shambay...@gmail.com To: devel@kannel.org Sent: Saturday, May 21, 2011 1:25 PM Subject: receiving incoming messages Hello all, I use following configuration to run kannel. I don't have any problem about sending sms using kannel, but I can't send message from a mobile to kannel. Any help is appreciated. group = core admin-port = 13000 smsbox-port = 13001 admin-password = bar log-file = /tmp/kannel.log #log-level = 0 box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 dlr-storage = mysql group = mysql-connection id = sqlbox-db host = localhost username = root password = 89117 database = mysql # max count of connections that will be opened for dbpool #default is 1 #max-connections = 1 group = dlr-db id = sqlbox-db table = dlr field-smsc = smsc field-timestamp = ts field-destination = destination field-source = source field-service = service field-url = url field-mask = mask field-status = status field-boxc-id = boxc group = smsc smsc = at modemtype = auto device=/dev/ttyACM0 #my-number = 899811270077051 my-number = 09367913772 connect-allow-ip = 127.0.0.1 log-level = 0 group = smsbox bearerbox-host = 127.0.0.1 bearerbox-port=13003 sendsms-port = 13013 #global-sender = 899811270077051 global-sender = 09367913772 log-level = 0 group = sendsms-user username = kanneluser password = mypassword concatenation= true max-messages = 10 group = sms-service keyword = default text=salam #keyword-regex = .* catch-all = true max-messages = 1 #get-url = http://localhost/sms?phone=%ptext=%a; # If modemtype=auto, try everyone and defaults to this one group = modems id = generic name = Generic Modem group = modems id = wavecom name = Wavecom detect-string = WAVECOM group = modems id = premicell name = Premicell detect-string = PREMICEL no-pin = true no-smsc = true group = modems id = siemens_tc35 name = Siemens TC35 detect-string = SIEMENS detect-string2 = TC35 init-string = AT+CNMI=1,2,0,1,1 speed = 19200 enable-hwhs = AT\\Q3 need-sleep = true group = modems id = siemens_m20 name = Siemens M20 detect-string = SIEMENS detect-string2 = M20 speed = 19200 enable-hwhs = AT\\Q3 keepalive-cmd = AT+CBC;+CSQ need-sleep = true group = modems id = siemens_sl45 name = Siemens SL45 detect-string = SIEMENS detect-string2 = SL45 init-string = AT+CNMI=1,2,2,2,1 keepalive-cmd = AT+CBC;+CSQ speed = 19200 enable-hwhs = AT\\Q3 need-sleep = true message-storage = SM group = modems id = nokia name = Nokia N81 detect-string = Nokia init-string =ATZ init-string =ATQ0 V1 E1 S0=0 C1 D2 + FCLASS=0 group = modems id = nokiaphone name = Nokia Phone detect-string = Nokia Mobile Phone need-sleep = true keepalive-cmd = AT+CBC;+CSQ enable-mms = true group = modems id = falcom name = Falcom detect-string = Falcom no-smsc = true group = modems id = ericsson_r520m name = Ericsson R520m detect-string = R520m init-string = AT+CNMI=3,2,0,0 group = modems id = ericsson_t68 name = Ericsson T68 detect-string = T68 init-string = AT+CNMI=3,3 keepalive-cmd = AT+CBC;+CSQ broken = true group = modems id = alcatel name = Alcatel detect-string = Alcatel init-string = AT+CNMI=3,2,0,0 group = smsc smsc = fake port = 1 -- Amirali Shambayati Bachelor Student Computer Engineering Department Sharif University of Technology Tehran, Iran
Re: devel Digest, Vol 57, Issue 14
Hi, Please don't use sevel for such questions. Use users list. BR, Nikos - Original Message - From: Rajendra Pondel neosta...@gmail.com To: devel@kannel.org Sent: Saturday, May 21, 2011 2:42 PM Subject: Re: devel Digest, Vol 57, Issue 14 Hello there. I have problem for u guys. Can u solve the following problem? Consider following scenario: There are three persons, named A, B and C. A's mobile no is M, B's no is N and C's no is P. The C is GSM/GPRS modem and is connected to pc/Server . B has forwarded all its voice calls to C. Now, A (call originator) calls to B (call forwarder), call gets forwarded to C (call terminated). Here, C is connected to pc/server, how do I extract call details using at commands? I want following details to be extracted. 1. the main call originating number (ie, from where call originated, not from where is forwarded, ie A's no what is M) 2. the number from where call got forwarded (ie, from where call forwarded from, ie, B's no N ) So, can any one tell me how do i achieve that using AT commands or any other way? Regards - Rajendra Pondel http://www.vakow.net On 5/21/11, devel-requ...@kannel.org devel-requ...@kannel.org wrote: Send devel mailing list submissions to devel@kannel.org To subscribe or unsubscribe via the World Wide Web, visit http://www.kannel.org/mailman/listinfo/devel or, via email, send a message with subject or body 'help' to devel-requ...@kannel.org You can reach the person managing the list at devel-ow...@kannel.org When replying, please edit your Subject line so it is more specific than Re: Contents of devel digest... Today's Topics: 1. Re: [PATCH] Throttling support for AT smsc (Alexander Malysh) -- Message: 1 Date: Fri, 20 May 2011 20:16:40 +0200 From: Alexander Malysh amal...@kannel.org To: v.chava...@telemaque.fr Cc: devel@kannel.org devel@kannel.org Subject: Re: [PATCH] Throttling support for AT smsc Message-ID: 26058399-0d6c-47e0-a84b-05754b61c...@kannel.org Content-Type: text/plain; charset=iso-8859-1 Hi Vincent, this is very easy: a) if you sleep for throughput you don't receive any MOs b) if you have something to send, this thread will be waked up any time and therefore there is no throughput garantee if you use load_XXX then all these issues can be avoided. Alex Am 19.05.2011 um 13:04 schrieb Vincent CHAVANIS: Hi Alex, AT commands are synchronous and there is only one thread for sending and receving messages Why should i implement the load_XX function to do the trick ? (there is no need here to modify the PrivAT2data structure) Vincent Le 18/05/2011 20:50, Alexander Malysh a ?crit : Hi, why don't you use load_XX support? See smsc_smpp as example. With only sleep thread will wakeup if new messages available for sending and therefore you don't guarantee throughput. Alex Am 18.05.2011 um 14:48 schrieb Vincent CHAVANIS: Hi all, Here is a small patch to support throttling on AT smsc Any comment ? regards Vincent. smsc_at_throttling.txt -- ___ devel mailing list devel@kannel.org http://www.kannel.org/mailman/listinfo/devel End of devel Digest, Vol 57, Issue 14 *
Re: [PATCH] handling of non-latin GSM subset in opensmppbox
Hi Rene, In my previous comment I said that making alt_charset is not necessary since by using a full iso and decoding with the same one, it would yield the original without errors, although it would be preferable to make it configurable. It turns out that not doing so, it would contradict kannel architecture. In such a content bearerbox, doesn't try simply to recover original charset, rather with alt_charset it tries to convert it to a new charset compatible with the smsc. therefore it is necessary to make it configurable. Since the list of features/client connection should be epandable, I would recommend skipping the text file alltogether and instead create a new configuration group, ie: group = client ... PS: Charset code was lift off gw/smsc/smsc_smpp.c. It needs to be converted to UTF-8 as well. BR, Nikos - Original Message - From: Rene Kluwen To: 'Nii Ako Ampa-Sowa' ; devel@kannel.org Sent: Monday, May 09, 2011 1:39 AM Subject: RE: [PATCH] handling of non-latin GSM subset in opensmppbox Patch committed. Current revision of opensmppbox is 61. Still todo: Make a configuration entry for alt-charset. Even though it is not really necessary at the moment. Log line: 2011-05-09 Rene Kluwen rene.kluwen at chimit.nl * gw/opensmppbox.c: Default GSM character set is converted to UTF-8 (Kannel's internal way of exchanging messages). The facilitates foreign (e.g. greek) characters. Thanks to Nii Ako Ampa-Sowa (ampasowa at gmail.com) for the patch. == Rene From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Nii Ako Ampa-Sowa Sent: Friday, 06 May, 2011 23:04 To: devel@kannel.org Subject: [PATCH] handling of non-latin GSM subset in opensmppbox Hi, opensmppbox doesn't seem to handle the non-Latin subset of the GSM character set very well. This affects the Euro sign as well as Greek characters. Attached is a patch that switches from using the Latin1 conversion routine to the UTF-8 version. Nii
Re: [PATCH] handling of non-latin GSM subset in opensmppbox
Yes, but that is only half the story. What about if the input is not GSM, but an iso-*? Shouldn't it be converted to UTF-8, too? The standard also for UCS-2 is UTF-16BE, not left as is. BR, Nikos - Original Message - From: Rene Kluwen To: 'Nii Ako Ampa-Sowa' ; devel@kannel.org Sent: Saturday, May 07, 2011 5:16 PM Subject: RE: [PATCH] handling of non-latin GSM subset in opensmppbox I think this patch makes sense. It’s an internal coding anyway… and it should be utf-8 instead of latin1. If nobody objects, I will commit during the week. == Rene From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Nii Ako Ampa-Sowa Sent: Friday, 06 May, 2011 23:04 To: devel@kannel.org Subject: [PATCH] handling of non-latin GSM subset in opensmppbox Hi, opensmppbox doesn't seem to handle the non-Latin subset of the GSM character set very well. This affects the Euro sign as well as Greek characters. Attached is a patch that switches from using the Latin1 conversion routine to the UTF-8 version. Nii
Re: [PATCH] handling of non-latin GSM subset in opensmppbox
Registered data_coding values for SMPP are: Bits 7 6 5 4 3 2 1 0 Meaning Notes 0 0 0 0 0 0 0 0 SMSC Default Alphabet 0 0 0 0 0 0 0 1 IA5 (CCITT T.50)/ASCII (ANSI X3.4) b 0 0 0 0 0 0 1 0 Octet unspecified (8-bit binary) b 0 0 0 0 0 0 1 1 Latin 1 (ISO-8859-1) b 0 0 0 0 0 1 0 0 Octet unspecified (8-bit binary) a 0 0 0 0 0 1 0 1 JIS (X 0208-1990) b 0 0 0 0 0 1 1 0 Cyrllic (ISO-8859-5) b 0 0 0 0 0 1 1 1 Latin/Hebrew (ISO-8859-8) b 0 0 0 0 1 0 0 0 UCS2 (ISO/IEC-10646) a 0 0 0 0 1 0 0 1 Pictogram Encoding b 0 0 0 0 1 0 1 0 ISO-2022-JP (Music Codes) b 0 0 0 0 1 0 1 1 reserved 0 0 0 0 1 1 0 0 reserved 0 0 0 0 1 1 0 1 Extended Kanji JIS(X 0212-1990) b 0 0 0 0 1 1 1 0 KS C 5601 b 0 0 0 0 1 1 1 1 reserved 1 0 1 1 1 1 1 1 reserved 1 1 0 0 x x x x GSM MWI control - see [GSM 03.38] d 1 1 0 1 x x x x GSM MWI control - see [GSM 03.38] d 1 1 1 0 x x x x reserved 1 1 1 1 x x x x GSM message class control - see [GSM 03.38] e With default data_coding (0) you could have a slew of charsets. That's the only way to pass iso-8859-7 (Greek). GSM and UCS2 should be determined from their values. But between the different iso flavors, it is impossible. It would probably be better to be configurable per ESME connection, but it doesn't need to be so. If the wrong iso is assumed, as long as the alt-charset in bearerbox is the same, it will be deconverted correctly, even if the intermediate UTF-8 is wrong. Of course, a full-spectrum iso like iso-8859-4 should be chosen, that contains all iso values. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Rene Kluwen' rene.klu...@chimit.nl; 'Nikos Balkanas' nbalka...@gmail.com; 'Nii Ako Ampa-Sowa' ampas...@gmail.com; de...@vm1.kannel.org Sent: Sunday, May 08, 2011 2:09 AM Subject: RE: [PATCH] handling of non-latin GSM subset in opensmppbox Oops... Nikos... I replied on a wrong thread. This was not about sqlbox. My real question: What type of charset do the SMPP specs dictate? Do you think in opensmppbox there should be a configuration value that indicates a charset? == Rene -Original Message- From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Sunday, 08 May, 2011 01:07 To: 'Nikos Balkanas'; 'Nii Ako Ampa-Sowa'; 'de...@vm1.kannel.org' Subject: RE: [PATCH] handling of non-latin GSM subset in opensmppbox It's what I thought also. There is a charset field in the send_sms table. Nikos, do you think that one should be accordingly? == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Sunday, 08 May, 2011 01:02 To: Rene Kluwen; 'Nii Ako Ampa-Sowa'; de...@vm1.kannel.org Subject: Re: [PATCH] handling of non-latin GSM subset in opensmppbox Yes, but that is only half the story. What about if the input is not GSM, but an iso-*? Shouldn't it be converted to UTF-8, too? The standard also for UCS-2 is UTF-16BE, not left as is. BR, Nikos - Original Message - From: Rene Kluwen To: 'Nii Ako Ampa-Sowa' ; devel@kannel.org Sent: Saturday, May 07, 2011 5:16 PM Subject: RE: [PATCH] handling of non-latin GSM subset in opensmppbox I think this patch makes sense. It's an internal coding anyway. and it should be utf-8 instead of latin1. If nobody objects, I will commit during the week. == Rene From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Nii Ako Ampa-Sowa Sent: Friday, 06 May, 2011 23:04 To: devel@kannel.org Subject: [PATCH] handling of non-latin GSM subset in opensmppbox Hi, opensmppbox doesn't seem to handle the non-Latin subset of the GSM character set very well. This affects the Euro sign as well as Greek characters. Attached is a patch that switches from using the Latin1 conversion routine to the UTF-8 version. Nii
Re: [PATCH] handling of non-latin GSM subset in opensmppbox
That could also be the issue that Mike is facing with sqlbox Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: 'Rene Kluwen' rene.klu...@chimit.nl; 'Nii Ako Ampa-Sowa' ampas...@gmail.com; de...@vm1.kannel.org Sent: Sunday, May 08, 2011 2:32 AM Subject: Re: [PATCH] handling of non-latin GSM subset in opensmppbox Registered data_coding values for SMPP are: Bits 7 6 5 4 3 2 1 0 Meaning Notes 0 0 0 0 0 0 0 0 SMSC Default Alphabet 0 0 0 0 0 0 0 1 IA5 (CCITT T.50)/ASCII (ANSI X3.4) b 0 0 0 0 0 0 1 0 Octet unspecified (8-bit binary) b 0 0 0 0 0 0 1 1 Latin 1 (ISO-8859-1) b 0 0 0 0 0 1 0 0 Octet unspecified (8-bit binary) a 0 0 0 0 0 1 0 1 JIS (X 0208-1990) b 0 0 0 0 0 1 1 0 Cyrllic (ISO-8859-5) b 0 0 0 0 0 1 1 1 Latin/Hebrew (ISO-8859-8) b 0 0 0 0 1 0 0 0 UCS2 (ISO/IEC-10646) a 0 0 0 0 1 0 0 1 Pictogram Encoding b 0 0 0 0 1 0 1 0 ISO-2022-JP (Music Codes) b 0 0 0 0 1 0 1 1 reserved 0 0 0 0 1 1 0 0 reserved 0 0 0 0 1 1 0 1 Extended Kanji JIS(X 0212-1990) b 0 0 0 0 1 1 1 0 KS C 5601 b 0 0 0 0 1 1 1 1 reserved 1 0 1 1 1 1 1 1 reserved 1 1 0 0 x x x x GSM MWI control - see [GSM 03.38] d 1 1 0 1 x x x x GSM MWI control - see [GSM 03.38] d 1 1 1 0 x x x x reserved 1 1 1 1 x x x x GSM message class control - see [GSM 03.38] e With default data_coding (0) you could have a slew of charsets. That's the only way to pass iso-8859-7 (Greek). GSM and UCS2 should be determined from their values. But between the different iso flavors, it is impossible. It would probably be better to be configurable per ESME connection, but it doesn't need to be so. If the wrong iso is assumed, as long as the alt-charset in bearerbox is the same, it will be deconverted correctly, even if the intermediate UTF-8 is wrong. Of course, a full-spectrum iso like iso-8859-4 should be chosen, that contains all iso values. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Rene Kluwen' rene.klu...@chimit.nl; 'Nikos Balkanas' nbalka...@gmail.com; 'Nii Ako Ampa-Sowa' ampas...@gmail.com; de...@vm1.kannel.org Sent: Sunday, May 08, 2011 2:09 AM Subject: RE: [PATCH] handling of non-latin GSM subset in opensmppbox Oops... Nikos... I replied on a wrong thread. This was not about sqlbox. My real question: What type of charset do the SMPP specs dictate? Do you think in opensmppbox there should be a configuration value that indicates a charset? == Rene -Original Message- From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Sunday, 08 May, 2011 01:07 To: 'Nikos Balkanas'; 'Nii Ako Ampa-Sowa'; 'de...@vm1.kannel.org' Subject: RE: [PATCH] handling of non-latin GSM subset in opensmppbox It's what I thought also. There is a charset field in the send_sms table. Nikos, do you think that one should be accordingly? == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Sunday, 08 May, 2011 01:02 To: Rene Kluwen; 'Nii Ako Ampa-Sowa'; de...@vm1.kannel.org Subject: Re: [PATCH] handling of non-latin GSM subset in opensmppbox Yes, but that is only half the story. What about if the input is not GSM, but an iso-*? Shouldn't it be converted to UTF-8, too? The standard also for UCS-2 is UTF-16BE, not left as is. BR, Nikos - Original Message - From: Rene Kluwen To: 'Nii Ako Ampa-Sowa' ; devel@kannel.org Sent: Saturday, May 07, 2011 5:16 PM Subject: RE: [PATCH] handling of non-latin GSM subset in opensmppbox I think this patch makes sense. It's an internal coding anyway. and it should be utf-8 instead of latin1. If nobody objects, I will commit during the week. == Rene From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Nii Ako Ampa-Sowa Sent: Friday, 06 May, 2011 23:04 To: devel@kannel.org Subject: [PATCH] handling of non-latin GSM subset in opensmppbox Hi, opensmppbox doesn't seem to handle the non-Latin subset of the GSM character set very well. This affects the Euro sign as well as Greek characters. Attached is a patch that switches from using the Latin1 conversion routine to the UTF-8 version. Nii
Re: Test SMS Delivery Reports with fakesmsc
Hi, Do not use devel list for usage questions. Use only users list. Nikos - Original Message - From: ha nguyen viet To: devel@kannel.org Sent: Tuesday, April 26, 2011 6:28 AM Subject: Test SMS Delivery Reports with fakesmsc Hi all, i'm not good with english so please kind to me. Throught this chapter 9 in kannel user's guide, i want to test sms delivery reports with fakesmsc. In group sendsms-user , i configure dlr-url = http://192.168.1.40/status.php?id=%pmask=%d. in url to send sms i add dlr-mask = 31 (all kind of report) I want to know what d value in the report, status.php get %p and %d from kannel but i only take the value 1(delivery success) or 8(smsc submit). i try to test the case which value d = 2(delivery failure) or 4(message buffered) but i can't. Can anyone tell me the example of testing fakesmsc delivery reports with d value is 2 or 4?
Re: useful patches for everyone
If you don't want to use it just ignore it completely, the default behavior if the directive is missing is to start the smsc at boot as usual, so no harm's done. This is not the issue. I still have (along with many others) to know about it in order to support it for users that ask (or not) about it. This feature by itself is not that much, but cluttering configuration with non-essential conveniences will add up to make configuration much more difficult to support than now. BR, Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Juan Nin jua...@gmail.com; Kannel Devel de...@vm1.kannel.org Sent: Tuesday, April 19, 2011 11:49 AM Subject: Re: useful patches for everyone For KISS's sake, this doesn't clutter configuration nor breaks backwards compatibility. It doesn't hurt performance either. If you don't want to use it just ignore it completely, the default behavior if the directive is missing is to start the smsc at boot as usual, so no harm's done. Where do we trace the absolutely necessary line is of course fuzzy, but from what I read seems like other users would find it useful as well. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 19/04/2011, at 05:19, Nikos Balkanas wrote: Hi, wapbox must be kept around because of backwards compatibility, that is a must for all open source software. Users are still using it. Finally I would like to add my support for keeping configuration explosion in check. Otherwise, what a few people might gain in convenience, a lot of people might have to pay for it in terms of kannel support due to more difficult configuration. Some golden rules in configuration are: 1) KISS 2) Don't expand it, unless it is absolutely necessary. Stopping service to modify configuration is a no-no. Commenting a configuration file off-line is convenience. My 2 cents, Nikos - Original Message - From: Juan Nin To: Kannel Devel Sent: Tuesday, April 19, 2011 4:41 AM Subject: Re: useful patches for everyone That's what we do today, but the idea is not to have to do any extra work, neither having to comment/uncomment things out, nor have to add/remove config files. Having the start-at-boot directive allows you to just keep the configuration defined, but the smsc does not start. So anytime you need it, you just use the start-smsc and then the stop-smsc. This is much cleaner IMHO than having to do all the extra manual work, no matter how easy that manual work it may be. A similar discussion was held some months ago, can't remember what new directive it was, where the directive was finally added, since it was seen it was helpful. Not all directives are used by everyone or may be useful for everybody, that happens on any piece of software, but does not mean it's not useful, nor that it should not be added. I don't care about the WAP related parts of Kannel for example, and that doesn't mean I believe they should not exist. Adding useful things to Kannel is something that makes Kannel a better product, so I don't really see why not to add it. Maybe if it was something complicated that really messed up with the code, could be, but this is definitely not the case. Just my 2 cents. 2011/4/18 Nikos Balkanas nbalka...@gmail.com What about the HTTP command start-smsc: It reloads the smsc and starts them from configuration. Therefore you could have the smsc commented out at start, then enable it in the configuration and start it from the web interface, without stooping kannel. Is that not adequate? BR, Nikos - Original Message - From: Thomas Gottgens tho...@ist.schuldig.de To: Alvaro Cornejo cornejo.alv...@gmail.com Cc: Alexander Malysh amal...@vm1.kannel.org; Kannel Devel de...@vm1.kannel.org Sent: Monday, April 18, 2011 11:24 PM Subject: Re: useful patches for everyone Hello, i second that. Having the ability to start kannel with some of the binds down is so much easier in HA/Failover environments. Monday, April 18, 2011, 8:31:05 PM, you wrote: AC Hi Alex AC Another use would be when having backup links. I do use over 20 modems AC but not have all enabled at start. In order to not to have to reload AC kannel when a new modem is needed, I do start kannel and then stop all AC the backup modems and I have to do the same whenever I restart kannel AC or the server AC I'll love to have this feature in standard kannel -- Best regards, Thomasmailto:tho...@ist.schuldig.de
Re: useful patches for everyone
I sure will do. But you are not helping out... Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Kannel Devel de...@vm1.kannel.org Sent: Tuesday, April 19, 2011 12:21 PM Subject: Re: useful patches for everyone I think you'll survive ;) -- Alejandro Guerrieri aguerri...@kannel.org On 19/04/2011, at 11:12, Nikos Balkanas wrote: If you don't want to use it just ignore it completely, the default behavior if the directive is missing is to start the smsc at boot as usual, so no harm's done. This is not the issue. I still have (along with many others) to know about it in order to support it for users that ask (or not) about it. This feature by itself is not that much, but cluttering configuration with non-essential conveniences will add up to make configuration much more difficult to support than now. BR, Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Juan Nin jua...@gmail.com; Kannel Devel de...@vm1.kannel.org Sent: Tuesday, April 19, 2011 11:49 AM Subject: Re: useful patches for everyone For KISS's sake, this doesn't clutter configuration nor breaks backwards compatibility. It doesn't hurt performance either. If you don't want to use it just ignore it completely, the default behavior if the directive is missing is to start the smsc at boot as usual, so no harm's done. Where do we trace the absolutely necessary line is of course fuzzy, but from what I read seems like other users would find it useful as well. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 19/04/2011, at 05:19, Nikos Balkanas wrote: Hi, wapbox must be kept around because of backwards compatibility, that is a must for all open source software. Users are still using it. Finally I would like to add my support for keeping configuration explosion in check. Otherwise, what a few people might gain in convenience, a lot of people might have to pay for it in terms of kannel support due to more difficult configuration. Some golden rules in configuration are: 1) KISS 2) Don't expand it, unless it is absolutely necessary. Stopping service to modify configuration is a no-no. Commenting a configuration file off-line is convenience. My 2 cents, Nikos - Original Message - From: Juan Nin To: Kannel Devel Sent: Tuesday, April 19, 2011 4:41 AM Subject: Re: useful patches for everyone That's what we do today, but the idea is not to have to do any extra work, neither having to comment/uncomment things out, nor have to add/remove config files. Having the start-at-boot directive allows you to just keep the configuration defined, but the smsc does not start. So anytime you need it, you just use the start-smsc and then the stop-smsc. This is much cleaner IMHO than having to do all the extra manual work, no matter how easy that manual work it may be. A similar discussion was held some months ago, can't remember what new directive it was, where the directive was finally added, since it was seen it was helpful. Not all directives are used by everyone or may be useful for everybody, that happens on any piece of software, but does not mean it's not useful, nor that it should not be added. I don't care about the WAP related parts of Kannel for example, and that doesn't mean I believe they should not exist. Adding useful things to Kannel is something that makes Kannel a better product, so I don't really see why not to add it. Maybe if it was something complicated that really messed up with the code, could be, but this is definitely not the case. Just my 2 cents. 2011/4/18 Nikos Balkanas nbalka...@gmail.com What about the HTTP command start-smsc: It reloads the smsc and starts them from configuration. Therefore you could have the smsc commented out at start, then enable it in the configuration and start it from the web interface, without stooping kannel. Is that not adequate? BR, Nikos - Original Message - From: Thomas Gottgens tho...@ist.schuldig.de To: Alvaro Cornejo cornejo.alv...@gmail.com Cc: Alexander Malysh amal...@vm1.kannel.org; Kannel Devel de...@vm1.kannel.org Sent: Monday, April 18, 2011 11:24 PM Subject: Re: useful patches for everyone Hello, i second that. Having the ability to start kannel with some of the binds down is so much easier in HA/Failover environments. Monday, April 18, 2011, 8:31:05 PM, you wrote: AC Hi Alex AC Another use would be when having backup links. I do use over 20 modems AC but not have all enabled at start. In order to not to have to reload AC kannel when a new modem is needed, I do start kannel and then stop all AC the backup modems and I have to do the same whenever I restart kannel AC or the server AC I'll love to have this feature in standard kannel -- Best regards, Thomasmailto:tho...@ist.schuldig.de
Re: useful patches for everyone
start-smsc already reloads smsc configuration. Proposed patch doesn't. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Alexander Malysh' amal...@kannel.org; 'Alejandro Guerrieri' aguerri...@kannel.org Cc: 'Kannel Devel' de...@vm1.kannel.org Sent: Tuesday, April 19, 2011 3:11 PM Subject: RE: useful patches for everyone I am voting +1 also if this means an improvement and doesn't break compatibility. Reload configuration sounds an interesting next project ;). A lot of work though. == Rene -Original Message- From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Alexander Malysh Sent: Tuesday, 19 April, 2011 11:53 To: Alejandro Guerrieri Cc: Kannel Devel Subject: Re: useful patches for everyone Hi Alex, IMHO this option is not really needed and is only workaround about a fact that bearerbox is unable to reload configuration without restart. But reload is much bigger implementation as this simple hack. If this hack will help much people to do cleaner configuration now then I'm not voting against this feature. Alex, please update userguide and commit this patch if nobody has any objections. I'm +0 Thanks, Alexander Malysh Am 19.04.2011 um 10:49 schrieb Alejandro Guerrieri: For KISS's sake, this doesn't clutter configuration nor breaks backwards compatibility. It doesn't hurt performance either. If you don't want to use it just ignore it completely, the default behavior if the directive is missing is to start the smsc at boot as usual, so no harm's done. Where do we trace the absolutely necessary line is of course fuzzy, but from what I read seems like other users would find it useful as well. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 19/04/2011, at 05:19, Nikos Balkanas wrote: Hi, wapbox must be kept around because of backwards compatibility, that is a must for all open source software. Users are still using it. Finally I would like to add my support for keeping configuration explosion in check. Otherwise, what a few people might gain in convenience, a lot of people might have to pay for it in terms of kannel support due to more difficult configuration. Some golden rules in configuration are: 1) KISS 2) Don't expand it, unless it is absolutely necessary. Stopping service to modify configuration is a no-no. Commenting a configuration file off-line is convenience. My 2 cents, Nikos - Original Message - From: Juan Nin To: Kannel Devel Sent: Tuesday, April 19, 2011 4:41 AM Subject: Re: useful patches for everyone That's what we do today, but the idea is not to have to do any extra work, neither having to comment/uncomment things out, nor have to add/remove config files. Having the start-at-boot directive allows you to just keep the configuration defined, but the smsc does not start. So anytime you need it, you just use the start-smsc and then the stop-smsc. This is much cleaner IMHO than having to do all the extra manual work, no matter how easy that manual work it may be. A similar discussion was held some months ago, can't remember what new directive it was, where the directive was finally added, since it was seen it was helpful. Not all directives are used by everyone or may be useful for everybody, that happens on any piece of software, but does not mean it's not useful, nor that it should not be added. I don't care about the WAP related parts of Kannel for example, and that doesn't mean I believe they should not exist. Adding useful things to Kannel is something that makes Kannel a better product, so I don't really see why not to add it. Maybe if it was something complicated that really messed up with the code, could be, but this is definitely not the case. Just my 2 cents. 2011/4/18 Nikos Balkanas nbalka...@gmail.com What about the HTTP command start-smsc: It reloads the smsc and starts them from configuration. Therefore you could have the smsc commented out at start, then enable it in the configuration and start it from the web interface, without stooping kannel. Is that not adequate? BR, Nikos - Original Message - From: Thomas Gottgens tho...@ist.schuldig.de To: Alvaro Cornejo cornejo.alv...@gmail.com Cc: Alexander Malysh amal...@vm1.kannel.org; Kannel Devel de...@vm1.kannel.org Sent: Monday, April 18, 2011 11:24 PM Subject: Re: useful patches for everyone Hello, i second that. Having the ability to start kannel with some of the binds down is so much easier in HA/Failover environments. Monday, April 18, 2011, 8:31:05 PM, you wrote: AC Hi Alex AC Another use would be when having backup links. I do use over 20 modems AC but not have all enabled at start. In order to not to have to reload AC kannel when a new modem is needed, I do start kannel and then stop all AC the backup modems and I have to do the same whenever I restart kannel AC or the server AC I'll love to have this feature in standard kannel -- Best
Re: useful patches for everyone
For what concerns me, this discussion is a waste of time and it's over, you're not entitled to decide what's accepted and what's not anyway. I am not deciding anything, just voicing my oppinion like everyone else. It seems you can't handle it though. Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Kannel Devel de...@vm1.kannel.org Sent: Tuesday, April 19, 2011 12:49 PM Subject: Re: useful patches for everyone YOU are not helping out. I've collaborated a patch and many people voiced it would be useful. You're only trolling as you usually do, instead of doing something PRODUCTIVE for a change. For what concerns me, this discussion is a waste of time and it's over, you're not entitled to decide what's accepted and what's not anyway. Alex, Stipe, I voiced my point and other people agreed as well. It's your call either to include it or not, just let me know so I can write the user guide part. Otherwise, it'll remain available in my blog where interested parties could download it and apply it. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 19/04/2011, at 11:23, Nikos Balkanas wrote: I sure will do. But you are not helping out... Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Kannel Devel de...@vm1.kannel.org Sent: Tuesday, April 19, 2011 12:21 PM Subject: Re: useful patches for everyone I think you'll survive ;) -- Alejandro Guerrieri aguerri...@kannel.org On 19/04/2011, at 11:12, Nikos Balkanas wrote: If you don't want to use it just ignore it completely, the default behavior if the directive is missing is to start the smsc at boot as usual, so no harm's done. This is not the issue. I still have (along with many others) to know about it in order to support it for users that ask (or not) about it. This feature by itself is not that much, but cluttering configuration with non-essential conveniences will add up to make configuration much more difficult to support than now. BR, Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Juan Nin jua...@gmail.com; Kannel Devel de...@vm1.kannel.org Sent: Tuesday, April 19, 2011 11:49 AM Subject: Re: useful patches for everyone For KISS's sake, this doesn't clutter configuration nor breaks backwards compatibility. It doesn't hurt performance either. If you don't want to use it just ignore it completely, the default behavior if the directive is missing is to start the smsc at boot as usual, so no harm's done. Where do we trace the absolutely necessary line is of course fuzzy, but from what I read seems like other users would find it useful as well. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 19/04/2011, at 05:19, Nikos Balkanas wrote: Hi, wapbox must be kept around because of backwards compatibility, that is a must for all open source software. Users are still using it. Finally I would like to add my support for keeping configuration explosion in check. Otherwise, what a few people might gain in convenience, a lot of people might have to pay for it in terms of kannel support due to more difficult configuration. Some golden rules in configuration are: 1) KISS 2) Don't expand it, unless it is absolutely necessary. Stopping service to modify configuration is a no-no. Commenting a configuration file off-line is convenience. My 2 cents, Nikos - Original Message - From: Juan Nin To: Kannel Devel Sent: Tuesday, April 19, 2011 4:41 AM Subject: Re: useful patches for everyone That's what we do today, but the idea is not to have to do any extra work, neither having to comment/uncomment things out, nor have to add/remove config files. Having the start-at-boot directive allows you to just keep the configuration defined, but the smsc does not start. So anytime you need it, you just use the start-smsc and then the stop-smsc. This is much cleaner IMHO than having to do all the extra manual work, no matter how easy that manual work it may be. A similar discussion was held some months ago, can't remember what new directive it was, where the directive was finally added, since it was seen it was helpful. Not all directives are used by everyone or may be useful for everybody, that happens on any piece of software, but does not mean it's not useful, nor that it should not be added. I don't care about the WAP related parts of Kannel for example, and that doesn't mean I believe they should not exist. Adding useful things to Kannel is something that makes Kannel a better product, so I don't really see why not to add it. Maybe if it was something complicated that really messed up with the code, could be, but this is definitely not the case. Just my 2 cents. 2011/4/18 Nikos Balkanas nbalka...@gmail.com What about the HTTP command start
Re: useful patches for everyone
What about the HTTP command start-smsc: It reloads the smsc and starts them from configuration. Therefore you could have the smsc commented out at start, then enable it in the configuration and start it from the web interface, without stooping kannel. Is that not adequate? BR, Nikos - Original Message - From: Thomas Gottgens tho...@ist.schuldig.de To: Alvaro Cornejo cornejo.alv...@gmail.com Cc: Alexander Malysh amal...@vm1.kannel.org; Kannel Devel de...@vm1.kannel.org Sent: Monday, April 18, 2011 11:24 PM Subject: Re: useful patches for everyone Hello, i second that. Having the ability to start kannel with some of the binds down is so much easier in HA/Failover environments. Monday, April 18, 2011, 8:31:05 PM, you wrote: AC Hi Alex AC Another use would be when having backup links. I do use over 20 modems AC but not have all enabled at start. In order to not to have to reload AC kannel when a new modem is needed, I do start kannel and then stop all AC the backup modems and I have to do the same whenever I restart kannel AC or the server AC I'll love to have this feature in standard kannel -- Best regards, Thomasmailto:tho...@ist.schuldig.de
Re: useful patches for everyone
Hi, wapbox must be kept around because of backwards compatibility, that is a must for all open source software. Users are still using it. Finally I would like to add my support for keeping configuration explosion in check. Otherwise, what a few people might gain in convenience, a lot of people might have to pay for it in terms of kannel support due to more difficult configuration. Some golden rules in configuration are: 1) KISS 2) Don't expand it, unless it is absolutely necessary. Stopping service to modify configuration is a no-no. Commenting a configuration file off-line is convenience. My 2 cents, Nikos - Original Message - From: Juan Nin To: Kannel Devel Sent: Tuesday, April 19, 2011 4:41 AM Subject: Re: useful patches for everyone That's what we do today, but the idea is not to have to do any extra work, neither having to comment/uncomment things out, nor have to add/remove config files. Having the start-at-boot directive allows you to just keep the configuration defined, but the smsc does not start. So anytime you need it, you just use the start-smsc and then the stop-smsc. This is much cleaner IMHO than having to do all the extra manual work, no matter how easy that manual work it may be. A similar discussion was held some months ago, can't remember what new directive it was, where the directive was finally added, since it was seen it was helpful. Not all directives are used by everyone or may be useful for everybody, that happens on any piece of software, but does not mean it's not useful, nor that it should not be added. I don't care about the WAP related parts of Kannel for example, and that doesn't mean I believe they should not exist. Adding useful things to Kannel is something that makes Kannel a better product, so I don't really see why not to add it. Maybe if it was something complicated that really messed up with the code, could be, but this is definitely not the case. Just my 2 cents. 2011/4/18 Nikos Balkanas nbalka...@gmail.com What about the HTTP command start-smsc: It reloads the smsc and starts them from configuration. Therefore you could have the smsc commented out at start, then enable it in the configuration and start it from the web interface, without stooping kannel. Is that not adequate? BR, Nikos - Original Message - From: Thomas Gottgens tho...@ist.schuldig.de To: Alvaro Cornejo cornejo.alv...@gmail.com Cc: Alexander Malysh amal...@vm1.kannel.org; Kannel Devel de...@vm1.kannel.org Sent: Monday, April 18, 2011 11:24 PM Subject: Re: useful patches for everyone Hello, i second that. Having the ability to start kannel with some of the binds down is so much easier in HA/Failover environments. Monday, April 18, 2011, 8:31:05 PM, you wrote: AC Hi Alex AC Another use would be when having backup links. I do use over 20 modems AC but not have all enabled at start. In order to not to have to reload AC kannel when a new modem is needed, I do start kannel and then stop all AC the backup modems and I have to do the same whenever I restart kannel AC or the server AC I'll love to have this feature in standard kannel -- Best regards, Thomasmailto:tho...@ist.schuldig.de
Re: Memory leak in tcpip_connect_nb_to_server_with_port
Interesting... ip2 used to be a C-string with memory allocated from the stack. Somehow, sometime, someone changed that to Octstr. Cannot find the record of that change in Redmine. Anyway, good call. +1 Nikos - Original Message - From: Roman Shterenzon To: Kannel Devel Sent: Saturday, April 16, 2011 12:34 PM Subject: Memory leak in tcpip_connect_nb_to_server_with_port It looks like it leaks the IP string every time. Please review the proposed fix. --Roman
Re: Kannel 1.5.0 Debian packages
Hi,
There is an issue with the current db compilation:
- Sqlite3, Postgresql and MySQL
That means for the binary to run, you need to install all 3 dbs.
Additionaly, since SQLbox tries to be cute about it, it creates its own
databases and tables and picks automatically the first one enabled, ie
Sqlite3, if i am not mistaken, or the first that it checks for, i.e. Mysql.
Granted this is an issue to be fixed in sqlbox, but regardless i would
strongly encourage different builds, each one with a single, at most, DB.
Already uploaded Debian packages may not be any better, but it would be nice
these to be better built.
BR,
Nikos
- Original Message -
From: Alexander Malysh amal...@kannel.org
To: Milan P. Stanic m...@arvanta.net
Cc: devel@kannel.org
Sent: Tuesday, March 22, 2011 3:37 PM
Subject: Re: Kannel 1.5.0 Debian packages
Hi Milan,
as far as I see, configuration should be fine. Could you please upload debs
and diff tar to some place
and we will push it to download section then.
Thanks,
Alexander Malysh
Am 22.03.2011 um 14:09 schrieb Milan P. Stanic:
Hi Alex,
On Tue, 2011-03-22 at 09:56, Alexander Malysh wrote:
Hi Milan,
that would be great to have debian packages for 1.5.0
I forgot to mention in original post that I sent these packages to
someone in Romania who is tried it on Ubuntu. He told me that the same
binary packages which I run on Debian also works well on Ubuntu but I
forget which release he runs.
could you please answer some questions:
- how these packages compiled
I patched 1.5.0 source with official Debian diff (actually tar file)
because my intention is that the packages I build shouldn't differ a lot
from Debian shipped packages. It is because of that if someone upgrade
it from official Debian release to newly built packages s/he doesn't
have to change anything in configuration files.
- which DB support is enabled
Sqlite3, Postgresql and MySQL.
- compiler/configure flags used
Here is the relevant section from debian/rules files:
./configure \
--host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) \
--enable-warnings \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
--enable-docs --enable-pam --enable-pcre \
--enable-ssl --with-ssl=/usr \
--with-mysql --with-mysql-dir=/usr \
--with-sqlite3 \
--with-pgsql --with-pgsql-dir=/usr
And here is relevant section from Makefile:
LIBS=-lpq -lmysqlclient_r -lssl -ldl -lpam -lpcreposix -lrt -lresolv
-lnsl -lm -lpthread -lxml2 -L/usr/lib -lpcreposix -lpcre -L/usr/lib
-lcrypto -lssl -rdynamic -L/usr/lib/mysql -lmysqlclient_r
-L/usr/local/lib -lsqlite3 -L/usr/lib
CFLAGS=-D_REENTRANT=1 -I. -Igw -g -O2 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE
-D_LARGE_FILES= -I/usr/include/libxml2 -Wall -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -Winline -Wformat
-Wformat-security -Wmissing-format-attribute -I/usr/include
-I/usr/include/mysql -I/usr/include/postgresql
LDFLAGS= -rdynamic
Do you have some place to upload packages and we will push those then to
download section?
Yes, I can upload it but would like to know first if the configuration
above is correct. If not, I can rebuild it with your (or someone else)
suggestions.
Thanks,
Alexander Malysh
Am 21.03.2011 um 23:46 schrieb Milan P. Stanic:
Hi all,
I have noticed on us...@kannel.org list that some user have a problem
how to build Kannel on Debian/Ubuntu systems.
On the Kannel site in download section Debian packages are outdated
(1.4.1 version for Debian sarge). Current Debian stable release is
shipped with with Kannel 1.4.3 version which is old as we all know.
I have built Kannel 1.5.0 (development release) for Debian squeeze
(current stable) and for i386 and amd64 architectures. It works without
problem for more than three or four months.
IMHO it would be useful for users to update Kannel download section
and put new Debian packages there. I'm ready to upload them but I don't
know where or whom to send these packages.
P.S.
I'm not sure who is the site admin so I write to list.
--
Kind regards, Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code.
--
Kind regards, Milan
--
Arvanta, IT Securityhttp://www.arvanta.net
Please do not send me e-mail containing HTML code.
Re: hex to binary conversion for xml post
but what about if someone wishes to xmp-post '0102030405' as text instead
of '12345'?
Scratch that. You can simply post '00010002000300040005'.
BR,
Nikos
- Original Message -
From: Nikos Balkanas nbalka...@gmail.com
To: Alexander Malysh amal...@kannel.org
Cc: Emanuele Carbone carbe...@gmail.com; de...@vm1.kannel.org
Sent: Wednesday, March 09, 2011 5:34 AM
Subject: Re: hex to binary conversion for xml post
Hi,
octstr_hex_to_binary uses gw_isxdigit to test for hex chars, which in turn
uses the Clib isxdigit to test for [0-9][a-f][A-F]. This is valid for
regular Hex characters, however body in HTTP post should be url-encoded:
'12345' = '%31%32%33%34%35'
gw_isxdigit aside from isxdigit should also check for a single '%' every 2
chars. I understand your argument about breaking existing installations,
but what about if someone wishes to xmp-post '0102030405' as text instead
of '12345'?
BR,
Nikos
- Original Message -
From: Alexander Malysh amal...@kannel.org
To: Nikos Balkanas nbalka...@gmail.com
Cc: Emanuele Carbone carbe...@gmail.com; de...@vm1.kannel.org
Sent: Wednesday, March 09, 2011 12:22 AM
Subject: Re: hex to binary conversion for xml post
Hi,
why do you think, it should be a bug?
You see old code, new code:
/* text */
XPATH_SEARCH_OCTSTR(/message/submit/ud, text, 0);
if (text != NULL octstr_hex_to_binary(text) == -1)
octstr_url_decode(text);
And this is simple, try hex encoding 12345 (0102030405) and set it as
text.
Thanks,
Alexander Malysh
P.S. Changing this behavior will break existing setups and this for no
good reason.
Am 02.03.2011 um 16:48 schrieb Nikos Balkanas:
Hi,
This is a bug. Code scans your text for any non-hex chars. Since all
chars, 12345 are valid hex chars, it assumes that text is in hex and
tries to decode it. It should be fixed to require the '%' for url-encoded
hex chars.
BR,
Nikos
- Original Message - From: Emanuele Carbone
To: devel@kannel.org
Sent: Wednesday, March 02, 2011 4:08 PM
Subject: hex to binary conversion for xml post
Hi guys,
i tried to send a simple sms with this text 12345 (without quotes).
The request was done in XML POST and i have received a strange sequence
of character. But if the same request is done in GET i receive the
correct message. Smsbox when received a xml request extract the text so:
/* text */
text = NULL;
get_tag(*body, octstr_imm(ud), tmp, 0, 0);
if(tmp) {
O_DESTROY(text);
text = octstr_duplicate(tmp);
if(octstr_hex_to_binary(text) == -1)
octstr_url_decode(text);
O_DESTROY(tmp);
}
with the text 12345: (but it is true for the all hex symbols)
octstr_check_range(ostr, 0, ostr-len, gw_isxdigit) is valid
and the function convert ascii data to binary values. This action
compromise my text.
I don't understand why for xml request smsbox do this check.
Please, can anyone explain the reason?!
thanks in advance
Re: hex to binary conversion for xml post
Hi,
This is a bug. Code scans your text for any non-hex chars. Since all chars,
12345 are valid hex chars, it assumes that text is in hex and tries to
decode it. It should be fixed to require the '%' for url-encoded hex chars.
BR,
Nikos
- Original Message -
From: Emanuele Carbone
To: devel@kannel.org
Sent: Wednesday, March 02, 2011 4:08 PM
Subject: hex to binary conversion for xml post
Hi guys,
i tried to send a simple sms with this text 12345 (without quotes). The
request was done in XML POST and i have received a strange sequence of
character. But if the same request is done in GET i receive the correct
message. Smsbox when received a xml request extract the text so:
/* text */
text = NULL;
get_tag(*body, octstr_imm(ud), tmp, 0, 0);
if(tmp) {
O_DESTROY(text);
text = octstr_duplicate(tmp);
if(octstr_hex_to_binary(text) == -1)
octstr_url_decode(text);
O_DESTROY(tmp);
}
with the text 12345: (but it is true for the all hex symbols)
octstr_check_range(ostr, 0, ostr-len, gw_isxdigit) is valid
and the function convert ascii data to binary values. This action compromise
my text.
I don't understand why for xml request smsbox do this check.
Please, can anyone explain the reason?!
thanks in advance
Re: Submitting a patch to Kannel: best practices?
Well I have worked with many distributed and clustered systems, and i can tell you that all use distributed administration. Sun clusters, IBM clusters, you name it. Of course, since these are commercial products, they do not rely on an html page, but instead they supply their own external application that connects to each system and presents a centralized view. This is essential for operation, since if one node goes down, you can still administer the other. I suggest you look more carefully at the things you are saying. Besides no one suggested to use wiki for the job. Still you have no clue how to differentiate between sqlbox, smppbox and smsbox. Good luck with that. Nikos On Sat, Dec 18, 2010 at 7:47 PM, Alejandro Guerrieri aguerri...@kannel.orgwrote: Sure, go maintain it yourself manually on a set of thousands of nodes. The easiest thing is to let the _system_ keep track of its registered resources and provide you with that list. Go check how most clustered systems work, I bet you won't find many requiring the administrator to create a wiki page with the urls. -- Alejandro Guerrieri aguerri...@kannel.org On 18/12/2010, at 18:40, Nikos Balkanas wrote: Besides, in a distributed administration system, the easiest thing is to have a custom page with links to each system, therefore, so that everything is managed from a centralized URL. BR, Nikos On Sat, Dec 18, 2010 at 7:34 PM, Nikos Balkanas nbalka...@gmail.comwrote: No, it won't. smsbox-admin-id is no better than smsbox-id for this purpose. In terms of software it doesn't tell anything more to bb, to differentiate sqlbox from smppbox or a regular smsbox connection, so that it can show different configuration options for each one. I have also adequate experience with clusters, farms and distributed computing. Kannel will have to rewrite major portions of its interface to be used in such. I think that we have just about exhausted this topic. BR, Nikos On Sat, Dec 18, 2010 at 4:02 PM, Alejandro Guerrieri aguerri...@kannel.org wrote: An approach similar to the one we use with the smsc-admin-id would work perfectly. smsbox-id, for routing. smsbox-admin-id for sending commands. A distributed management is always better than a centralized one as complexity scales up, and doesn't limit you to anything in simpler scenarios. I disagree with that, as most of the industry does. Clusters are managed from a central place, not from each box alone (and I have my share of experience with clusters to back my point). Might work for 2-3 boxes, but try to manage 10 instances by hitting 10 different urls on 10 different servers. Scale that to 100, 1000, 1... Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 18/12/2010, at 14:48, Nikos Balkanas wrote: I don't think that wholistic centralized management is an acceptable option. Even with centralized management smsbox-id will be required. There are several features that are only applicable to the particular instance you need them. For example, live reconfiguration of services or sendsms accounts to a particular smsbox. It is not available yet, but there is no benefit in excluding it from a future version. As far as the other smsbox types go (sqlbox, smppbox), they should be allowed to have their own sets of live parameters, completely different than standard smsbox, according to their needs without trapping them to an smsbox format. These extra features or lack thereof cannot be distinguished by smsbox-id alone. A distributed management is always better than a centralized one as complexity scales up, and doesn't limit you to anything in simpler scenarios. BR, Nikos On Fri, Dec 17, 2010 at 8:50 PM, Alejandro Guerrieri aguerri...@kannel.org wrote: Well, it's a tradeoff, as usual. If you get a complex cluster of services, usually you either manage them altogether (and lose granularity), or manage them individually (and each time you need to change something on all of them you need to do it X times). Now, a good compromise would be to be able to optionally target a specific instance by passing the smsbox-id. If you don't pass it, the command is delivered to all the connected smsboxes, but if you pass it the command is only passed to that specific smsbox instance. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 17/12/2010, at 19:44, Nikos Balkanas wrote: Maybe, but it doesn't scale well. Consider that you may have 2-3 smsboxes, an sqlbox and an smppbox (all connected as smsboxes to bb). Next you might want to be able to change dynamically log levels to each one, or dynamically manage sendsms accounts. You will end up with a bb admin page a mile long. Besides, sqlbox has different admin requirements than smppbox or smsbox and bb cannot tell them apart. BR, Nikos - Original Message - From: Alexander Malysh To: Nikos Balkanas Cc: David McCann ; devel@kannel.org Sent: Friday
Re: Submitting a patch to Kannel: best practices?
I don't think that wholistic centralized management is an acceptable option. Even with centralized management smsbox-id will be required. There are several features that are only applicable to the particular instance you need them. For example, live reconfiguration of services or sendsms accounts to a particular smsbox. It is not available yet, but there is no benefit in excluding it from a future version. As far as the other smsbox types go (sqlbox, smppbox), they should be allowed to have their own sets of live parameters, completely different than standard smsbox, according to their needs without trapping them to an smsbox format. These extra features or lack thereof cannot be distinguished by smsbox-id alone. A distributed management is always better than a centralized one as complexity scales up, and doesn't limit you to anything in simpler scenarios. BR, Nikos On Fri, Dec 17, 2010 at 8:50 PM, Alejandro Guerrieri aguerri...@kannel.orgwrote: Well, it's a tradeoff, as usual. If you get a complex cluster of services, usually you either manage them altogether (and lose granularity), or manage them individually (and each time you need to change something on all of them you need to do it X times). Now, a good compromise would be to be able to optionally target a specific instance by passing the smsbox-id. If you don't pass it, the command is delivered to all the connected smsboxes, but if you pass it the command is only passed to that specific smsbox instance. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 17/12/2010, at 19:44, Nikos Balkanas wrote: Maybe, but it doesn't scale well. Consider that you may have 2-3 smsboxes, an sqlbox and an smppbox (all connected as smsboxes to bb). Next you might want to be able to change dynamically log levels to each one, or dynamically manage sendsms accounts. You will end up with a bb admin page a mile long. Besides, sqlbox has different admin requirements than smppbox or smsbox and bb cannot tell them apart. BR, Nikos - Original Message - From: Alexander Malysh To: Nikos Balkanas Cc: David McCann ; devel@kannel.org Sent: Friday, December 17, 2010 5:04 PM Subject: Re: Submitting a patch to Kannel: best practices? Hi, it would be better to let bearerbox tell smsbox to reload lists. admin message already exists for communication between bearerbox and smsbox (see restart command as example). Then you don't need extra admin interface for smsbox. Thanks, Alexander Malysh Am 17.12.2010 um 14:49 schrieb Nikos Balkanas: Hi David, Yes. bb has its own black/white lists for incoming MO traffic, similar to smsbox's MT. These can be reloaded on the fly through its http admin interface. Another very useful feature is that it allows you to change log-levels on the fly. Very useful for debugging. Check gw/bb_http.c: httpd_commands for sources. I am not talking about bearerbox telling smsbox to reload its lists. I am talking for a separate http admin for smsbox, like the one in bb. Otherwise you would have major restructuring to get it through the admin *Msg, and it is not worth it. BR, Nikos On Fri, Dec 17, 2010 at 1:07 PM, David McCann david.a.mcc...@gmail.com wrote: Hi Nikos-- Thank you for the promt reply! I completely agree that this makes more sense as a bearerbox, admin command. I initially added it as such, but then realized that in fact, all the translations logic sat within the smsbox process, rather than the bearerbox. Adding it directly as an smsbox command removes any need for any communication between the bearerbox and the smsbox. But I agree it still feels like a hack, in terms of where a user would expect to send a command such as refresh list. If you could point me to a pattern in the code where the bearerbox communicates with the smsbox in a similar fashion, it'd be a huge help and I'd be happy to re-submit my patch with it working in that manner. The current diff is still attached to the feature request, but I've attached it here as well (currently in two patches, src and doc) just for review, as we discuss this alternate approach. In regards to your comment about bearerbox handling this on the fly through its admin HTTP interface...I'm not quite sure I follow? I know this service-level refreshing functionality doesn't currently exist, are you just referring to similar functionality that exists in bearerbox? Forgive my confusion. Thanks again, --dm On Fri, Dec 17, 2010 at 1:07 PM, Nikos Balkanas nbalka...@gmail.com wrote: Hi, Usually people just post the patch to the devel list with subject: Patch: filename. Patch is attached as a diff of the file(s) from latest svn sources, followed by a brief description in the body. Wrt to your proposed solution, I am not very much in favor. In bearerbox this is handle on the fly through its admin HTTP
Re: Submitting a patch to Kannel: best practices?
Besides, in a distributed administration system, the easiest thing is to have a custom page with links to each system, therefore, so that everything is managed from a centralized URL. BR, Nikos On Sat, Dec 18, 2010 at 7:34 PM, Nikos Balkanas nbalka...@gmail.com wrote: No, it won't. smsbox-admin-id is no better than smsbox-id for this purpose. In terms of software it doesn't tell anything more to bb, to differentiate sqlbox from smppbox or a regular smsbox connection, so that it can show different configuration options for each one. I have also adequate experience with clusters, farms and distributed computing. Kannel will have to rewrite major portions of its interface to be used in such. I think that we have just about exhausted this topic. BR, Nikos On Sat, Dec 18, 2010 at 4:02 PM, Alejandro Guerrieri aguerri...@kannel.org wrote: An approach similar to the one we use with the smsc-admin-id would work perfectly. smsbox-id, for routing. smsbox-admin-id for sending commands. A distributed management is always better than a centralized one as complexity scales up, and doesn't limit you to anything in simpler scenarios. I disagree with that, as most of the industry does. Clusters are managed from a central place, not from each box alone (and I have my share of experience with clusters to back my point). Might work for 2-3 boxes, but try to manage 10 instances by hitting 10 different urls on 10 different servers. Scale that to 100, 1000, 1... Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 18/12/2010, at 14:48, Nikos Balkanas wrote: I don't think that wholistic centralized management is an acceptable option. Even with centralized management smsbox-id will be required. There are several features that are only applicable to the particular instance you need them. For example, live reconfiguration of services or sendsms accounts to a particular smsbox. It is not available yet, but there is no benefit in excluding it from a future version. As far as the other smsbox types go (sqlbox, smppbox), they should be allowed to have their own sets of live parameters, completely different than standard smsbox, according to their needs without trapping them to an smsbox format. These extra features or lack thereof cannot be distinguished by smsbox-id alone. A distributed management is always better than a centralized one as complexity scales up, and doesn't limit you to anything in simpler scenarios. BR, Nikos On Fri, Dec 17, 2010 at 8:50 PM, Alejandro Guerrieri aguerri...@kannel.org wrote: Well, it's a tradeoff, as usual. If you get a complex cluster of services, usually you either manage them altogether (and lose granularity), or manage them individually (and each time you need to change something on all of them you need to do it X times). Now, a good compromise would be to be able to optionally target a specific instance by passing the smsbox-id. If you don't pass it, the command is delivered to all the connected smsboxes, but if you pass it the command is only passed to that specific smsbox instance. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 17/12/2010, at 19:44, Nikos Balkanas wrote: Maybe, but it doesn't scale well. Consider that you may have 2-3 smsboxes, an sqlbox and an smppbox (all connected as smsboxes to bb). Next you might want to be able to change dynamically log levels to each one, or dynamically manage sendsms accounts. You will end up with a bb admin page a mile long. Besides, sqlbox has different admin requirements than smppbox or smsbox and bb cannot tell them apart. BR, Nikos - Original Message - From: Alexander Malysh To: Nikos Balkanas Cc: David McCann ; devel@kannel.org Sent: Friday, December 17, 2010 5:04 PM Subject: Re: Submitting a patch to Kannel: best practices? Hi, it would be better to let bearerbox tell smsbox to reload lists. admin message already exists for communication between bearerbox and smsbox (see restart command as example). Then you don't need extra admin interface for smsbox. Thanks, Alexander Malysh Am 17.12.2010 um 14:49 schrieb Nikos Balkanas: Hi David, Yes. bb has its own black/white lists for incoming MO traffic, similar to smsbox's MT. These can be reloaded on the fly through its http admin interface. Another very useful feature is that it allows you to change log-levels on the fly. Very useful for debugging. Check gw/bb_http.c: httpd_commands for sources. I am not talking about bearerbox telling smsbox to reload its lists. I am talking for a separate http admin for smsbox, like the one in bb. Otherwise you would have major restructuring to get it through the admin *Msg, and it is not worth it. BR, Nikos On Fri, Dec 17, 2010 at 1:07 PM, David McCann david.a.mcc...@gmail.com wrote: Hi Nikos-- Thank you for the promt reply! I completely agree
Re: Submitting a patch to Kannel: best practices?
Hi, Usually people just post the patch to the devel list with subject: Patch: filename. Patch is attached as a diff of the file(s) from latest svn sources, followed by a brief description in the body. Wrt to your proposed solution, I am not very much in favor. In bearerbox this is handle on the fly through its admin HTTP interface. I think a similar approach would be best for smsbox. BR, Nikos On Fri, Dec 17, 2010 at 8:10 AM, David McCann david.a.mcc...@gmail.comwrote: Greetings all! I've been a kannel user for years, but within the past week I've just started to work directly with the code. I had a particular need which I couldn't find a good workaround for: My current deployment with kannel uses whitelisting to dispatch messages to various running web applications (at the sms-service group level), however users do update their contact information from time to time, meaning the whitelist needs to updated, preferrably without the smsbox having to be restarted entirely. I've added a new command to the list of available commands for SMSBox, namely /cgi-bin/refreshlist, and (maybe a little overzealously) created an issue: https://redmine.kannel.org/issues/584 And submitted my patch there. Given that I'm pretty new to this community, I'm wondering if anyone can advise me on the best/most convenient way to submit a patch for incorporation into the code? Thanks in advance, David McCann T4D, UNICEF Uganda
Re: Submitting a patch to Kannel: best practices?
Hi David, Yes. bb has its own black/white lists for incoming MO traffic, similar to smsbox's MT. These can be reloaded on the fly through its http admin interface. Another very useful feature is that it allows you to change log-levels on the fly. Very useful for debugging. Check gw/bb_http.c: httpd_commands for sources. I am not talking about bearerbox telling smsbox to reload its lists. I am talking for a separate http admin for smsbox, like the one in bb. Otherwise you would have major restructuring to get it through the admin *Msg, and it is not worth it. BR, Nikos On Fri, Dec 17, 2010 at 1:07 PM, David McCann david.a.mcc...@gmail.comwrote: Hi Nikos-- Thank you for the promt reply! I completely agree that this makes more sense as a bearerbox, admin command. I initially added it as such, but then realized that in fact, all the translations logic sat within the smsbox process, rather than the bearerbox. Adding it directly as an smsbox command removes any need for any communication between the bearerbox and the smsbox. But I agree it still feels like a hack, in terms of where a user would expect to send a command such as refresh list. If you could point me to a pattern in the code where the bearerbox communicates with the smsbox in a similar fashion, it'd be a huge help and I'd be happy to re-submit my patch with it working in that manner. The current diff is still attached to the feature request, but I've attached it here as well (currently in two patches, src and doc) just for review, as we discuss this alternate approach. In regards to your comment about bearerbox handling this on the fly through its admin HTTP interface...I'm not quite sure I follow? I know this service-level refreshing functionality doesn't currently exist, are you just referring to similar functionality that exists in bearerbox? Forgive my confusion. Thanks again, --dm On Fri, Dec 17, 2010 at 1:07 PM, Nikos Balkanas nbalka...@gmail.comwrote: Hi, Usually people just post the patch to the devel list with subject: Patch: filename. Patch is attached as a diff of the file(s) from latest svn sources, followed by a brief description in the body. Wrt to your proposed solution, I am not very much in favor. In bearerbox this is handle on the fly through its admin HTTP interface. I think a similar approach would be best for smsbox. BR, Nikos On Fri, Dec 17, 2010 at 8:10 AM, David McCann david.a.mcc...@gmail.comwrote: Greetings all! I've been a kannel user for years, but within the past week I've just started to work directly with the code. I had a particular need which I couldn't find a good workaround for: My current deployment with kannel uses whitelisting to dispatch messages to various running web applications (at the sms-service group level), however users do update their contact information from time to time, meaning the whitelist needs to updated, preferrably without the smsbox having to be restarted entirely. I've added a new command to the list of available commands for SMSBox, namely /cgi-bin/refreshlist, and (maybe a little overzealously) created an issue: https://redmine.kannel.org/issues/584 And submitted my patch there. Given that I'm pretty new to this community, I'm wondering if anyone can advise me on the best/most convenient way to submit a patch for incorporation into the code? Thanks in advance, David McCann T4D, UNICEF Uganda
Re: Submitting a patch to Kannel: best practices?
Maybe, but it doesn't scale well. Consider that you may have 2-3 smsboxes, an sqlbox and an smppbox (all connected as smsboxes to bb). Next you might want to be able to change dynamically log levels to each one, or dynamically manage sendsms accounts. You will end up with a bb admin page a mile long. Besides, sqlbox has different admin requirements than smppbox or smsbox and bb cannot tell them apart. BR, Nikos - Original Message - From: Alexander Malysh To: Nikos Balkanas Cc: David McCann ; devel@kannel.org Sent: Friday, December 17, 2010 5:04 PM Subject: Re: Submitting a patch to Kannel: best practices? Hi, it would be better to let bearerbox tell smsbox to reload lists. admin message already exists for communication between bearerbox and smsbox (see restart command as example). Then you don't need extra admin interface for smsbox. Thanks, Alexander Malysh Am 17.12.2010 um 14:49 schrieb Nikos Balkanas: Hi David, Yes. bb has its own black/white lists for incoming MO traffic, similar to smsbox's MT. These can be reloaded on the fly through its http admin interface. Another very useful feature is that it allows you to change log-levels on the fly. Very useful for debugging. Check gw/bb_http.c: httpd_commands for sources. I am not talking about bearerbox telling smsbox to reload its lists. I am talking for a separate http admin for smsbox, like the one in bb. Otherwise you would have major restructuring to get it through the admin *Msg, and it is not worth it. BR, Nikos On Fri, Dec 17, 2010 at 1:07 PM, David McCann david.a.mcc...@gmail.com wrote: Hi Nikos-- Thank you for the promt reply! I completely agree that this makes more sense as a bearerbox, admin command. I initially added it as such, but then realized that in fact, all the translations logic sat within the smsbox process, rather than the bearerbox. Adding it directly as an smsbox command removes any need for any communication between the bearerbox and the smsbox. But I agree it still feels like a hack, in terms of where a user would expect to send a command such as refresh list. If you could point me to a pattern in the code where the bearerbox communicates with the smsbox in a similar fashion, it'd be a huge help and I'd be happy to re-submit my patch with it working in that manner. The current diff is still attached to the feature request, but I've attached it here as well (currently in two patches, src and doc) just for review, as we discuss this alternate approach. In regards to your comment about bearerbox handling this on the fly through its admin HTTP interface...I'm not quite sure I follow? I know this service-level refreshing functionality doesn't currently exist, are you just referring to similar functionality that exists in bearerbox? Forgive my confusion. Thanks again, --dm On Fri, Dec 17, 2010 at 1:07 PM, Nikos Balkanas nbalka...@gmail.com wrote: Hi, Usually people just post the patch to the devel list with subject: Patch: filename. Patch is attached as a diff of the file(s) from latest svn sources, followed by a brief description in the body. Wrt to your proposed solution, I am not very much in favor. In bearerbox this is handle on the fly through its admin HTTP interface. I think a similar approach would be best for smsbox. BR, Nikos On Fri, Dec 17, 2010 at 8:10 AM, David McCann david.a.mcc...@gmail.com wrote: Greetings all! I've been a kannel user for years, but within the past week I've just started to work directly with the code. I had a particular need which I couldn't find a good workaround for: My current deployment with kannel uses whitelisting to dispatch messages to various running web applications (at the sms-service group level), however users do update their contact information from time to time, meaning the whitelist needs to updated, preferrably without the smsbox having to be restarted entirely. I've added a new command to the list of available commands for SMSBox, namely /cgi-bin/refreshlist, and (maybe a little overzealously) created an issue: https://redmine.kannel.org/issues/584 And submitted my patch there. Given that I'm pretty new to this community, I'm wondering if anyone can advise me on the best/most convenient way to submit a patch for incorporation into the code? Thanks in advance, David McCann T4D, UNICEF Uganda
Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc)
Maybe you didn't mean to. But there are people from different cultures frequenting this forum, and calling someone imbecil publicly is certainly not flattering. All the same, please avoid using any suggestions or personal characterizations on me. Just stick to the facts. You should also re-read and correct your replies before posting them: Consider your answer: I don't see why we have to switch to relative time again. Only bug in kannel is, that validity is in minutes and not absolute time. The same bug apply to deferred. I am sorry, it just doesn't make any sense to me. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Devel Kannel de...@vm1.kannel.org Sent: Tuesday, December 14, 2010 2:54 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Nikos, it was in no way an insult! but sometimes it better for all of us to think a little bit longer before write a answer... Thanks, Alexander Malysh Am 14.12.2010 um 13:45 schrieb Nikos Balkanas: Please avoid using such expressions. Simply, sometimes it is difficult to understand what you say. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; Devel Kannel devel@kannel.org Sent: Tuesday, December 14, 2010 2:32 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Nikos, sometimes you have to think a bit more before you write answer ;) Converting validity to seconds will not fix this issue because it's again relative to something and this something is not the timestamp when message was created but when message is sent and this is wrong. Thanks, Alexander Malysh Am 14.12.2010 um 13:25 schrieb Nikos Balkanas: Yeah, but that's putting too much trust on external conditions, like the SMSc, for which we have no knowledge. Relative time should fix this, regardless of what the SMSc is doing. Bottom line, less problems for the user. As far as the validity period goes, I think that someone is asking for it if he specifies 1' validity period. But I don't object to it, if you want to have it specified in seconds, it's a trivial thing to do. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Alexander Malysh amal...@vm1.kannel.org; Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; de...@vm1.kannel.org Sent: Tuesday, December 14, 2010 1:27 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Hi, it's a condition for every time based parameter that server synchronized to NTP. If this not a case it's not our bad. I don't know reason for switching to absolute time anymore. As to the bug: just imagine, you send message with validity of 1min, kannel try to deliver to SMSC but SMSC is not reachable for 2 min. Then SMSC is reachable again and kannel submits message to SMSC with validity of 1min BUT validity is already expired because we waited for 2 mins for SMSC. Thanks, Alexander Malysh Am 13.12.2010 um 22:19 schrieb Nikos Balkanas: Hi, I was not aware that you were in relative time before. The only reason for switching is that it offers greater accuracy than absolute time. There is no guarantee that SMScs are correctly synchronized to NTP. Some users seem to objection to this. (or the UG entry). You obviously had your reasons for switching to absolute time. Could you list them or send me an email reference? In kannel, in SMPP, the validity is correctly converted to calendar date before sending out. There is no bug, and the resolution in configuration is perefectly acceptable (seconds are an overkill). BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; devel@kannel.org Sent: Monday, December 13, 2010 7:29 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Hi, I don't see why we have to switch to relative time again. Only bug in kannel is, that validity is in minutes and not absolute time. The same bug apply to deferred. Thanks, Alexander Malysh Am 27.11.2010 um 09:09 schrieb Nikos Balkanas: I stand corrected. bb sends in, at least in SMPP, absolute time as GMT + validity * 60 for validity and scheduled delivery time. Not very safe or good. Needs the server to be synchronized with SMSc, which would probably mean both have to be ntp synchronized. This is a defect of the SMPP spec. It defines the format of relative time in absolute terms, instead of seconds, making it difficult to calculate and reconstruct. The proposed patch makes smpp work with relative time. Please test, I do not have access to an SMSc. Let me know how it goes. I hope that all
Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc)
what doesn't do sense for you? validity period in kannel is given relative in minutes. relative to whatever timestamp and this timestamp is wrong. validity as well as deferred should be _absolute_ timestamp. Correct expression would be: ...validity is in relative time and not absolute time ...validity is not in absolute time ...validity is in minutes and not in seconds ...validity is not in seconds minutes doesn't have anything to do with absolute time. Like comparing apples with oranges. Hope this is clearer now. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Devel Kannel de...@vm1.kannel.org Sent: Wednesday, December 15, 2010 4:35 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) huh you seems to be on the wrong way! btw imbecil is wrong spelled... that should be imbecile... but anyway it's just YOUR opinion but not mine and we will stick to the facts... Consider your answer: I don't see why we have to switch to relative time again. Only bug in kannel is, that validity is in minutes and not absolute time. The same bug apply to deferred. what doesn't do sense for you? validity period in kannel is given relative in minutes. relative to whatever timestamp and this timestamp is wrong. validity as well as deferred should be _absolute_ timestamp. I hope you understand it now and if not please read code... Thanks, Alexander Malysh Am 15.12.2010 um 15:18 schrieb Nikos Balkanas: Maybe you didn't mean to. But there are people from different cultures frequenting this forum, and calling someone imbecil publicly is certainly not flattering. All the same, please avoid using any suggestions or personal characterizations on me. Just stick to the facts. You should also re-read and correct your replies before posting them: Consider your answer: I don't see why we have to switch to relative time again. Only bug in kannel is, that validity is in minutes and not absolute time. The same bug apply to deferred. I am sorry, it just doesn't make any sense to me. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Devel Kannel de...@vm1.kannel.org Sent: Tuesday, December 14, 2010 2:54 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Nikos, it was in no way an insult! but sometimes it better for all of us to think a little bit longer before write a answer... Thanks, Alexander Malysh Am 14.12.2010 um 13:45 schrieb Nikos Balkanas: Please avoid using such expressions. Simply, sometimes it is difficult to understand what you say. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; Devel Kannel devel@kannel.org Sent: Tuesday, December 14, 2010 2:32 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Nikos, sometimes you have to think a bit more before you write answer ;) Converting validity to seconds will not fix this issue because it's again relative to something and this something is not the timestamp when message was created but when message is sent and this is wrong. Thanks, Alexander Malysh Am 14.12.2010 um 13:25 schrieb Nikos Balkanas: Yeah, but that's putting too much trust on external conditions, like the SMSc, for which we have no knowledge. Relative time should fix this, regardless of what the SMSc is doing. Bottom line, less problems for the user. As far as the validity period goes, I think that someone is asking for it if he specifies 1' validity period. But I don't object to it, if you want to have it specified in seconds, it's a trivial thing to do. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Alexander Malysh amal...@vm1.kannel.org; Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; de...@vm1.kannel.org Sent: Tuesday, December 14, 2010 1:27 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Hi, it's a condition for every time based parameter that server synchronized to NTP. If this not a case it's not our bad. I don't know reason for switching to absolute time anymore. As to the bug: just imagine, you send message with validity of 1min, kannel try to deliver to SMSC but SMSC is not reachable for 2 min. Then SMSC is reachable again and kannel submits message to SMSC with validity of 1min BUT validity is already expired because we waited for 2 mins for SMSC. Thanks, Alexander Malysh Am 13.12.2010 um 22:19 schrieb Nikos Balkanas: Hi, I was not aware that you were in relative time before. The only reason for switching is that it offers greater accuracy than absolute time. There is no guarantee that SMScs are correctly synchronized to NTP
Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc)
Yeah, but that's putting too much trust on external conditions, like the SMSc, for which we have no knowledge. Relative time should fix this, regardless of what the SMSc is doing. Bottom line, less problems for the user. As far as the validity period goes, I think that someone is asking for it if he specifies 1' validity period. But I don't object to it, if you want to have it specified in seconds, it's a trivial thing to do. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Alexander Malysh amal...@vm1.kannel.org; Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; de...@vm1.kannel.org Sent: Tuesday, December 14, 2010 1:27 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Hi, it's a condition for every time based parameter that server synchronized to NTP. If this not a case it's not our bad. I don't know reason for switching to absolute time anymore. As to the bug: just imagine, you send message with validity of 1min, kannel try to deliver to SMSC but SMSC is not reachable for 2 min. Then SMSC is reachable again and kannel submits message to SMSC with validity of 1min BUT validity is already expired because we waited for 2 mins for SMSC. Thanks, Alexander Malysh Am 13.12.2010 um 22:19 schrieb Nikos Balkanas: Hi, I was not aware that you were in relative time before. The only reason for switching is that it offers greater accuracy than absolute time. There is no guarantee that SMScs are correctly synchronized to NTP. Some users seem to objection to this. (or the UG entry). You obviously had your reasons for switching to absolute time. Could you list them or send me an email reference? In kannel, in SMPP, the validity is correctly converted to calendar date before sending out. There is no bug, and the resolution in configuration is perefectly acceptable (seconds are an overkill). BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; devel@kannel.org Sent: Monday, December 13, 2010 7:29 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Hi, I don't see why we have to switch to relative time again. Only bug in kannel is, that validity is in minutes and not absolute time. The same bug apply to deferred. Thanks, Alexander Malysh Am 27.11.2010 um 09:09 schrieb Nikos Balkanas: I stand corrected. bb sends in, at least in SMPP, absolute time as GMT + validity * 60 for validity and scheduled delivery time. Not very safe or good. Needs the server to be synchronized with SMSc, which would probably mean both have to be ntp synchronized. This is a defect of the SMPP spec. It defines the format of relative time in absolute terms, instead of seconds, making it difficult to calculate and reconstruct. The proposed patch makes smpp work with relative time. Please test, I do not have access to an SMSc. Let me know how it goes. I hope that all SMScs support it. It is more accurate than absolute time, since it doesn't require synchronization between smsc and bearerbox. Please vote. BR, Nikos - Original Message - From: Milan P. Stanic m...@arvanta.net To: us...@kannel.org Sent: Monday, November 22, 2010 4:25 PM Subject: Re: syncronize kannel with smsc On Mon, 2010-11-22 at 05:31, ishagh ouldbah wrote: are you sure? According to SMPP version 3.4 time can be absolute or relative. Absolute time is default. How it is implemented in particular software is another question. I think that the kannel uses absolute time, at least for SMPP. Here is comment from gw/smsc/smsc_smpp.c - /* * check for validity and defered settings * were message value has higher priiority then smsc config group * value * Note: we always send in UTC and just define Time Difference as * 00 and * direction '+'. */ -- From: Nikos Balkanas nbalka...@gmail.com To: ishagh ouldbah ishagh...@yahoo.com; us...@kannel.org Sent: Mon, November 22, 2010 1:00:48 PM Subject: Re: syncronize kannel with smsc Well, UG is wrong there. In the SMSc definitions it states: validityperiod integer How long the message will be valid, i.e., how long the SMSC will try try to send the message to the recipient. Defined in minutes. BR, Nikos - Original Message - From: ishagh ouldbah To: Nikos Balkanas ; us...@kannel.org Sent: Monday, November 22, 2010 1:31 PM Subject: Re: syncronize kannel with smsc thans for your reponce but in SMS Push (send-sms) CGI Variables it is writen in the userguid that to use the variable validity you should syncronize with smsc contant Optional. If given, Kannel will inform SMS Center that it should only try to send
Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc)
Please avoid using such expressions. Simply, sometimes it is difficult to understand what you say. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; Devel Kannel devel@kannel.org Sent: Tuesday, December 14, 2010 2:32 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Nikos, sometimes you have to think a bit more before you write answer ;) Converting validity to seconds will not fix this issue because it's again relative to something and this something is not the timestamp when message was created but when message is sent and this is wrong. Thanks, Alexander Malysh Am 14.12.2010 um 13:25 schrieb Nikos Balkanas: Yeah, but that's putting too much trust on external conditions, like the SMSc, for which we have no knowledge. Relative time should fix this, regardless of what the SMSc is doing. Bottom line, less problems for the user. As far as the validity period goes, I think that someone is asking for it if he specifies 1' validity period. But I don't object to it, if you want to have it specified in seconds, it's a trivial thing to do. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Alexander Malysh amal...@vm1.kannel.org; Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; de...@vm1.kannel.org Sent: Tuesday, December 14, 2010 1:27 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Hi, it's a condition for every time based parameter that server synchronized to NTP. If this not a case it's not our bad. I don't know reason for switching to absolute time anymore. As to the bug: just imagine, you send message with validity of 1min, kannel try to deliver to SMSC but SMSC is not reachable for 2 min. Then SMSC is reachable again and kannel submits message to SMSC with validity of 1min BUT validity is already expired because we waited for 2 mins for SMSC. Thanks, Alexander Malysh Am 13.12.2010 um 22:19 schrieb Nikos Balkanas: Hi, I was not aware that you were in relative time before. The only reason for switching is that it offers greater accuracy than absolute time. There is no guarantee that SMScs are correctly synchronized to NTP. Some users seem to objection to this. (or the UG entry). You obviously had your reasons for switching to absolute time. Could you list them or send me an email reference? In kannel, in SMPP, the validity is correctly converted to calendar date before sending out. There is no bug, and the resolution in configuration is perefectly acceptable (seconds are an overkill). BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; devel@kannel.org Sent: Monday, December 13, 2010 7:29 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Hi, I don't see why we have to switch to relative time again. Only bug in kannel is, that validity is in minutes and not absolute time. The same bug apply to deferred. Thanks, Alexander Malysh Am 27.11.2010 um 09:09 schrieb Nikos Balkanas: I stand corrected. bb sends in, at least in SMPP, absolute time as GMT + validity * 60 for validity and scheduled delivery time. Not very safe or good. Needs the server to be synchronized with SMSc, which would probably mean both have to be ntp synchronized. This is a defect of the SMPP spec. It defines the format of relative time in absolute terms, instead of seconds, making it difficult to calculate and reconstruct. The proposed patch makes smpp work with relative time. Please test, I do not have access to an SMSc. Let me know how it goes. I hope that all SMScs support it. It is more accurate than absolute time, since it doesn't require synchronization between smsc and bearerbox. Please vote. BR, Nikos - Original Message - From: Milan P. Stanic m...@arvanta.net To: us...@kannel.org Sent: Monday, November 22, 2010 4:25 PM Subject: Re: syncronize kannel with smsc On Mon, 2010-11-22 at 05:31, ishagh ouldbah wrote: are you sure? According to SMPP version 3.4 time can be absolute or relative. Absolute time is default. How it is implemented in particular software is another question. I think that the kannel uses absolute time, at least for SMPP. Here is comment from gw/smsc/smsc_smpp.c - /* * check for validity and defered settings * were message value has higher priiority then smsc config group * value * Note: we always send in UTC and just define Time Difference as * 00 and * direction '+'. */ -- From: Nikos Balkanas nbalka
Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc)
Hi, I was not aware that you were in relative time before. The only reason for switching is that it offers greater accuracy than absolute time. There is no guarantee that SMScs are correctly synchronized to NTP. Some users seem to objection to this. (or the UG entry). You obviously had your reasons for switching to absolute time. Could you list them or send me an email reference? In kannel, in SMPP, the validity is correctly converted to calendar date before sending out. There is no bug, and the resolution in configuration is perefectly acceptable (seconds are an overkill). BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Milan P. Stanic m...@arvanta.net; ishagh ouldbah ishagh...@yahoo.com; devel@kannel.org Sent: Monday, December 13, 2010 7:29 PM Subject: Re: Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc) Hi, I don't see why we have to switch to relative time again. Only bug in kannel is, that validity is in minutes and not absolute time. The same bug apply to deferred. Thanks, Alexander Malysh Am 27.11.2010 um 09:09 schrieb Nikos Balkanas: I stand corrected. bb sends in, at least in SMPP, absolute time as GMT + validity * 60 for validity and scheduled delivery time. Not very safe or good. Needs the server to be synchronized with SMSc, which would probably mean both have to be ntp synchronized. This is a defect of the SMPP spec. It defines the format of relative time in absolute terms, instead of seconds, making it difficult to calculate and reconstruct. The proposed patch makes smpp work with relative time. Please test, I do not have access to an SMSc. Let me know how it goes. I hope that all SMScs support it. It is more accurate than absolute time, since it doesn't require synchronization between smsc and bearerbox. Please vote. BR, Nikos - Original Message - From: Milan P. Stanic m...@arvanta.net To: us...@kannel.org Sent: Monday, November 22, 2010 4:25 PM Subject: Re: syncronize kannel with smsc On Mon, 2010-11-22 at 05:31, ishagh ouldbah wrote: are you sure? According to SMPP version 3.4 time can be absolute or relative. Absolute time is default. How it is implemented in particular software is another question. I think that the kannel uses absolute time, at least for SMPP. Here is comment from gw/smsc/smsc_smpp.c - /* * check for validity and defered settings * were message value has higher priiority then smsc config group * value * Note: we always send in UTC and just define Time Difference as * 00 and * direction '+'. */ -- From: Nikos Balkanas nbalka...@gmail.com To: ishagh ouldbah ishagh...@yahoo.com; us...@kannel.org Sent: Mon, November 22, 2010 1:00:48 PM Subject: Re: syncronize kannel with smsc Well, UG is wrong there. In the SMSc definitions it states: validityperiod integer How long the message will be valid, i.e., how long the SMSC will try try to send the message to the recipient. Defined in minutes. BR, Nikos - Original Message - From: ishagh ouldbah To: Nikos Balkanas ; us...@kannel.org Sent: Monday, November 22, 2010 1:31 PM Subject: Re: syncronize kannel with smsc thans for your reponce but in SMS Push (send-sms) CGI Variables it is writen in the userguid that to use the variable validity you should syncronize with smsc contant Optional. If given, Kannel will inform SMS Center that it should only try to send the message for this many minutes. If the destination mobile is off other situation that it cannot receive the sms, the smsc discards the message. Note: you must have your Kannel box time synchronized with the SMS Center. note that i need to specify it for a specified service regards From: Nikos Balkanas nbalka...@gmail.com To: ishagh ouldbah ishagh...@yahoo.com; us...@kannel.org Sent: Sun, November 21, 2010 4:00:52 PM Subject: Re: syncronize kannel with smsc Hi, You don't need to. SMPP protocol works with validity period (relative time). Therefore, no absolute time is ever involved and you don't need to synchronize. BR, Nikos - Original Message - From: ishagh ouldbah To: us...@kannel.org Sent: Sunday, November 21, 2010 4:18 PM Subject: syncronize kannel with smsc Hi all, I want to set validity variable so I need to syncrnize with the smsc my question is How can I syncronize kannel box with smsc regards -- Kind regards, Milan -- Arvanta, IT Securityhttp://www.arvanta.net Please do not send me e-mail containing HTML code. smsc_smpp.diff
Patch: gw/smsc/smsc_smpp.c (Re: syncronize kannel with smsc)
I stand corrected. bb sends in, at least in SMPP, absolute time as GMT + validity * 60 for validity and scheduled delivery time. Not very safe or good. Needs the server to be synchronized with SMSc, which would probably mean both have to be ntp synchronized. This is a defect of the SMPP spec. It defines the format of relative time in absolute terms, instead of seconds, making it difficult to calculate and reconstruct. The proposed patch makes smpp work with relative time. Please test, I do not have access to an SMSc. Let me know how it goes. I hope that all SMScs support it. It is more accurate than absolute time, since it doesn't require synchronization between smsc and bearerbox. Please vote. BR, Nikos - Original Message - From: Milan P. Stanic m...@arvanta.net To: us...@kannel.org Sent: Monday, November 22, 2010 4:25 PM Subject: Re: syncronize kannel with smsc On Mon, 2010-11-22 at 05:31, ishagh ouldbah wrote: are you sure? According to SMPP version 3.4 time can be absolute or relative. Absolute time is default. How it is implemented in particular software is another question. I think that the kannel uses absolute time, at least for SMPP. Here is comment from gw/smsc/smsc_smpp.c - /* * check for validity and defered settings * were message value has higher priiority then smsc config group * value * Note: we always send in UTC and just define Time Difference as * 00 and * direction '+'. */ -- From: Nikos Balkanas nbalka...@gmail.com To: ishagh ouldbah ishagh...@yahoo.com; us...@kannel.org Sent: Mon, November 22, 2010 1:00:48 PM Subject: Re: syncronize kannel with smsc Well, UG is wrong there. In the SMSc definitions it states: validityperiod integer How long the message will be valid, i.e., how long the SMSC will try try to send the message to the recipient. Defined in minutes. BR, Nikos - Original Message - From: ishagh ouldbah To: Nikos Balkanas ; us...@kannel.org Sent: Monday, November 22, 2010 1:31 PM Subject: Re: syncronize kannel with smsc thans for your reponce but in SMS Push (send-sms) CGI Variables it is writen in the userguid that to use the variable validity you should syncronize with smsc contant Optional. If given, Kannel will inform SMS Center that it should only try to send the message for this many minutes. If the destination mobile is off other situation that it cannot receive the sms, the smsc discards the message. Note: you must have your Kannel box time synchronized with the SMS Center. note that i need to specify it for a specified service regards From: Nikos Balkanas nbalka...@gmail.com To: ishagh ouldbah ishagh...@yahoo.com; us...@kannel.org Sent: Sun, November 21, 2010 4:00:52 PM Subject: Re: syncronize kannel with smsc Hi, You don't need to. SMPP protocol works with validity period (relative time). Therefore, no absolute time is ever involved and you don't need to synchronize. BR, Nikos - Original Message - From: ishagh ouldbah To: us...@kannel.org Sent: Sunday, November 21, 2010 4:18 PM Subject: syncronize kannel with smsc Hi all, I want to set validity variable so I need to syncrnize with the smsc my question is How can I syncronize kannel box with smsc regards -- Kind regards, Milan -- Arvanta, IT Securityhttp://www.arvanta.net Please do not send me e-mail containing HTML code. smsc_smpp.diff Description: Binary data
Re: [Solution] possible DLR mismatch due to the '+' character absence inthe MSISDN
Hi, I am not so sure. It used to be like that, but then a patch was submitted that converted it to quotes. This permitted to use certain SQL functions as names for tables and columns, if I remember correctly. I think that V Chambanis submitted the patch. You certainly have a point, but it needs to be discussed first. BR, Nikos - Original Message - From: Mohammed Saleem To: kannel_dev_mailinglist Sent: Thursday, November 25, 2010 4:40 PM Subject: [Solution] possible DLR mismatch due to the '+' character absence inthe MSISDN Dear Kannelers I have faced a slight issue with the DLR matching when a DLR is received from the carrier, when we send the message we use the international format +XXXy and when the carrier sends the DLR it send the MSISDN with the '+' character, and some other times it sends it without the '+' character. I know it is the carrier's fault, but this causes a DLR mismatch and bb can't find the DLR Anyways, I have solved this by changing the SQL statements in gw/dlr_mysql.c ( I use MySQL ad SLR storage) I've removed the quotes from the destination value( changed '%s' to %s) , this lets MySQL searches for the record using numeric comparing not literal, therefore, the '+' character won't affect anything Can anyone help with creating a patch? I tried to create one but I am not sure if my dlr_mysql.c is not modified before, so I thought someone would do this for us Thanks Best Regards, Mohammed M I Sleem http://www.abusleem.net http://www.freakle.com - The Search Freak http://www.colorle.com - color your Google search
Re: 1.5.x SUBMIT_MULTI support
Hi, Normal procedure is to download and make corrections to the latest svn. Then generate a patch of the changes you made, submit to devel for discussion and if it is useful and doesn't clash with anything, it will be picked up by a kannel administrator and submitted to svn. BR, Nikos - Original Message - From: Alan Milligan To: devel@kannel.org Sent: Friday, November 26, 2010 3:14 AM Subject: 1.5.x SUBMIT_MULTI support Hi, I have some patches against 1.4.3 which port the submit-multi patch created a number of years ago. I'd like to get this into the 1.5.x mainline if that's possible. I can probably port a release of this to 1.5.0 but may or may not be in a position to have this tested against a range of Acision MAR/SMSC equipment. Can someone please confirm if/what must be done to get this into the Kannel trunk. Alan
Re: SMSC Rejected DLR shouldn't be saved in the DLR storage
Hi, Read UG about dlr-mask. BR, Nikos - Original Message - From: Mohammed Saleem To: kannel_dev_mailinglist Sent: Thursday, November 18, 2010 3:24 PM Subject: Re: SMSC Rejected DLR shouldn't be saved in the DLR storage Hello Kanelers, Any idea? please advise on this, I couldn't find the place where to modify the source to disable this !! Any reply would be highly appreciated Thanks Best Regards, Mohammed M I Sleem http://www.abusleem.net http://www.freakle.com - The Search Freak http://www.colorle.com - color your Google search On Tue, Nov 16, 2010 at 6:29 PM, Mohammed Saleem mohammedsl...@gmail.com wrote: When the SMS is rejected by the SMSC, why it gets saved into the DLR storage? (eg. dlr table)? since it is already rejected by the SMSC it shouldn't be saved in the DLR storage or it will kept in the storage forever is this a bug or is there a case that the SMSC may report DLR on rejected messages? Thanks Best Regards, Mohammed M I Sleem http://www.abusleem.net http://www.freakle.com - The Search Freak http://www.colorle.com - color your Google search
Re: [PATCH] Logging to syslog
Good idea, just that wapbox already supports syslog. It would be good to use the same archotecture for the rest. BR, Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Devel Kannel devel@kannel.org Sent: Tuesday, November 16, 2010 9:49 PM Subject: [PATCH] Logging to syslog Proposed patch implements syslog logging on bearerbox, smsbox and wapbox. More details and a link the the patch here: http://www.blogalex.com/archives/240 Please review. I'll write the userguide patch if it's accepted. Regards, -- Alejandro Guerrieri aguerri...@kannel.org
Re: [PATCH] Logging to syslog
Sorry, don't have the time. BR, Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Devel Kannel devel@kannel.org Sent: Tuesday, November 16, 2010 10:11 PM Subject: Re: [PATCH] Logging to syslog Check the patch, that's what I did... I've extended what there was on wapbox (I don't think it was working actually). Regerds, -- Alejandro Guerrieri aguerri...@kannel.org On 16/11/2010, at 21:07, Nikos Balkanas wrote: Good idea, just that wapbox already supports syslog. It would be good to use the same archotecture for the rest. BR, Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Devel Kannel devel@kannel.org Sent: Tuesday, November 16, 2010 9:49 PM Subject: [PATCH] Logging to syslog Proposed patch implements syslog logging on bearerbox, smsbox and wapbox. More details and a link the the patch here: http://www.blogalex.com/archives/240 Please review. I'll write the userguide patch if it's accepted. Regards, -- Alejandro Guerrieri aguerri...@kannel.org
Re: Disable SMPP log in bearerbox log !
Hi, It is in gw/smsc/smsc_smpp.c: handle_pdu(). Should be ~line 1752. I think that deleting it will also remove it from connection log. BR, Nikos - Original Message - From: Mohammed Saleem To: kannel_dev_mailinglist Sent: Friday, November 12, 2010 12:42 PM Subject: Disable SMPP log in bearerbox log ! Hello Kannelers, I have some noisy log in the bearerbox log file, such like 2010-11-12 10:33:40 [3441] [13] ERROR: SMPP[SDZAIN03]: SMSC returned error code 0x0045 (Submit failed) in response to submit_sm. This line of log has already been mentioned in the SMPP connection log, how can I remove it from the bearerbox log? any tip or pointer to the location of this log in the source would be highly appreciated Cheers Best Regards, Mohammed M I Sleem http://www.abusleem.net http://www.freakle.com - The Search Freak http://www.colorle.com - color your Google search
Re: [PATCH] esm_class to default_smsc_mode
You don't seem so sure that default_smsc_mode will not cause problems. I remember in the past some issues with ESM_CLASS, but were few and in between. Store and forward has been working for most people. This change will affect regular sms as well. Wouldn't be better to make it configurable? BR, Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Devel Kannel devel@kannel.org Sent: Tuesday, November 09, 2010 11:21 PM Subject: Re: [PATCH] esm_class to default_smsc_mode Correction: using store and forward causes problems. [Thanks Juan Nin for noting it] Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 09/11/2010, at 19:34, Alejandro Guerrieri wrote: This patch changes the esm_class from store and forward to default smsc mode. Using default smsc mode causes problems with wap-push on a number of carriers around the world. On the other hand, at least in my own experience setting it to default smsc mode doesn't cause any negative effects. Regards, -- Alejandro Guerrieri aguerri...@kannel.org kannel-smpp-esm_class.patch
Re: Message length limit
No, you cannot do that, it is in a violation of the SMS spec. After all SMS stands for Short Messaging System. If you want to create an SMSc just for you, be my guest, but it won't be able to handle any other traffic other than yours. BR, Nikos - Original Message - From: Luca Corti l...@fantacast.it To: Mohammed Saleem mohammedsl...@gmail.com Cc: devel@kannel.org Sent: Saturday, October 30, 2010 6:12 PM Subject: Re: Message length limit On Sat, 2010-10-30 at 13:11 +0200, Mohammed Saleem wrote: Check the documentation, these variables would be helpful in the sendsms-user group but I haven't used disabled them before max-messages number concatenation bool I see, but my question is a bit different. I don't wan't to send multiple messages which are then handled as a single message by the end device. What I want to do is implementing an smsc driver which talks with its smsc over a protocol which allows messages to be larger than standard SMS messages. So the question is, if I implement such a driver, will kannel allow me to inject such large messages via sendsms, queue them and then ship them to my smsc driver even if the message text is larger than the standard SMS 160 charachters limit? Hope the question is clearer now. ciao Luca
Re: Message length limit
Good to know. And the SMScs have no problem with it? I imagine they split it themselves before delivery to mobile and they charge each part. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Luca Corti l...@fantacast.it Cc: Nikos Balkanas nbalka...@gmail.com; devel@kannel.org Sent: Saturday, October 30, 2010 9:15 PM Subject: Re: Message length limit Hi, it should be possible in bearerbox and in smsbox but smsbox will need to be modified. In bearerbox you have to use max-sms-octets config variable to set maximum length for SMSC module/connection. Btw. SMPP allow message up to 64K using message_payload... Thanks, Alex Am 30.10.2010 um 17:53 schrieb Luca Corti: On Sat, 2010-10-30 at 18:16 +0300, Nikos Balkanas wrote: No, you cannot do that, it is in a violation of the SMS spec. After all SMS stands for Short Messaging System. If you want to create an SMSc just for you, be my guest, but it won't be able to handle any other traffic other than yours. As I clearly stated, I'd like to *abuse* kannel. Obviously, these are not SMS messages, since they do not adhere to the SMS specs, but they share enough common traits with SMS messages that the only limitation I see is the message length. I know implementing my own protocol/driver will not allow me to route such messages through standard SMSCs. I asked if the kannel internal architecture allows larger messages larger to flow through kannel (smsbox, bearerbox) and be delivered to a driver which talks non-standard protocols to non-standard SMSCs. If my understanding of how kannel works is correct, this is the flow of a message submitted through sendsms and terminated via a driver to an SMSc: HTTP - sendsms - smsbox - bearerbox - smsc driver Are there internal data formats or validity checks in place which explicitly forbid this? I realize I'm trying to bend kannel to my needs, I'd just like to know if this is theoretically possible before considering the possibility of implementing an smsc driver. I'm currently looking at the code, but I thought this is a question kannel developers may be able to quickly respond to. thanks for your feedback Luca
Re: [PATCH] Opensmppbox and handling of stat txt field in DLR.
Hi, Looks good. Opensmppbox maintainer is Rene. You might want to cc him for smppbox patches. 3 observations: 1) You write straight C. I have no problem with it, and in fact I prefer it. But other people might object to it, and would prefer octstr_* wrappers. Please review gwlib/octstr.h and replace some of the functions like strstr and sscanf with those. 2) What if there is no stat: field in the DLR? Handle this case, too. 3) You need to octstr_destroy(dlr_status) when done, else you will have a memory leak. +1 BR, Nikos - Original Message - From: XEN-Housing s.r.o. i...@xen-housing.sk To: devel@kannel.org Sent: Thursday, October 28, 2010 3:09 PM Subject: [PATCH] Opensmppbox and handling of stat txt field in DLR. Hello there. I was wroten another small patch to opensmppbox. When i got from smpp smsc an fail status due sms was expired, at stat field of message was EXPIRED, but when DLR passes trought opensmppbox, target client got fixed UNDELIV text. Original code doesnot reflect original reason why sms delivery failed. Please review that code, if there are no memory leaks, or if that code should be applicated to all message statuses, not only DLR_FAIL and DLR_SMSC_FAIL. Slavoj.
Re: [PATCH] Opensmppbox and handling of stat txt field in DLR.
Hi,
1 more thing:
if (original_stat) {
dlr_status = octstr_create(original_stat);
= if (*original_stat){
dlr_status = octstr_create(original_stat);
BR,
Nikos
- Original Message -
From: XEN-Housing s.r.o. i...@xen-housing.sk
To: Nikos Balkanas nbalka...@gmail.com
Cc: rene.klu...@chimit.nl; devel@kannel.org
Sent: Thursday, October 28, 2010 4:01 PM
Subject: Re: [PATCH] Opensmppbox and handling of stat txt field in DLR.
Hi,
fixed memory leak and missing stat field in original dlr text. thnx for
help Nikos ;)
Slavoj.
DΕ�a 28. 10. 2010 14:47, Nikos Balkanas wrote / napΓsal(a):
Hi,
Looks good. Opensmppbox maintainer is Rene. You might want to cc him
for smppbox patches.
3 observations:
1) You write straight C. I have no problem with it, and in fact I
prefer it. But other people might object to it, and would prefer
octstr_* wrappers. Please review gwlib/octstr.h and replace some of
the functions like strstr and sscanf with those.
2) What if there is no stat: field in the DLR? Handle this case, too.
3) You need to octstr_destroy(dlr_status) when done, else you will
have a memory leak.
+1
BR,
Nikos
- Original Message - From: XEN-Housing s.r.o.
i...@xen-housing.sk
To: devel@kannel.org
Sent: Thursday, October 28, 2010 3:09 PM
Subject: [PATCH] Opensmppbox and handling of stat txt field in DLR.
Hello there.
I was wroten another small patch to opensmppbox. When i got from smpp
smsc an fail status due sms was expired, at stat field of message was
EXPIRED, but when DLR passes trought opensmppbox, target client got
fixed UNDELIV text. Original code doesnot reflect original reason why
sms delivery failed.
Please review that code, if there are no memory leaks, or if that code
should be applicated to all message statuses, not only DLR_FAIL and
DLR_SMSC_FAIL.
Slavoj.
Re: [FIX] BROKEN DLR with Mysql with intermediate state
Hi, Good eye! That's a typo that got away. +1 BR, Nikos - Original Message - From: Vincent CHAVANIS v.chava...@telemaque.fr To: devel@kannel.org Sent: Monday, October 11, 2010 7:38 PM Subject: [FIX] BROKEN DLR with Mysql with intermediate state Dear all, Here is a small patch that fixes intermediate DLR state for all SMSCs using MySQL. Vincent. -- Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR) Service Technique/Reseau - NOC Direction du Developpement xMS+ http://www.telemaque.fr/ v.chava...@telemaque.fr Tel : +33 4 92 90 99 84 (fax 9142)
Re: Message state in DELIVER_SM operation
Sure it does, in smpp_pdu_unpack() along with the rest of the TLV Integers. BR, Nikos - Original Message - From: shesh_india aiyeng...@gmail.com To: devel@kannel.org Sent: Tuesday, September 28, 2010 6:43 AM Subject: Re: Message state in DELIVER_SM operation Hello But the deliver_sm does not parse the message_state. Is there any new code committed to the Trunk where this is handled regards Shesh Alexander Malysh wrote: Hi, this is from SMPP 3.4 Thanks, Alexander Malysh Am 27.09.2010 um 15:27 schrieb Sharwan K: Hello, I am looking for a little clarification with respect to the message delivery status in smpp. While browsing through the source file (gw/smsc/smsc_smpp.c) in handle_pdu() function , in case:deliver_sm , we call the function handle_dlr and the last argument which is passed is pdu-u.deliver_sm.message_state. I am not able to understand from where we get the message_state as there is no such parameter specified in the SMPP 3.4 specification for DELIVER_SM message. can someone correct me in the understanding the logic behind this part ? Regards, Basileis -- View this message in context: http://old.nabble.com/Message-state-in-DELIVER_SM-operation-tp29819011p29825134.html Sent from the Kannel - Dev mailing list archive at Nabble.com.
Re: SMPP BOX
(not x-posting) Just a note. I suspect that Debian 1.4.3 may be no good. At least sqlbox was compiled with 3 DB libraries, so users had to install all DB libraries for the rpm - impractical. Also since sqlbox is a bit intelligent about its DB and building its own tables, it was picking the first one defined, therefore it would always pick mysql no matter what. Maybe kannel has the same fate. But i was not referring to Debian for submission. I was referring to the kannel site, where available rpms are ~10 yrs old. BR, Nikos - Original Message - From: Milan P. Stanic m...@arvanta.net To: us...@kannel.org Cc: devel@kannel.org Sent: Wednesday, September 22, 2010 2:04 PM Subject: Re: SMPP BOX [ Cc-ing to devel so Alex can read ] On Wed, 2010-09-22 at 13:11, Nikos Balkanas wrote: You need to be an administrator to upload content. The way I would do it, is to mark it as Contribution: ... in Subject and submit to Alex M, cc the list. He will upload it for you. If it is too large for email, talk to Alex first. OK. Tnx. I will do that. PS: Usually rpms are built out of stable realeases (ie 1.4.3) not svn. Since a lot of additions have hapenned since, you might want to wait a bit for next release, 1.4.4, I believe it is very close due. Stable release (1.4.3) is already in Debian testing/unstable (and Ubuntu, I think). Debian is reluctant to accept development versions of software so I usually build Kannel (and other important packages) from source. And because current Debian testing in frozen state I think that the new stable release (as Alex announced on devel list) have a little chance to go to next Debian stable. I know that is not best situation because I know that the development version of Kannel is stable and deserves to be in the stable distro's (be it Debian or other). Long story short, I would like to help people who do not have experience to build Kannel (and opensmppbox) from sources, to have development (and real soon now, stable) version out of the box, because I did it already for my own use. BR, Nikos - Original Message - From: Milan P. Stanic m...@arvanta.net To: us...@kannel.org Sent: Wednesday, September 22, 2010 12:15 PM Subject: Re: SMPP BOX On Wed, 2010-09-22 at 12:08, Nikos Balkanas wrote: There is a special area in the downloads section of the site that includes rpms. Why don't you contribute it there? Nice idea. I can build postgresql and mysql versions to. Though I don't know how to upload it there. Must I have account or anonymous upload is allowed? BR, Nikos - Original Message - From: Milan P. Stanic m...@arvanta.net To: us...@kannel.org Sent: Wednesday, September 22, 2010 11:49 AM Subject: Re: SMPP BOX On Wed, 2010-09-22 at 00:44, dafodil wrote: I guess i need these steps to install smpp box create a directory gateway under path /usr/local then run command svn co https://svn.kannel.org/gateway/trunk Create a directory smppbox under path /usr/local/gateway then run command svn co https://svn.kannel.org/smppbox/trunk then go to directory /usr/local/gateway/trunk and run these commands ./configure make make install Same command run under /usr/local/gateway/smppbox/trunk ./configure make make install But i have got kannel installed(stable vesion 1.4.3).so what should i do? remove existing and install new ones.(if i need to remove than how?) or just reinstalling the svn source should go fine.(in that case do i need any additional steps apart from what mentioned above) I built Kannel SVN version a week ago for Debian testing/unstable (with sqlite3 support only) for i386 and amd64 architectures. If someone wants to host them somewhere for users who do not have enough experience with building software from sources I can upload all the packages (binary, development, extra and documentation). It works in production on the squeeze (testing) Debian distribution without any problem. I presume it should work on current stable and testing Ubuntu. I also debianized opensmmpbox and built it for amd64 architecture (but I could build i386 version because I have development chroots all around) so it could be useful for people with less experience. If someone have resources (and good will) to host these packages drop me a note, please. Kiran Reddy-3 wrote: Hi, https://svn.kannel.org/gateway/trunk On 9/22/2010 12:54, dafodil wrote: Hi List, From the document i get following: - Latest Kannel must be installed (1.4.3 svn version), including development headers and libraries. Kannel�²β�¬β�Άs gwlib is needed for compilation. Additionally a working (running) Bearerbox is needed to route SMS to. If it is not available, SMS messages can possibly be lost and no more logins are permitted. - Form where can i get svn version1.4.3.from download section i see kannel stable 1.4.3 and development version 1.3.2. from where do i get development headers and libraries or kannel svn1.4.3 contains
Re: [PATCH] CMPP2 (China Mobile Peer to Peer) module
That means that the patch is unnecessary and current SMPP driver can handle
it with only a configuration change.
BR,
Nikos
- Original Message -
From: Rene Kluwen rene.klu...@chimit.nl
To: 'Stipe Tolj' s...@tolj.org
Cc: 'kannel_dev_mailinglist' devel@kannel.org
Sent: Monday, September 20, 2010 6:25 PM
Subject: RE: [PATCH] CMPP2 (China Mobile Peer to Peer) module
I agree as well!
-Original Message-
From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf
Of Stipe Tolj
Sent: Monday, 20 September, 2010 15:14
Cc: kannel_dev_mailinglist
Subject: Re: [PATCH] CMPP2 (China Mobile Peer to Peer) module
Alejandro Guerrieri schrieb:
--- gw/msg-decl.h (revision 4843)
+++ gw/msg-decl.h (working copy)
@@ -111,6 +111,11 @@
INTEGER(resend_try)
INTEGER(resend_time)
OCTSTR(meta_data)
+OCTSTR(service_id)
+OCTSTR(fee_usertype)
+OCTSTR(fee_terminal_id)
+OCTSTR(fee_type)
+OCTSTR(fee_code)
})
What about using meta-data for that? Assuming a separate smsc module is
used (unless all the new PDU's are implemented inside smsc_smpp?), using
meta-data to pass the specific parameters could be an option.
yep, total agree here!
Stipe
--
---
Kφlner Landstrasse 419
40589 Dόsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: [RFC] adding CMPP (China Mobile's SMPP clone) SMSC client sidemodule
I know that, but he talks about changing the Msg struct
BR,
Nikos
- Original Message -
From: Alejandro Guerrieri aguerri...@kannel.org
To: Nikos Balkanas nbalka...@gmail.com
Cc: Stipe Tolj s...@tolj.org; 'kannel_dev_mailinglist'
devel@kannel.org
Sent: Sunday, September 19, 2010 1:30 PM
Subject: Re: [RFC] adding CMPP (China Mobile's SMPP clone) SMSC client
sidemodule
Not really, using different PDU's doesn't mean having to change Msg at all.
If there's different PDU's to handle submit, deliver, etc. it can be
abstracted on the same Msg structure and it can be done with a special SMSC
(or extending smsc_smpp as Alex suggested) and there's no need to touch
anything else.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 19/09/2010, at 05:37, Nikos Balkanas wrote:
it's a sort of SMPP with some PDU additions. The patch I have adds 3
parameters to the msg struct, which we could resolve maybe to use other
known
values if they semantically match.
Do you mean PDU? Changing Msg is very troublesome. It needs changes to
smsbox, sqlbox, and smppbox in addition to bearerbox.
BR,
Nikos
- Original Message - From: Stipe Tolj s...@tolj.org
Cc: 'kannel_dev_mailinglist' devel@kannel.org
Sent: Saturday, September 18, 2010 11:36 PM
Subject: Re: [RFC] adding CMPP (China Mobile's SMPP clone) SMSC client
sidemodule
Rene Kluwen schrieb:
Exactly. Is this really different from plain old SMPP?
Maybe a configuration parameter can do the trick?
it's a sort of SMPP with some PDU additions. The patch I have adds 3
parameters to the msg struct, which we could resolve maybe to use other
known
values if they semantically match.
I'll have a view into it and post the patch for review by the group.
Stipe
--
---
Kφlner Landstrasse 419
40589 D�sseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: [RFC] adding CMPP (China Mobile's SMPP clone) SMSC client sidemodule
it's a sort of SMPP with some PDU additions. The patch I have adds 3
parameters to the msg struct, which we could resolve maybe to use other
known
values if they semantically match.
Do you mean PDU? Changing Msg is very troublesome. It needs changes to
smsbox, sqlbox, and smppbox in addition to bearerbox.
BR,
Nikos
- Original Message -
From: Stipe Tolj s...@tolj.org
Cc: 'kannel_dev_mailinglist' devel@kannel.org
Sent: Saturday, September 18, 2010 11:36 PM
Subject: Re: [RFC] adding CMPP (China Mobile's SMPP clone) SMSC client
sidemodule
Rene Kluwen schrieb:
Exactly. Is this really different from plain old SMPP?
Maybe a configuration parameter can do the trick?
it's a sort of SMPP with some PDU additions. The patch I have adds 3
parameters to the msg struct, which we could resolve maybe to use other
known
values if they semantically match.
I'll have a view into it and post the patch for review by the group.
Stipe
--
---
Kφlner Landstrasse 419
40589 Dόsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Re: wtls branch merged
In total agreement. As already stated, rpms are for the masses, wtls for the
few that really need it ;-)
BR,
Nikos
- Original Message -
From: Alexander Malysh amal...@kannel.org
To: Nikos Balkanas nbalka...@gmail.com
Cc: Milan P. Stanic m...@arvanta.net; Kannel Devel devel@kannel.org;
Rene Kluwen rene.klu...@chimit.nl
Sent: Monday, September 13, 2010 11:06 AM
Subject: Re: wtls branch merged
Hi,
I just not even noticed that RC5 was not enabled in openssl by default
because fink for OSX does this...
Back to this patch, wtls was never enabled by default in kannel and wtls
requires RC5 (as far as I know).
So the only possible solution would be to ship binary packages without wtls
and if somebody would like to
have wtls support, have to compile openssl with RC5 and kannel from source.
As to the patent and license. We don't implement RC5 we just use openssl
library. So IMO it should not be our
issue.
Thanks,
Alexander Malysh
Am 13.09.2010 um 06:44 schrieb Nikos Balkanas:
Actually nothing changes from the day before. wtls is not enabled by
default. This submission just fixes a broken feature, doesn't provide a
new one. The same way that providers built packages before (without wtls)
the same way they will continue to do. They simply have one more option:
wtls that works. More options never hurt anyone.
Lastly I stand by my original assessment. We are fully covered by
openssl's license. RC5 is not implemented in wtls code, but is part of the
openssl source. There used to be strict export restrictions, till the
Reagan years, but they have been relaxed since then (1990). wtls is not
restricted. Users may be restricted to download openssl alltogether, but
this is not our concern, and in that case they can always configure kannel
without encryption (SSL or wtls).
Quoting from netsnmp
(http://www.net-snmp.org/wiki/index.php/Crypto_Export_Restrictions):
Our cryptography software portions (AES and DES) actually come from
OpenSSL and are not implemented internally. Additionally, back when export
restrictions were relaxed for open source software, all that is required
for an open source package thats provides releases on a web site is to
send proper notification to the US export office (which we did), but the
export office does not respond to such queries (they only log it).
It's up to manufactures of devices and software that intend to sell their
devices over-seas to go through proper paperwork for the device that
includes open source software. IE, nothing we could give you would satisfy
your own requirements. We strongly suggest you consult with an export
control lawyer as this community is not a legal service that you can count
on.
This apparently is not specific to rc5, but includes all linking to
openssl libraries, including kannel's https implementation.
Hope this clears up things,
Nikos
- Original Message - From: Milan P. Stanic m...@arvanta.net
To: devel@kannel.org
Sent: Sunday, September 12, 2010 8:46 PM
Subject: Re: wtls branch merged
To reply myself:
On Sun, 2010-09-12 at 19:36, Milan P. Stanic wrote:
On Sun, 2010-09-12 at 20:13, Nikos Balkanas wrote:
I don't believe so. The openssl RC5 is licensed under the openssl
license (similar to kannel's).
http://www.openssl.org/source/license.html
Licence is for software implementation and it is free but the RC5
algorithm is patented, AFAIK. I'm not a lawyer and I don't all details
but I think that the RC5 cannot be used in USA (and possible other
countries) without licence from the patent holder (in that case RSA
Data Security).
A quick look at WTLS specification shows that the RC5 isn't mandatory
but optional.
Just found this Press Release
http://www.rsa.com/press_release.aspx?id=172
which states that RC5
cite
algorithm that is specified as should be supported by all WTLS clients
and servers by the WAP Forum for WTLS environments.
/cite
So, I was wrong. But the issue remains. I suspect that any distributor
will have Kannel package with WTLS enabled in their repositories.
Yes it is necessary, as mentioned in a previous mail. Incorrectly I
said that it is used in key generation. Actually it is one of the 3
cipher algorithms used for content according to the wtls spec:
enum bulk_algorithms {
NULL_bulk,
RC5_CBC_40,
RC5_CBC_56,
RC5_CBC,
DES_CBC_40,
DES_CBC,
TRIPLE_DES_CBC_EDE,
IDEA_CBC_40,
IDEA_CBC_56,
IDEA_CBC
};
This implementation supports the RC5 and DES algorithms. Not the IDEA.
Kannel already has wtls with RC5 for all these years, except that it
doesn't work.
BR,
Nikos
- Original Message - From: Milan P. Stanic
m...@arvanta.net
To: devel@kannel.org
Sent: Sunday, September 12, 2010 7:42 PM
Subject: Re: wtls branch merged
On Sun, 2010-09-12 at 17:35, Nikos Balkanas wrote:
But you don't need an rpm if you build from sources. You have all
the includes and sources that you
Re: wtls branch merged
Thanks for bringing them to my attention. I cannot use -std=gnu99 in Solaris and don't get those. I will compile in Linux and fix them. BR, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Kannel Devel devel@kannel.org Sent: Monday, September 13, 2010 11:14 AM Subject: Re: wtls branch merged Hi Nikos, patch commited to svn but we have more warnings wtls related: gcc -std=gnu99 -D_REENTRANT=1 -I. -Igw -g -O2 -DDARWIN=1 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -D_LARGE_FILES= -I/sw/include/libxml2 -I/sw/include -Wall -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wformat -Wformat-security -Wmissing-format-attribute -I/usr/include/openssl -I/sw/include/mysql -I/Users/alex/oracle/instantclient_10_2/sdk/include -o wap/wtls-secmgr.o -c wap/wtls-secmgr.c wap/wtls.c:280: warning: no previous prototype for ‘send_alert’ wap/wtls.c:401: warning: no previous prototype for ‘stateName’ gcc -std=gnu99 -D_REENTRANT=1 -I. -Igw -g -O2 -DDARWIN=1 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -D_LARGE_FILES= -I/sw/include/libxml2 -I/sw/include -Wall -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wformat -Wformat-security -Wmissing-format-attribute -I/usr/include/openssl -I/sw/include/mysql -I/Users/alex/oracle/instantclient_10_2/sdk/include -o wap/wtls_pdu.o -c wap/wtls_pdu.c wap/wtls_pdu.c:359: warning: no previous prototype for ‘wtls_payload_guess_length’ gcc -std=gnu99 -D_REENTRANT=1 -I. -Igw -g -O2 -DDARWIN=1 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -D_LARGE_FILES= -I/sw/include/libxml2 -I/sw/include -Wall -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wformat -Wformat-security -Wmissing-format-attribute -I/usr/include/openssl -I/sw/include/mysql -I/Users/alex/oracle/instantclient_10_2/sdk/include -o wap/wtls_pdusupport.o -c wap/wtls_pdusupport.c wap/wtls_pdusupport.c:892: warning: no previous prototype for ‘destroy_octstr’ wap/wtls_pdusupport.c:897: warning: no previous prototype for ‘destroy_octstr16’ wap/wtls_pdusupport.c:902: warning: no previous prototype for ‘destroy_octstr_fixed’ wap/wtls_pdusupport.c:913: warning: no previous prototype for ‘destroy_dhparams’ wap/wtls_pdusupport.c:920: warning: no previous prototype for ‘destroy_ecparams’ wap/wtls_pdusupport.c:969: warning: no previous prototype for ‘destroy_public_key’ wap/wtls_pdusupport.c:1004: warning: no previous prototype for ‘destroy_rsa_secret’ wap/wtls_pdusupport.c:1016: warning: no previous prototype for ‘destroy_key_exchange_id’ wap/wtls_pdusupport.c:1092: warning: no previous prototype for ‘destroy_signature’ wap/wtls_pdusupport.c:1126: warning: no previous prototype for ‘dump_void16’ gcc -std=gnu99 -D_REENTRANT=1 -I. -Igw -g -O2 -DDARWIN=1 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -D_LARGE_FILES= -I/sw/include/libxml2 -I/sw/include -Wall -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wformat -Wformat-security -Wmissing-format-attribute -I/usr/include/openssl -I/sw/include/mysql -I/Users/alex/oracle/instantclient_10_2/sdk/include -o wap/wtls_statesupport.o -c wap/wtls_statesupport.c wap/wtls_statesupport.c:663: warning: no previous prototype for ‘wtls_P_hash’ wap/wtls_statesupport.c: In function ‘wtls_hmac_hash’: wap/wtls_statesupport.c:737: warning: implicit declaration of function ‘HMAC’ wap/wtls_statesupport.c:737: warning: nested extern declaration of ‘HMAC’ wap/wtls_statesupport.c: At top level: wap/wtls_statesupport.c:1103: warning: no previous prototype for ‘wtls_get_certificate’ wap/wtls_statesupport.c:1184: warning: no previous prototype for ‘isSupportedKeyEx’ wap/wtls_statesupport.c:1383: warning: no previous prototype for ‘add_all_handshake_data’ Thanks, Alexander Malysh Am 12.09.2010 um 13:15 schrieb Nikos Balkanas: Hi, Reporting from Solaris 10.5 amd64, 64bit compilation. Configured --with-wtls=openssl 1) Compilation: Clean. A couple of unrelated warnings fixed. Attaching patch. 2) Emulators used: a) Openwave SDK 6.2.2 wap: no problems (connection tested) b) Nokia NMBS 4.0: no problems (connection connectionless tested) Sites tested, following through links: http://wap.google.com http://wap.yahoo.com http://m.facebook Only facebook had a warning with nokia's emulator (b) about unsupported content. This was not observed with Openwave (a) and in any case it is related to wap, not wtls. The same happens in plain wtp communication. Overall a succesful merge. Thanks, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Kannel Devel devel@kannel.org Cc: Nikos Balkanas nbalka...@gmail.com Sent: Sunday, September 12, 2010 1:04 PM Subject: wtls branch merged Hi together, just merged and commited wtls branch
Re: wtls branch merged
This apparently is not specific to rc5, but includes all linking to openssl libraries, including kannel's https implementation. Not realy. In https RC5 is not prefered encryption algorithm like in WTLS. The RSA 1024 anon key is the most popular option in https. AFAIK it can be used only in rc5 algorithms for encryption/decryption. It is strange that openssl would include such information in their README rather than the LICENSE file. Apparently RSA securities have been acquired by EMC (SAN storage solutions). I have contacted them to give me the current status of their RC5 licensing. I will update this group when I get their response. Actually I mixed up a bit export restrictions with patents. The quote fom netsnmp was about export restrictions to AES and DES, which are used in SSL and cover https, not patents. BR, Nikos - Original Message - From: Milan P. Stanic m...@arvanta.net To: devel@kannel.org Sent: Monday, September 13, 2010 11:35 AM Subject: Re: wtls branch merged On Mon, 2010-09-13 at 07:44, Nikos Balkanas wrote: Actually nothing changes from the day before. wtls is not enabled by default. This submission just fixes a broken feature, doesn't provide a new one. The same way that providers built packages before (without wtls) the same way they will continue to do. They simply have one more option: wtls that works. More options never hurt anyone. Yes. You are right. This issue is old one as can be verified on the mail-archive from year 2002: http://www.mail-archive.com/de...@kannel.3glab.org/msg05446.html Lastly I stand by my original assessment. We are fully covered by openssl's license. RC5 is not implemented in wtls code, but is part of the openssl source. There used to be strict export restrictions, till the Reagan years, but they have been relaxed since then (1990). wtls is not restricted. Users may be restricted to download openssl alltogether, but this is not our concern, and in that case they can always configure kannel without encryption (SSL or wtls). Here is quote from the file /usr/share/doc/openssl/README.Debian (Debian distro, of course) regarding issue: PATENT ISSUES - Some algorithms used in the library are covered by patents. As a result, the following algorithms in libcrypto have been disabled: - RC5 - MDC2 - IDEA Also see the patents section in the README file. README which comes with openssl says something similar. PATENTS --- Various companies hold various patents for various algorithms in various locations around the world. _YOU_ are responsible for ensuring that your use of any algorithms is legal by checking if there are any patents in your country. The file contains some of the patents that we know about or are rumored to exist. This is not a definitive list. RSA Security holds software patents on the RC5 algorithm. If you intend to use this cipher, you must contact RSA Security for licensing conditions. Their web page is http://www.rsasecurity.com/. RC4 is a trademark of RSA Security, so use of this label should perhaps only be used with RSA Security's permission. The IDEA algorithm is patented by Ascom in Austria, France, Germany, Italy, Japan, the Netherlands, Spain, Sweden, Switzerland, UK and the USA. They should be contacted if that algorithm is to be used; their web page is http://www.ascom.ch/. NTT and Mitsubishi have patents and pending patents on the Camellia algorithm, but allow use at no charge without requiring an explicit licensing agreement: http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html So, I believe that the legal teams of various free operating system distributors have considered all issues about that and decided that is not safe to enable patented algorithms despite the fact that the implementation in openssl is licensed for free. After all, Kannel as it is now, is safe because distributors will not enable WTLS (I presume) and users who need WTLS have to compile openssl and kannel from the source, what is good practice anyway (but we can expect a lot of questions from novices in the lists). Maybe something about that should go in the FAQ. I don't want to tell that the Kannel should be changed. It is perfectly fine in the current state in regard with RC5 and WTLS, IMHO. Quoting from netsnmp (http://www.net-snmp.org/wiki/index.php/Crypto_Export_Restrictions): Our cryptography software portions (AES and DES) actually come from OpenSSL and are not implemented internally. Additionally, back when export restrictions were relaxed for open source software, all that is required for an open source package thats provides releases on a web site is to send proper notification to the US export office
Re: wtls branch merged
OK. I think you solved the RC5 issue. You need headers (openssl-devel) with rc5 enabled. About the rest: After configure --with-wtls=openssl you should end up with gw-config.h: /* Defined if we're using OpenSSL WTLS */ 211: #define HAVE_WTLS_OPENSSL 1 If not, enable it manually and rebuild. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Rene Kluwen' rene.klu...@chimit.nl; 'Nikos Balkanas' nbalka...@gmail.com; 'Alexander Malysh' amal...@kannel.org Cc: 'Kannel Devel' devel@kannel.org Sent: Sunday, September 12, 2010 3:38 PM Subject: RE: wtls branch merged Clearly I am missing something. After ./configure --with-wtls=openssl, I get: (openssl-devel is installed). /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:235: undefined reference to `private_key' /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:236: undefined reference to `private_key' /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:219: undefined reference to `x509_cert' /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:220: undefined reference to `x509_cert' libwap.a(wtls.o): In function `clientHello': /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:453: undefined reference to `wtls_choose_ciphersuite' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:472: undefined reference to `wtls_choose_clientkeyid' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:484: undefined reference to `wtls_choose_snmode' libwap.a(wtls.o): In function `wtls_event_handle': /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:302: undefined reference to `packet_contains_changecipherspec' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:314: undefined reference to `packet_contains_changecipherspec' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:328: undefined reference to `is_critical_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:338: undefined reference to `is_warning_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:397: undefined reference to `packet_is_application_data' libwap.a(wtls.o): In function `serverHello': /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:533: undefined reference to `wtls_get_random' libwap.a(wtls.o): In function `wtls_event_handle': /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:826: undefined reference to `wtls_decrypt_pdu_list' libwap.a(wtls.o): In function `wtls_event_handle': /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:77: undefined reference to `packet_contains_clienthello' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:480: undefined reference to `packet_contains_clienthello' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:210: undefined reference to `clienthellos_are_identical' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:231: undefined reference to `is_warning_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:240: undefined reference to `is_critical_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:281: undefined reference to `clienthellos_are_identical' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:421: undefined reference to `is_critical_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:431: undefined reference to `is_warning_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:502: undefined reference to `packet_contains_changecipherspec' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:514: undefined reference to `packet_contains_changecipherspec' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:528: undefined reference to `is_critical_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:538: undefined reference to `is_warning_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:302: undefined reference to `packet_contains_finished' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:302: undefined reference to `packet_contains_userdata' libwap.a(wtls.o): In function `exchange_keys': /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:627: undefined reference to `wtls_decrypt_key' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:638: undefined reference to `wtls_get_rsapublickey' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:654: undefined reference to `wtls_calculate_prf' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:710: undefined reference to `wtls_hash' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:710: undefined reference to `wtls_calculate_prf' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:751: undefined reference to `wtls_hash' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:751: undefined reference to `wtls_calculate_prf' libwap.a(wtls.o): In function `wtls_event_handle': /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:132: undefined reference to `wtls_get_rsapublickey' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:493: undefined reference to `packet_is_application_data' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:406: undefined
Re: wtls branch merged
Actually you get these errors because you didn't solve your rc5 issue and proceeded nevertheless. rc5 is needed for cryptography of wtls. Otherwise you won't be able to produce the keys. Either install openssl with rc5 enabled or build from sources with --enable-rc5. When you get these, your gw-config.h will set the correct directives and compile cleanly. After compilation, you will have to configure wtls group in your kannel.conf and produce a pair of self-signed RSA keys for that. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Rene Kluwen rene.klu...@chimit.nl; 'Alexander Malysh' amal...@kannel.org Cc: 'Kannel Devel' devel@kannel.org Sent: Sunday, September 12, 2010 4:45 PM Subject: Re: wtls branch merged OK. I think you solved the RC5 issue. You need headers (openssl-devel) with rc5 enabled. About the rest: After configure --with-wtls=openssl you should end up with gw-config.h: /* Defined if we're using OpenSSL WTLS */ 211: #define HAVE_WTLS_OPENSSL 1 If not, enable it manually and rebuild. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Rene Kluwen' rene.klu...@chimit.nl; 'Nikos Balkanas' nbalka...@gmail.com; 'Alexander Malysh' amal...@kannel.org Cc: 'Kannel Devel' devel@kannel.org Sent: Sunday, September 12, 2010 3:38 PM Subject: RE: wtls branch merged Clearly I am missing something. After ./configure --with-wtls=openssl, I get: (openssl-devel is installed). /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:235: undefined reference to `private_key' /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:236: undefined reference to `private_key' /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:219: undefined reference to `x509_cert' /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:220: undefined reference to `x509_cert' libwap.a(wtls.o): In function `clientHello': /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:453: undefined reference to `wtls_choose_ciphersuite' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:472: undefined reference to `wtls_choose_clientkeyid' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:484: undefined reference to `wtls_choose_snmode' libwap.a(wtls.o): In function `wtls_event_handle': /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:302: undefined reference to `packet_contains_changecipherspec' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:314: undefined reference to `packet_contains_changecipherspec' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:328: undefined reference to `is_critical_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:338: undefined reference to `is_warning_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:397: undefined reference to `packet_is_application_data' libwap.a(wtls.o): In function `serverHello': /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:533: undefined reference to `wtls_get_random' libwap.a(wtls.o): In function `wtls_event_handle': /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:826: undefined reference to `wtls_decrypt_pdu_list' libwap.a(wtls.o): In function `wtls_event_handle': /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:77: undefined reference to `packet_contains_clienthello' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:480: undefined reference to `packet_contains_clienthello' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:210: undefined reference to `clienthellos_are_identical' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:231: undefined reference to `is_warning_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:240: undefined reference to `is_critical_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:281: undefined reference to `clienthellos_are_identical' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:421: undefined reference to `is_critical_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:431: undefined reference to `is_warning_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:502: undefined reference to `packet_contains_changecipherspec' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:514: undefined reference to `packet_contains_changecipherspec' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:528: undefined reference to `is_critical_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:538: undefined reference to `is_warning_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:302: undefined reference to `packet_contains_finished' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:302: undefined reference to `packet_contains_userdata' libwap.a(wtls.o): In function `exchange_keys': /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:627: undefined reference to `wtls_decrypt_key' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:638: undefined reference to `wtls_get_rsapublickey' /home/system/adm_rene/svn
Re: wtls branch merged
But you don't need an rpm if you build from sources. You have all the includes and sources that you need. If you are referring about the binary kannel rpms, these are seriously outdated. Besides rpms are for the masses, and wtls is for the few...You should disable wtls when building for the masses. BR, Nikos . - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Nikos Balkanas' nbalka...@gmail.com; 'Alexander Malysh' amal...@kannel.org Cc: 'Kannel Devel' devel@kannel.org Sent: Sunday, September 12, 2010 5:29 PM Subject: RE: wtls branch merged Okay... suppose you can build it in one step. That still won't solve the rpm dependency. == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Sunday, 12 September, 2010 16:23 To: Rene Kluwen; 'Alexander Malysh' Cc: 'Kannel Devel' Subject: Re: wtls branch merged Actually it is not that bad. Openssl compiles from sources in one step: config threads no-krb5 shared enable-rc5 --prefix=/usr/local/64 Clean, nothing to it. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Nikos Balkanas' nbalka...@gmail.com; 'Alexander Malysh' amal...@kannel.org Cc: 'Kannel Devel' devel@kannel.org Sent: Sunday, September 12, 2010 5:12 PM Subject: RE: wtls branch merged Hmmm... too much of a bother. I wonder if anybody still uses wap nowadays. Maybe in combination with mbuni, wap might be convenient. But even then, people won't use wtls. @Alexander: What dependencies does the pre-compiled package need when using this 'feature'? Because otherwise nobody (at least I won't) be able to install it from rpm, because the CentOS packages include openssl without RC5 support. Not sure about other distributions. == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Sunday, 12 September, 2010 15:58 To: Rene Kluwen; 'Alexander Malysh' Cc: 'Kannel Devel' Subject: Re: wtls branch merged Actually you get these errors because you didn't solve your rc5 issue and proceeded nevertheless. rc5 is needed for cryptography of wtls. Otherwise you won't be able to produce the keys. Either install openssl with rc5 enabled or build from sources with --enable-rc5. When you get these, your gw-config.h will set the correct directives and compile cleanly. After compilation, you will have to configure wtls group in your kannel.conf and produce a pair of self-signed RSA keys for that. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Rene Kluwen rene.klu...@chimit.nl; 'Alexander Malysh' amal...@kannel.org Cc: 'Kannel Devel' devel@kannel.org Sent: Sunday, September 12, 2010 4:45 PM Subject: Re: wtls branch merged OK. I think you solved the RC5 issue. You need headers (openssl-devel) with rc5 enabled. About the rest: After configure --with-wtls=openssl you should end up with gw-config.h: /* Defined if we're using OpenSSL WTLS */ 211: #define HAVE_WTLS_OPENSSL 1 If not, enable it manually and rebuild. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Rene Kluwen' rene.klu...@chimit.nl; 'Nikos Balkanas' nbalka...@gmail.com; 'Alexander Malysh' amal...@kannel.org Cc: 'Kannel Devel' devel@kannel.org Sent: Sunday, September 12, 2010 3:38 PM Subject: RE: wtls branch merged Clearly I am missing something. After ./configure --with-wtls=openssl, I get: (openssl-devel is installed). /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:235: undefined reference to `private_key' /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:236: undefined reference to `private_key' /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:219: undefined reference to `x509_cert' /home/system/adm_rene/svn/pam/trunk/gw/wapbox.c:220: undefined reference to `x509_cert' libwap.a(wtls.o): In function `clientHello': /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:453: undefined reference to `wtls_choose_ciphersuite' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:472: undefined reference to `wtls_choose_clientkeyid' /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:484: undefined reference to `wtls_choose_snmode' libwap.a(wtls.o): In function `wtls_event_handle': /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:302: undefined reference to `packet_contains_changecipherspec' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:314: undefined reference to `packet_contains_changecipherspec' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:328: undefined reference to `is_critical_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:338: undefined reference to `is_warning_alert' /home/system/adm_rene/svn/pam/trunk/wap/wtls_state-decl.h:397: undefined reference to `packet_is_application_data' libwap.a(wtls.o): In function `serverHello': /home/system/adm_rene/svn/pam/trunk/wap/wtls.c:533: undefined reference to `wtls_get_random' libwap.a(wtls.o): In function `wtls_event_handle': /home/system
Re: wtls branch merged
Actually nothing changes from the day before. wtls is not enabled by
default. This submission just fixes a broken feature, doesn't provide a new
one. The same way that providers built packages before (without wtls) the
same way they will continue to do. They simply have one more option: wtls
that works. More options never hurt anyone.
Lastly I stand by my original assessment. We are fully covered by openssl's
license. RC5 is not implemented in wtls code, but is part of the openssl
source. There used to be strict export restrictions, till the Reagan years,
but they have been relaxed since then (1990). wtls is not restricted. Users
may be restricted to download openssl alltogether, but this is not our
concern, and in that case they can always configure kannel without
encryption (SSL or wtls).
Quoting from netsnmp
(http://www.net-snmp.org/wiki/index.php/Crypto_Export_Restrictions):
Our cryptography software portions (AES and DES) actually come from OpenSSL
and are not implemented internally. Additionally, back when export
restrictions were relaxed for open source software, all that is required for
an open source package thats provides releases on a web site is to send
proper notification to the US export office (which we did), but the export
office does not respond to such queries (they only log it).
It's up to manufactures of devices and software that intend to sell their
devices over-seas to go through proper paperwork for the device that
includes open source software. IE, nothing we could give you would satisfy
your own requirements. We strongly suggest you consult with an export
control lawyer as this community is not a legal service that you can count
on.
This apparently is not specific to rc5, but includes all linking to openssl
libraries, including kannel's https implementation.
Hope this clears up things,
Nikos
- Original Message -
From: Milan P. Stanic m...@arvanta.net
To: devel@kannel.org
Sent: Sunday, September 12, 2010 8:46 PM
Subject: Re: wtls branch merged
To reply myself:
On Sun, 2010-09-12 at 19:36, Milan P. Stanic wrote:
On Sun, 2010-09-12 at 20:13, Nikos Balkanas wrote:
I don't believe so. The openssl RC5 is licensed under the openssl
license (similar to kannel's).
http://www.openssl.org/source/license.html
Licence is for software implementation and it is free but the RC5
algorithm is patented, AFAIK. I'm not a lawyer and I don't all details
but I think that the RC5 cannot be used in USA (and possible other
countries) without licence from the patent holder (in that case RSA
Data Security).
A quick look at WTLS specification shows that the RC5 isn't mandatory
but optional.
Just found this Press Release
http://www.rsa.com/press_release.aspx?id=172
which states that RC5
cite
algorithm that is specified as should be supported by all WTLS clients
and servers by the WAP Forum for WTLS environments.
/cite
So, I was wrong. But the issue remains. I suspect that any distributor
will have Kannel package with WTLS enabled in their repositories.
Yes it is necessary, as mentioned in a previous mail. Incorrectly I
said that it is used in key generation. Actually it is one of the 3
cipher algorithms used for content according to the wtls spec:
enum bulk_algorithms {
NULL_bulk,
RC5_CBC_40,
RC5_CBC_56,
RC5_CBC,
DES_CBC_40,
DES_CBC,
TRIPLE_DES_CBC_EDE,
IDEA_CBC_40,
IDEA_CBC_56,
IDEA_CBC
};
This implementation supports the RC5 and DES algorithms. Not the IDEA.
Kannel already has wtls with RC5 for all these years, except that it
doesn't work.
BR,
Nikos
- Original Message - From: Milan P. Stanic
m...@arvanta.net
To: devel@kannel.org
Sent: Sunday, September 12, 2010 7:42 PM
Subject: Re: wtls branch merged
On Sun, 2010-09-12 at 17:35, Nikos Balkanas wrote:
But you don't need an rpm if you build from sources. You have all
the includes and sources that you need.
If you are referring about the binary kannel rpms, these are
seriously outdated. Besides rpms are for the masses, and wtls is for
the few...You should disable wtls when building for the masses.
It could be problem for distributors (RH, Debian, Suse, xxxBSD and
others) if they cannot distribute Kannel with WTLS enabled because RC5
is patented and distributors don't want to go court.
Is the RC5 mandatory for WTLS?
Nikos
.
- Original Message - From: Rene Kluwen
rene.klu...@chimit.nl
To: 'Nikos Balkanas' nbalka...@gmail.com; 'Alexander Malysh'
amal...@kannel.org
Cc: 'Kannel Devel' devel@kannel.org
Sent: Sunday, September 12, 2010 5:29 PM
Subject: RE: wtls branch merged
Okay... suppose you can build it in one step.
That still won't solve the rpm dependency.
== Rene
-Original Message-
From: Nikos Balkanas [mailto:nbalka...@gmail.com]
Sent: Sunday, 12 September, 2010 16:23
To: Rene Kluwen; 'Alexander Malysh'
Cc: 'Kannel Devel'
Subject
Re: Release plan
Looks good. +1 Nikos - Original Message - From: Rene Kluwen To: 'Alejandro Guerrieri' Cc: 'Alejandro Guerrieri' ; 'Kannel Devel' Sent: Friday, September 10, 2010 11:07 PM Subject: RE: Release plan Not sure if anybody noticed. But not all sms messages were acked properly before, leaving messages in the message store. I stuck across this, while implementing sqlbox for a client. This patch solves the problem. I would like to see it implemented before next devel-release. Votes? == Rene From: Alejandro Guerrieri [mailto:aguerri...@kannel.org] Sent: Friday, 10 September, 2010 20:30 To: Rene Kluwen Cc: 'Alejandro Guerrieri'; 'Kannel Devel' Subject: Re: Release plan Yes, that was what I was thinking also. I'll try with an older version of Sqlbox and latest SVN to see if there's any differences. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 10/09/2010, at 20:12, Rene Kluwen wrote: If it has something to do with acks, then this might be the case. == Rene From: Alejandro Guerrieri [mailto:alejandro.guerri...@gmail.com] Sent: Friday, 10 September, 2010 19:23 To: Rene Kluwen Cc: Alexander Malysh; Victor Luchitz; Kannel Devel Subject: Re: Release plan Wow, that's odd. Perhaps one of the latest patches solved it? I'll try to reproduce it this weekend to be sure. Regards, Alex On Fri, Sep 10, 2010 at 7:16 PM, Rene Kluwen rene.klu...@chimit.nl wrote: Just sent a million messages via Nikos' stress test. And they all arrived, without losing a single message. == Rene 2010/9/10 Alexander Malysh amal...@kannel.org: Hi Rene, we can delay release for one more week but not longer. If you think it's better to delay let us know. Thanks, Alexander Malysh Am 09.09.2010 um 17:46 schrieb Rene Kluwen: @Alejandro: Not sure if it is a show stopper. It could be in the section known bugs. @Alexander: Even though I am +1 for a new release (the older release has been a while) next weekend is really a short notice. @ both: I will investigate the MO problem of sqlbox. == Rene -Original Message- From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Alejandro Guerrieri Sent: Thursday, 09 September, 2010 15:34 To: Alexander Malysh Cc: Kannel Devel Subject: Re: Release plan On Sqlbox, we have that unsolved issue that arose when the meta-data branch was applied on Kannel. That's a showstopper imho. To describe the problem further: The issue arises when sqlbox is between bearerbox and smsbox, and it's only observed on MO traffic. When you receive just a few MO messages, it works fine. However, if you sustain a moderate level of inbound messages, some of them are lost. The logs shows nothing relevant. The bug was observed by many users on the list. I've also confirmed it's happening. I'm not sure if it's really an sqlbox bug, or if it's really on Kannel's side. The problem doesn't occur if you use an older version of Kannel (pre meta-data). Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 09/09/2010, at 15:12, Alexander Malysh wrote: Hi together, we are plan to release new Kannel developer version. For this task we have at this point in time only one patch to merge, wtls branch. We also plan to release sqlbox opensmppbox with Kannel. Rene Alex: could you please check status of both boxes and let us know whether you agree to release with Kannel and whether boxes ready for release? The plan would be: 1) this weekend WTLS branch merge 2) next week testing 3) next weekend release but here depends on Stipe Please let me know which not commited patches should go in and whether somebody sees showstopper. Thanks, Alexander Malysh -- Best regards, Victor Luchitz
Re: Patch: gw/urltrans.c
Maybe, but AFAIK this is a perl expression and should be used when configured with pcre, not regex... BR, Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: Milan P. Stanic m...@arvanta.net; devel@kannel.org Sent: Tuesday, August 31, 2010 12:23 PM Subject: Re: Patch: gw/urltrans.c Of course you can do the [Aa][Bb][Cc] trick! That was the reason while Alex and I told you that case sensitivity mattered and we were against your point about disabling it on the first place... While this method works fine, it's a lot harder to maintain. Being able to use i would simplify things imho. Not a show-stopper, but would improve things. A similar issue occurs with latin accents (and also the ρ in spanish). You usually want to accept accented words as well. Time ago, we solved it by using [Aaα] [Eeι] ... [NnΡρ] etc. Of course this wouldn't be solved with the i switch and would still need the bracket trick to work, but at least it would be simpler and more readable than having each and every letter between brackets in upper and lower case. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 31/08/2010, at 00:40, Nikos Balkanas wrote: Not really. kannel normally uses regex for regexp. If compiled with pcre, then it will expand patterns to include pcre. However, for simple folks, as Alex M indicated, the possibility with plain regex is still there: keyword-regex = [Cc][Aa][Pp][Ss] will match all case permutations of Caps. No need for i switches. It should be more efficient as well. BR, Nikos - Original Message - From: Alejandro Guerrieri aguerri...@kannel.org To: Milan P. Stanic m...@arvanta.net Cc: devel@kannel.org Sent: Monday, August 30, 2010 7:36 PM Subject: Re: Patch: gw/urltrans.c Afaik, Kannel uses pcre for regexps. Not sure if it's possible to pass parameters as it is now, but seems like a possible course of action. Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 30/08/2010, at 18:33, Milan P. Stanic wrote: On Mon, 2010-08-30 at 17:33, Rene Kluwen wrote: I agree here. Regexps are by default not case sensitive, unless the i-modifier is set. Isn't internal option setting an option? Like they do here: http://nl2.php.net/manual/en/regexp.reference.internal-options.php Example: (?i:foo) This example is PCRE, I think. Kannel regex is POSIX compatible. -- Kind regards, Milan -- Arvanta, IT Securityhttp://www.arvanta.net Please do not send me e-mail containing HTML code.
Re: Patch: gw/urltrans.c
Hi, Please see comments inlined. Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: devel@kannel.org Sent: Monday, August 30, 2010 12:08 PM Subject: Re: Patch: gw/urltrans.c Hi, why do you change explicit configuration to something implicit? I don't understand. Please explain what is explicit and what is implicit. user have to decide whether to use keyword or keyword-regex and if both given it's error and was indicated so. Just trying to align source with documentation, by popular demand. About the case sensitivity, I would like to give a user possibility to decide. The policy should be: - if keyword given make it case insensitive (just backwards compatibility) - if keyword-regex given it's case sensitive That's confusing for anyone. How do you know what users want? It could blow the list off. I think everything should be treated equally. keyword-regex is just an extention of keyword. Rules applying to the first should apply to the second as well. Any votes from the list? So the patch should be: - remove octstr_convert_range from find_translation - add REG_ICASE for keyword - documentation No problem, but first please address my points. Thanks, Alexander Malysh Am 27.08.2010 um 02:24 schrieb Nikos Balkanas: Added some needed initialization. Sorry about that. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Cc: Rene Kluwen rene.klu...@chimit.nl; 'Alvaro Cornejo' cornejo.alv...@gmail.com Sent: Friday, August 27, 2010 1:30 AM Subject: Re: Patch: gw/urltrans.c Case insensitivity is observed in the code. It just lacks in configuration. I changed patch to match documentation: 1) When given both keyword-regex and keyword, it will just prefer keyword-regex without complains (according to UG). 2) It will accept any case in configuration for both keyword and keyword-regex and do case incensitive matching. 3) Fixed a diagnostic that was pooping up evrywhere during matches. Enjoy, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Alvaro Cornejo' cornejo.alv...@gmail.com; 'Nikos Balkanas' nbalka...@gmail.com Cc: devel@kannel.org Sent: Thursday, August 26, 2010 5:10 PM Subject: RE: Patch: gw/urltrans.c A lot of hand sets, nowadays automatically convert the first letter to uppercase whilst typing an sms message. So I think case-insensivity is not a bad thing? == Rene -Original Message- From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Alvaro Cornejo Sent: Thursday, 26 August, 2010 15:44 To: Nikos Balkanas Cc: devel@kannel.org Subject: Re: Patch: gw/urltrans.c It should then be noted in the user guide. Otherwise we will continue receiving this questions over and over. |--- --| 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 2010/8/26 Nikos Balkanas nbalka...@gmail.com: I don't know if this is really necessary. Just using lower case in the keyword-regex pattern will work as well. Please disregard. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Sent: Thursday, August 26, 2010 8:02 AM Subject: Patch: gw/urltrans.c Hi, Currently keyword-regex is configured to only do exact case matches. This is in contrast to keyword matching, which is case incensitive. Additionaly, input string input string is converted to lower case for matching. This will cause all keyword-regex patterns with capital letters to fail. This patch corrects that by inittializing keyword-regex to case incensitive matching. Reported by Mike Cariotoglou BR, Nikos urltrans.diff
Re: Patch: gw/urltrans.c
All right. Here it is. Enjoy, Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: devel@kannel.org Sent: Monday, August 30, 2010 5:21 PM Subject: Re: Patch: gw/urltrans.c see inlined... Am 30.08.2010 um 16:06 schrieb Nikos Balkanas: Hi, Please see comments inlined. Nikos - Original Message - From: Alexander Malysh amal...@kannel.org To: Nikos Balkanas nbalka...@gmail.com Cc: devel@kannel.org Sent: Monday, August 30, 2010 12:08 PM Subject: Re: Patch: gw/urltrans.c Hi, why do you change explicit configuration to something implicit? I don't understand. Please explain what is explicit and what is implicit. use have to decide what to use keyword or keyword-regex and both settings just not allowed and is error. Now it also indicated so. With you patch you make decision for user to use keyword or keyword-regex... user have to decide whether to use keyword or keyword-regex and if both given it's error and was indicated so. Just trying to align source with documentation, by popular demand. About the case sensitivity, I would like to give a user possibility to decide. The policy should be: - if keyword given make it case insensitive (just backwards compatibility) - if keyword-regex given it's case sensitive That's confusing for anyone. How do you know what users want? It could blow the list off. I think everything should be treated equally. keyword-regex is just an extention of keyword. Rules applying to the first should apply to the second as well. no, keyword-regex is replacement for keyword and keyword is there only for backwards compatibility. And keyword-regex was extra set to be case sensitive because some users want it so and if you make it case insensitive user will not be able to do so. Other way around works, e.g. you will match OK: [o][O][kK] I see a convert_range in find_translation as a bug... Any votes from the list? So the patch should be: - remove octstr_convert_range from find_translation - add REG_ICASE for keyword - documentation No problem, but first please address my points. Thanks, Alexander Malysh Am 27.08.2010 um 02:24 schrieb Nikos Balkanas: Added some needed initialization. Sorry about that. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Cc: Rene Kluwen rene.klu...@chimit.nl; 'Alvaro Cornejo' cornejo.alv...@gmail.com Sent: Friday, August 27, 2010 1:30 AM Subject: Re: Patch: gw/urltrans.c Case insensitivity is observed in the code. It just lacks in configuration. I changed patch to match documentation: 1) When given both keyword-regex and keyword, it will just prefer keyword-regex without complains (according to UG). 2) It will accept any case in configuration for both keyword and keyword-regex and do case incensitive matching. 3) Fixed a diagnostic that was pooping up evrywhere during matches. Enjoy, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Alvaro Cornejo' cornejo.alv...@gmail.com; 'Nikos Balkanas' nbalka...@gmail.com Cc: devel@kannel.org Sent: Thursday, August 26, 2010 5:10 PM Subject: RE: Patch: gw/urltrans.c A lot of hand sets, nowadays automatically convert the first letter to uppercase whilst typing an sms message. So I think case-insensivity is not a bad thing? == Rene -Original Message- From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Alvaro Cornejo Sent: Thursday, 26 August, 2010 15:44 To: Nikos Balkanas Cc: devel@kannel.org Subject: Re: Patch: gw/urltrans.c It should then be noted in the user guide. Otherwise we will continue receiving this questions over and over. |--- --| 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 2010/8/26 Nikos Balkanas nbalka...@gmail.com: I don't know if this is really necessary. Just using lower case in the keyword-regex pattern will work as well. Please disregard. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Sent: Thursday, August 26, 2010 8:02 AM Subject: Patch: gw/urltrans.c Hi, Currently keyword-regex is configured to only do exact case matches. This is in contrast to keyword matching, which is case incensitive. Additionaly, input string input string is converted to lower case for matching. This will cause all keyword-regex patterns with capital letters to fail. This patch corrects that by inittializing keyword-regex to case incensitive matching. Reported by Mike Cariotoglou BR, Nikos urltrans.diff kannel.diff Description: Binary data
Re: Patch: gw/urltrans.c
Case insensitivity is observed in the code. It just lacks in configuration. I changed patch to match documentation: 1) When given both keyword-regex and keyword, it will just prefer keyword-regex without complains (according to UG). 2) It will accept any case in configuration for both keyword and keyword-regex and do case incensitive matching. 3) Fixed a diagnostic that was pooping up evrywhere during matches. Enjoy, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Alvaro Cornejo' cornejo.alv...@gmail.com; 'Nikos Balkanas' nbalka...@gmail.com Cc: devel@kannel.org Sent: Thursday, August 26, 2010 5:10 PM Subject: RE: Patch: gw/urltrans.c A lot of hand sets, nowadays automatically convert the first letter to uppercase whilst typing an sms message. So I think case-insensivity is not a bad thing? == Rene -Original Message- From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Alvaro Cornejo Sent: Thursday, 26 August, 2010 15:44 To: Nikos Balkanas Cc: devel@kannel.org Subject: Re: Patch: gw/urltrans.c It should then be noted in the user guide. Otherwise we will continue receiving this questions over and over. |--- --| 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 2010/8/26 Nikos Balkanas nbalka...@gmail.com: I don't know if this is really necessary. Just using lower case in the keyword-regex pattern will work as well. Please disregard. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Sent: Thursday, August 26, 2010 8:02 AM Subject: Patch: gw/urltrans.c Hi, Currently keyword-regex is configured to only do exact case matches. This is in contrast to keyword matching, which is case incensitive. Additionaly, input string input string is converted to lower case for matching. This will cause all keyword-regex patterns with capital letters to fail. This patch corrects that by inittializing keyword-regex to case incensitive matching. Reported by Mike Cariotoglou BR, Nikos urltrans.diff Description: Binary data
Re: Patch: gw/urltrans.c
Added some needed initialization. Sorry about that. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Cc: Rene Kluwen rene.klu...@chimit.nl; 'Alvaro Cornejo' cornejo.alv...@gmail.com Sent: Friday, August 27, 2010 1:30 AM Subject: Re: Patch: gw/urltrans.c Case insensitivity is observed in the code. It just lacks in configuration. I changed patch to match documentation: 1) When given both keyword-regex and keyword, it will just prefer keyword-regex without complains (according to UG). 2) It will accept any case in configuration for both keyword and keyword-regex and do case incensitive matching. 3) Fixed a diagnostic that was pooping up evrywhere during matches. Enjoy, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Alvaro Cornejo' cornejo.alv...@gmail.com; 'Nikos Balkanas' nbalka...@gmail.com Cc: devel@kannel.org Sent: Thursday, August 26, 2010 5:10 PM Subject: RE: Patch: gw/urltrans.c A lot of hand sets, nowadays automatically convert the first letter to uppercase whilst typing an sms message. So I think case-insensivity is not a bad thing? == Rene -Original Message- From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Alvaro Cornejo Sent: Thursday, 26 August, 2010 15:44 To: Nikos Balkanas Cc: devel@kannel.org Subject: Re: Patch: gw/urltrans.c It should then be noted in the user guide. Otherwise we will continue receiving this questions over and over. |--- --| 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 2010/8/26 Nikos Balkanas nbalka...@gmail.com: I don't know if this is really necessary. Just using lower case in the keyword-regex pattern will work as well. Please disregard. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Sent: Thursday, August 26, 2010 8:02 AM Subject: Patch: gw/urltrans.c Hi, Currently keyword-regex is configured to only do exact case matches. This is in contrast to keyword matching, which is case incensitive. Additionaly, input string input string is converted to lower case for matching. This will cause all keyword-regex patterns with capital letters to fail. This patch corrects that by inittializing keyword-regex to case incensitive matching. Reported by Mike Cariotoglou BR, Nikos urltrans.diff Description: Binary data
Re: Open smppbox queues - priority queues
Can fakesmpp help? The test wouldn't be isolated, which would be ideal, but I need to implement an ESME client for that. But maybe it could show in: fakesmpp - bb1 - smppbox - bb2 - fakesmpp You will need to feed fake smpp with a copy of bb1's configuration, but with smsbox-port set to bb2. If not, let me know and I will add support for smppbox. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Nikos Balkanas' nbalka...@gmail.com; devel@kannel.org Sent: Wednesday, August 25, 2010 2:41 PM Subject: RE: Open smppbox queues - priority queues Before, I could not test properly. Just got my office system Internet connection back yesterday, since we've moved to another place. Testing via a GSM Internet link is not quite ideal :)... So I've got to think of some kind of bench mark (ideas?) to compare the different implementations with. == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Wednesday, 25 August, 2010 00:53 To: Rene Kluwen; devel@kannel.org Subject: Re: Open smppbox queues - priority queues Hi Rene, I am really confused here. I am still waiting for an answer. Are queues slowing down performance or not? If yes by what amount? Priority queues are the real hogger, especially the larger they get. I don't think that this is necessary, since they are prioritized in bb. I think since they are such a performance degradation, they shouldn't be implemented more than once. Lastly consider that if you put priority queues in smppbox, there will always be people thinking that they do not work the way they are supposed to ;-) BR, Nikos - Original Message - From: Rene Kluwen To: devel@kannel.org Sent: Tuesday, August 24, 2010 6:00 PM Subject: Open smppbox queues - priority queues Here again another patch, which uses priority queues. Looking for a way to come up with representative performance figures so we can decide which implementation is best. == Rene
Re: Open smppbox queues - priority queues
Outgoing queues are better than incoming for performance... BR, Nikos - Original Message - From: Rene Kluwen To: 'Alexander Malysh' Cc: devel@kannel.org Sent: Wednesday, August 25, 2010 6:09 PM Subject: RE: Open smppbox queues - priority queues True… As I already stated earlier, I think the best setup is the way it is now already. So in that way, I agree with you. The queues that I implemented are for academic purposes. Some people on the list reported bad performance. So I wanted to check if other implementations (i.e. with queues) give better performance results. == Rene From: Alexander Malysh [mailto:malys...@googlemail.com] On Behalf Of Alexander Malysh Sent: Wednesday, 25 August, 2010 13:56 To: Rene Kluwen Cc: devel@kannel.org Subject: Re: Open smppbox queues - priority queues Hi Rene, as I already said, I don't think you need any queue. bearerbox implements already queuing for you. And with queuing you have to wait for ack anyway because you may not be able to handle temp. nacks with DLR approach. Thanks, Alexander Malysh Am 24.08.2010 um 17:00 schrieb Rene Kluwen: Here again another patch, which uses priority queues. Looking for a way to come up with representative performance figures so we can decide which implementation is best. == Rene smppbox_prioqueues_2.patch
Patch: gw/urltrans.c
Hi, Currently keyword-regex is configured to only do exact case matches. This is in contrast to keyword matching, which is case incensitive. Additionaly, input string input string is converted to lower case for matching. This will cause all keyword-regex patterns with capital letters to fail. This patch corrects that by inittializing keyword-regex to case incensitive matching. Reported by Mike Cariotoglou BR, Nikos urltrans.diff Description: Binary data
Re: Patch: gw/urltrans.c
I don't know if this is really necessary. Just using lower case in the keyword-regex pattern will work as well. Please disregard. BR, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: devel@kannel.org Sent: Thursday, August 26, 2010 8:02 AM Subject: Patch: gw/urltrans.c Hi, Currently keyword-regex is configured to only do exact case matches. This is in contrast to keyword matching, which is case incensitive. Additionaly, input string input string is converted to lower case for matching. This will cause all keyword-regex patterns with capital letters to fail. This patch corrects that by inittializing keyword-regex to case incensitive matching. Reported by Mike Cariotoglou BR, Nikos
Re: smppbox bulk sms: slow reception from a client
The threads should not be it. Otherwise all multithreaded programs would be in trouble ;-). Anyway, they usually increase performance, reducing wait I/O and taking advantage of every bit of free CPU. What you put in the threads has an effect, but it is minimal. You just do a pointer append, and pointer move. You have muteces, allright, but they should not collide in your code. What kind of performance degradation are you talking about? BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Nikos Balkanas' nbalka...@gmail.com; 'Hillel Bilman' hbil...@ecommunicate.biz Cc: devel@kannel.org Sent: Monday, August 23, 2010 3:22 PM Subject: RE: smppbox bulk sms: slow reception from a client The performance penalty is probably because of the overhead of the queues and 2 extra producer threads that take care of putting the messages in the queue. And yes... you are right about the round trip of the ack that is the most probably cause of the delay. I am also working on a priority queue implementation. The big question will be: Which is the implementation with the best results? Personally I think the best way to handle things is how things are now. But will do some more testing, next weekend. == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Monday, 23 August, 2010 03:07 To: Rene Kluwen; 'Hillel Bilman' Cc: devel@kannel.org Subject: Re: smppbox bulk sms: slow reception from a client You didn't understand me. I asked about the performance penalty in the queued patch, and what was responsible for it, because i couldn't see it. You don't have a dict for stored_acks in there. That's the other patch, which I agree it is faster with immediate acks. But even there, it is not the dict the problem, it is a hash table after all, but the round-trip you are doing to get the ack. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Nikos Balkanas' nbalka...@gmail.com; 'Hillel Bilman' hbil...@ecommunicate.biz Cc: devel@kannel.org Sent: Monday, August 23, 2010 12:27 AM Subject: RE: smppbox bulk sms: slow reception from a client I think that if I profile, the bottle neck will be the dict that I use to store acks. But not 100% sure. == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Sunday, 22 August, 2010 23:25 To: Rene Kluwen; 'Hillel Bilman' Cc: devel@kannel.org Subject: Re: smppbox bulk sms: slow reception from a client Let's see. On one hand you have a serial design, on the other a multithreaded one. OK, not exactly multithreaded, but queued which will get you ~80% of a true multithreaded design. Which one is faster, and more robust under heavy traffic? How much of a delay are you talking about? Any idea what is the offending call(s)? BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Hillel Bilman' hbil...@ecommunicate.biz Cc: devel@kannel.org Sent: Sunday, August 22, 2010 9:15 PM Subject: RE: smppbox bulk sms: slow reception from a client I knew this wasn't a good idea. The overall performance is a lot slower now. Please find attached an smppbox implementation including queues (patch to svn trunk). I am myself -1 for this patch. But here you have it, for the ones that want to try. == Rene -Original Message- From: Hillel Bilman [mailto:hbil...@ecommunicate.biz] Sent: Sunday, 22 August, 2010 18:59 To: rene.klu...@chimit.nl Cc: devel@kannel.org Subject: RE: smppbox bulk sms: slow reception from a client Thanks for the update and to Chimit for smppbox in general. To take up the discussion from the user group, you mentioned a great idea to have another set of queues that smppbox only uses. To add to this, it would be great to have the same set of queues where you can set priority and range 0-3 is allowed. Then this prevents your smppbox flooding bearer box and also you can far more easily isolate problems from smppbox. Regards
Re: smppbox bulk sms: slow reception from a client
Looks good. This is how it should be. But you need queues to implement this, otherwise if bb goes down you will loose the SMS, while reporting to the ESME that it was accepted. Besides it is unrelated to queue functionality, so why do you compare it to queues? Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: devel@kannel.org Sent: Sunday, August 22, 2010 10:03 PM Subject: FW: smppbox bulk sms: slow reception from a client Sorry, forgot to copy the list. -Original Message- From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Sunday, 22 August, 2010 20:53 To: 'Hillel Bilman'; 'Davit Mirzoyan'; 'Alvaro Cornejo'; 'Nikos Balkanas'; 'ad...@impexrur.pl' Subject: RE: smppbox bulk sms: slow reception from a client For the ones who are worried about smppbox performance. Here is something that I believe in better than the queue implementation (like in my earlier post of today). At some point in time, I made smppbox wait for a bearerbox ack before acknowledging the message back to the ESME and vice versa. In the following patch, I turned that back again. I immediately acknowledge the message, irregardless what it's relaying status later is going to be. If you have problems with smppbox and/or slow performance, this patch might be for you. I made the patch in such a manner that it is easy to make a configuration option for this, in a later stage. Please test. == Rene -Original Message- From: Hillel Bilman [mailto:hbil...@ecommunicate.biz] Sent: Sunday, 22 August, 2010 18:59 To: rene.klu...@chimit.nl Cc: devel@kannel.org Subject: RE: smppbox bulk sms: slow reception from a client Thanks for the update and to Chimit for smppbox in general. To take up the discussion from the user group, you mentioned a great idea to have another set of queues that smppbox only uses. To add to this, it would be great to have the same set of queues where you can set priority and range 0-3 is allowed. Then this prevents your smppbox flooding bearer box and also you can far more easily isolate problems from smppbox. Regards
Re: smppbox bulk sms: slow reception from a client
Let's see. On one hand you have a serial design, on the other a multithreaded one. OK, not exactly multithreaded, but queued which will get you ~80% of a true multithreaded design. Which one is faster, and more robust under heavy traffic? How much of a delay are you talking about? Any idea what is the offending call(s)? BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Hillel Bilman' hbil...@ecommunicate.biz Cc: devel@kannel.org Sent: Sunday, August 22, 2010 9:15 PM Subject: RE: smppbox bulk sms: slow reception from a client I knew this wasn't a good idea. The overall performance is a lot slower now. Please find attached an smppbox implementation including queues (patch to svn trunk). I am myself -1 for this patch. But here you have it, for the ones that want to try. == Rene -Original Message- From: Hillel Bilman [mailto:hbil...@ecommunicate.biz] Sent: Sunday, 22 August, 2010 18:59 To: rene.klu...@chimit.nl Cc: devel@kannel.org Subject: RE: smppbox bulk sms: slow reception from a client Thanks for the update and to Chimit for smppbox in general. To take up the discussion from the user group, you mentioned a great idea to have another set of queues that smppbox only uses. To add to this, it would be great to have the same set of queues where you can set priority and range 0-3 is allowed. Then this prevents your smppbox flooding bearer box and also you can far more easily isolate problems from smppbox. Regards
Re: smppbox bulk sms: slow reception from a client
You didn't understand me. I asked about the performance penalty in the queued patch, and what was responsible for it, because i couldn't see it. You don't have a dict for stored_acks in there. That's the other patch, which I agree it is faster with immediate acks. But even there, it is not the dict the problem, it is a hash table after all, but the round-trip you are doing to get the ack. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Nikos Balkanas' nbalka...@gmail.com; 'Hillel Bilman' hbil...@ecommunicate.biz Cc: devel@kannel.org Sent: Monday, August 23, 2010 12:27 AM Subject: RE: smppbox bulk sms: slow reception from a client I think that if I profile, the bottle neck will be the dict that I use to store acks. But not 100% sure. == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Sunday, 22 August, 2010 23:25 To: Rene Kluwen; 'Hillel Bilman' Cc: devel@kannel.org Subject: Re: smppbox bulk sms: slow reception from a client Let's see. On one hand you have a serial design, on the other a multithreaded one. OK, not exactly multithreaded, but queued which will get you ~80% of a true multithreaded design. Which one is faster, and more robust under heavy traffic? How much of a delay are you talking about? Any idea what is the offending call(s)? BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Hillel Bilman' hbil...@ecommunicate.biz Cc: devel@kannel.org Sent: Sunday, August 22, 2010 9:15 PM Subject: RE: smppbox bulk sms: slow reception from a client I knew this wasn't a good idea. The overall performance is a lot slower now. Please find attached an smppbox implementation including queues (patch to svn trunk). I am myself -1 for this patch. But here you have it, for the ones that want to try. == Rene -Original Message- From: Hillel Bilman [mailto:hbil...@ecommunicate.biz] Sent: Sunday, 22 August, 2010 18:59 To: rene.klu...@chimit.nl Cc: devel@kannel.org Subject: RE: smppbox bulk sms: slow reception from a client Thanks for the update and to Chimit for smppbox in general. To take up the discussion from the user group, you mentioned a great idea to have another set of queues that smppbox only uses. To add to this, it would be great to have the same set of queues where you can set priority and range 0-3 is allowed. Then this prevents your smppbox flooding bearer box and also you can far more easily isolate problems from smppbox. Regards
Re: Sqlbox acks
What about some sanity checks? NULL msg, corrupted msg (cannot be unpacked), etc.? Also do you check about heartbeat admin msgs? bb thinks it is an smsbox... Otherwise +1 BR, Nikos - Original Message - From: Rene Kluwen To: 'Alejandro Guerrieri' Cc: devel@kannel.org Sent: Thursday, August 12, 2010 10:42 PM Subject: RE: Sqlbox acks You were ahead of me. Yes, I needed to destroy that as well… fixed at the same time that you wrote this email :=). == Rene From: Alejandro Guerrieri [mailto:aguerri...@kannel.org] Sent: Thursday, 12 August, 2010 21:40 To: Rene Kluwen Cc: devel@kannel.org Subject: Re: Sqlbox acks Perhaps you need to destroy mack also? -- Alejandro Guerrieri aguerri...@kannel.org On 12/08/2010, at 21:05, Rene Kluwen wrote: Does anybody object to this simple patch which will take away a lot of worries of sqlbox users? It generates an ack to bearerbox if a message is directed to sqlbox itself (i.e. not to an smsbox). == Rene sqlbox_acks_1.patch
Re: Urgent Need Help in SMPP
Read user's guide. It has lots of examples. Afterwards if you have specific questions ask the list. BR, Nikos - Original Message - From: adil nazir To: Nikos Balkanas Cc: devel@kannel.org Sent: Thursday, August 12, 2010 8:06 AM Subject: Re: Urgent Need Help in SMPP SMSC may not contain the accepted_smsc variable. I want to use denied-smsc-id with smsc of type smpp but when i do so still my smsc can accept messages of all other smsc's. Tell me what can i do? From: Nikos Balkanas nbalka...@gmail.com To: adil nazir adil_nazi...@yahoo.com Sent: Thu, August 12, 2010 2:22:35 AM Subject: Re: Urgent Need Help in SMPP Address list so that others may benefit/offer insight. Do not send me personnals. - Original Message - From: adil nazir To: Nikos Balkanas Sent: Wednesday, August 11, 2010 2:29 PM Subject: Re: Urgent Need Help in SMPP SMSC may not contain the accepted_smsc variable. I want to use denied-smsc-id with smsc of type smpp but when i do so still my smsc can accept messages of all other smsc's. Tell me what can i do? From: Nikos Balkanas nbalka...@gmail.com To: adil nazir adil_nazi...@yahoo.com; devel@kannel.org Sent: Wed, August 11, 2010 3:11:07 PM Subject: Re: Urgent Need Help in SMPP Hi, Don't do work already done. The SMPP drivers are in gw/smsc/*smpp.c. 1) Priority queue works. Recheck. 2) This is fully functional. You need a combination of accepted-smsc and denied-smsc. Read examples in User's guide. BR, Nikos - Original Message - From: adil nazir To: devel@kannel.org Sent: Wednesday, August 11, 2010 9:53 AM Subject: Urgent Need Help in SMPP Please can any one tell me that how can i extract SMPP code from kannel. I want to develop my own application using SMPP i want this because of following reasons: 1. In existing kannel i am unable to give high priority to the massages already in queue i have also used (0-3) priority but still its behavior is same. 2. Also existing kannel route the massage to any SMSC in multiple SMSC environment. I have tried to use denied-smsc-id but still when one SMSC goes down (means not responding but not alive ) kannel route message to the other SMSC. So that is why i want to extract SMPP module from kannel so guide me how can i do this i am new on kannel source code. Also if you have any other solution then tell me but reply as soon as possible. Regards, Adil
Re: Urgent Need Help in SMPP
Hi, Don't do work already done. The SMPP drivers are in gw/smsc/*smpp.c. 1) Priority queue works. Recheck. 2) This is fully functional. You need a combination of accepted-smsc and denied-smsc. Read examples in User's guide. BR, Nikos - Original Message - From: adil nazir To: devel@kannel.org Sent: Wednesday, August 11, 2010 9:53 AM Subject: Urgent Need Help in SMPP Please can any one tell me that how can i extract SMPP code from kannel. I want to develop my own application using SMPP i want this because of following reasons: 1. In existing kannel i am unable to give high priority to the massages already in queue i have also used (0-3) priority but still its behavior is same. 2. Also existing kannel route the massage to any SMSC in multiple SMSC environment. I have tried to use denied-smsc-id but still when one SMSC goes down (means not responding but not alive ) kannel route message to the other SMSC. So that is why i want to extract SMPP module from kannel so guide me how can i do this i am new on kannel source code. Also if you have any other solution then tell me but reply as soon as possible. Regards, Adil
Re: Is kannel store sms in mysql
Hi, Please read User's guide about dlr-url. BR, Nikos - Original Message - From: Rahul Chordiya To: devel@kannel.org Sent: Tuesday, August 03, 2010 1:02 PM Subject: Is kannel store sms in mysql Hello All, Anybody can help me that how can i store SENT SMS and delivery reports in mysql database i have completely configure kannel sms box and mysql connection on my fedore core 12. Thanks in advanced. Ragard Rahul Chordiya
Re: Patch: EMI UUCP DLRs (final)
Hi Rene, Why get things unnecessarily complicated? You can update openSMPPbox code and leave the new argument always to 0 if you don't need it, or - even better - set it to 1 to match against EMI and CMDI DLRs. You can always get those in openSMPPbox, since bb can use differential routing. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Alexander Malysh' amal...@kannel.org; 'Nikos Balkanas' nbalka...@gmail.com Cc: 'Kannel Devel' devel@kannel.org Sent: Monday, August 02, 2010 2:39 AM Subject: RE: Patch: EMI UUCP DLRs (final) I propose the following patch. It adds #define DLR_FIND_USE_DST To dlr.h. It is a convenient way to know if I should add an extra parameter to dlr_find or not. So smppbox (and possibly other gwlib based programs) can happily compile with the dlr_find with the extra option and also (if the define does not exist) with the old dlr_find. == Rene -Original Message- From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Alexander Malysh Sent: Wednesday, 28 July, 2010 22:59 To: Nikos Balkanas Cc: Kannel Devel Subject: Re: Patch: EMI UUCP DLRs (final) Hi, patch with minor fixes commited to SVN. Thanks, Alexander Malysh Am 26.07.2010 um 18:14 schrieb Nikos Balkanas: Kyriaco, Previous svn diff I got with -ub, which may be relevant. Try this one which is only -u. BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: Nikos Balkanas nbalka...@gmail.com Cc: Kannel Devel devel@kannel.org Sent: Monday, July 26, 2010 5:04 PM Subject: Re: Patch: EMI UUCP DLRs (final) Hi Nikos, I got the svn snapshot today. Don't think its an SVN problem, possibly some flag needed for patch. patch 2.5.9 svn, version 1.4.2 (r22196) Running on Debian Etch. I should be able to hand patch the files where it is giving errors. Some from what I saw were due to different indentation. If you wish I can post the files detailing the rejected patches. Kyriacos On 26/07/2010 16:50, Nikos Balkanas wrote: Sorry for the irrelevant question. I tried from a fresh downloaded svn: zdev:~/work/kannel/gateway- patch kannel.diff Looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. done This is from Solaris using sunfreeware's gnu svn: svn, version 1.6.9 (r901367) compiled Mar 20 2010, 16:02:58 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme Hope this helps, Nikos - Original Message - From: Nikos Balkanas nbalka...@gmail.com To: Kyriacos Sakkas kyria...@netsmart.com.cy; Kannel Devel devel@kannel.org Sent: Monday, July 26, 2010 4:04 PM Subject: Re: Patch: EMI UUCP DLRs (final) Hi Kyriaco, Are you patching against latest svn? BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: Kannel Devel devel@kannel.org Sent: Monday, July 26, 2010 2:08 PM Subject: Re: Patch: EMI UUCP DLRs (final) Trying to patch to svn downloaded today (same version as in diff) and getting some errors. I will try to change the diff to work, but id someone has already done this, please forward, or let me know whats wrong with my patch command line. Patch file is from Nikos on the 20th. /opt/svn/26072010/trunk# patch --dry-run -p0 -b cimd_dlr.diff (Stripping trailing CRs from patch.) patching file gw/dlr_mysql.c (Stripping trailing CRs from patch.) patching file gw/dlr_oracle.c (Stripping trailing CRs from patch.) patching file gw/dlr_pgsql.c (Stripping trailing CRs from patch.) patching file gw/dlr_mem.c (Stripping trailing CRs from patch
Re: [PATCH] Smppbox acks
Besides bb has also the same issue, and it doesn't seem to be a problem. Some minor memory increase. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Victor Luchitz' vluch...@gmail.com Cc: 'Kannel Devel' devel@kannel.org Sent: Monday, August 02, 2010 4:36 PM Subject: RE: [PATCH] Smppbox acks Not receiving acks is only on topic if the connection is bad, somewhere. Probably you will need to reconnect in that case anyway. -Original Message- From: Victor Luchitz [mailto:vluch...@gmail.com] Sent: Monday, 02 August, 2010 09:18 To: Rene Kluwen Cc: Tomasz Konopka; Kannel Devel Subject: Re: [PATCH] Smppbox acks What bothers me a bit about this patch is that messages we don't receive ack for are going to stay in memory forever, well, as long the boxc is alive. A proper timeout mechanism would be a nice bonus. 2010/8/2 Rene Kluwen rene.klu...@chimit.nl: Here is a more advanced patch. Messages to bearerbox are acked, once the deliver_sm_resp pdu is in. Also submit_sm pdu's get their responses, after bearerbox has acked the message. And if not, a failure notice is returned. Before, message acks were given right away, without checking for failure or rejection. Tomasz: Would it be possible for you to test this patch in your environment? Victor: Would you review for stupidities? Comments are welcome. == Rene -- Best regards, Victor Luchitz
Re: Patch: EMI UUCP DLRs (final)
I see. Isn't it always in openSMPPbox installation instructions to download and install latest kanell sources? It wouldn't be a bad idea to release an openSMPPbox patch just to align it with latest kannel. Worst case scenario, one could always make latest kannel sources, without deploying them, just to feed openSMPPbox compilation. The bad thing with these defines, is that they keep accumulating, even after they are useless, out of fear not to break any existing old installations. I think that any client using the gateway's libraries, should follow suit quickly and align their sources, without imposing changes to the gateway. What about SQLbox? Does it also use dlr_find? BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Nikos Balkanas' nbalka...@gmail.com; 'Alexander Malysh' amal...@kannel.org Cc: 'Kannel Devel' devel@kannel.org Sent: Monday, August 02, 2010 8:43 PM Subject: RE: Patch: EMI UUCP DLRs (final) The problem is not adding an extra actual parameter. The problem is that people must now update to the latest Kannel code or otherwise smppbox won't compile. == Rene -Original Message- From: Nikos Balkanas [mailto:nbalka...@gmail.com] Sent: Monday, 02 August, 2010 19:29 To: Rene Kluwen; 'Alexander Malysh' Cc: 'Kannel Devel' Subject: Re: Patch: EMI UUCP DLRs (final) Hi Rene, Why get things unnecessarily complicated? You can update openSMPPbox code and leave the new argument always to 0 if you don't need it, or - even better - set it to 1 to match against EMI and CMDI DLRs. You can always get those in openSMPPbox, since bb can use differential routing. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: 'Alexander Malysh' amal...@kannel.org; 'Nikos Balkanas' nbalka...@gmail.com Cc: 'Kannel Devel' devel@kannel.org Sent: Monday, August 02, 2010 2:39 AM Subject: RE: Patch: EMI UUCP DLRs (final) I propose the following patch. It adds #define DLR_FIND_USE_DST To dlr.h. It is a convenient way to know if I should add an extra parameter to dlr_find or not. So smppbox (and possibly other gwlib based programs) can happily compile with the dlr_find with the extra option and also (if the define does not exist) with the old dlr_find. == Rene -Original Message- From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of Alexander Malysh Sent: Wednesday, 28 July, 2010 22:59 To: Nikos Balkanas Cc: Kannel Devel Subject: Re: Patch: EMI UUCP DLRs (final) Hi, patch with minor fixes commited to SVN. Thanks, Alexander Malysh Am 26.07.2010 um 18:14 schrieb Nikos Balkanas: Kyriaco, Previous svn diff I got with -ub, which may be relevant. Try this one which is only -u. BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: Nikos Balkanas nbalka...@gmail.com Cc: Kannel Devel devel@kannel.org Sent: Monday, July 26, 2010 5:04 PM Subject: Re: Patch: EMI UUCP DLRs (final) Hi Nikos, I got the svn snapshot today. Don't think its an SVN problem, possibly some flag needed for patch. patch 2.5.9 svn, version 1.4.2 (r22196) Running on Debian Etch. I should be able to hand patch the files where it is giving errors. Some from what I saw were due to different indentation. If you wish I can post the files detailing the rejected patches. Kyriacos On 26/07/2010 16:50, Nikos Balkanas wrote: Sorry for the irrelevant question. I tried from a fresh downloaded svn: zdev:~/work/kannel/gateway- patch kannel.diff Looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. The next patch looks like a unified context diff. done This is from Solaris using sunfreeware's gnu svn: svn, version 1.6.9 (r901367) compiled Mar 20 2010, 16:02:58 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local
Re: Discussion: Prepaid counting
Hi, I can see a couple of problems in this approach. 1) Billing should be implemented in bearerbox, since it decides on final routing, not sqlbox. 2) There is an overuse of the DB. There is no need to put the priceplan in a DB. BR, Nikos - Original Message - From: Rene Kluwen rene.klu...@chimit.nl To: devel@kannel.org Cc: kinch...@gmail.com Sent: Sunday, August 01, 2010 4:08 AM Subject: Discussion: Prepaid counting Suppose I add 2 tables to sqlbox: mysql describe sms_users; +-+--+--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +-+--+--+-+-+---+ | binfo | varchar(100) | NO | PRI | NULL| | | balance | float(10,0) | NO | | 0 | | +-+--+--+-+-+---+ 2 rows in set (0.00 sec) And: mysql describe sms_rates; +-+--+--+-+-+---+ | Field | Type | Null | Key | Default | Extra | +-+--+--+-+-+---+ | prefix | varchar(100) | NO | PRI | | | | smsc| varchar(100) | NO | PRI | | | | rate| float(10,4) | NO | | 0. | | | country | varchar(255) | YES | | | | +-+--+--+-+-+---+ 4 rows in set (0.00 sec) And suppose I match prefix/smsc against sms_rates and draw the variable rate from it. Next, I check the sms_users table with the binfo field (not sure if this is a good idea or not) and I withdraw rate from balance if balance is big enough. Once balance reaches 0, sqlbox will refuse to relay further messages to bearerbox. Attached is a patch that does the trick (for now, only mysql engines). Note: This code hasn't been tested yet and probably contains a bug or two. But I am posting it anyway to see what the almighty Kannel Developers have to say about it. This patch is especially useful if you want your clients to have access to an open smppbox with a limited amount of credits. But also it works for smsboxes and sqlboxes, as you please. I made a small patch to open smppbox that allows passing of binfo. == Rene
