which cells work with kannel
Hi all, Has any 1 used a cell as virtual SMSC with kannel successfully, if yes PLZ tell me which cell u used and mail the MODEM conf also. THANK U. - Get the freedom to save as many mails as you wish. Click here to know how.
inbound sms concatenation
hi all, i'm still researching this but thought i'd send off a message here in case anyone had some sample code they could share. i have the following sms-service defined: # SERVICES group = sms-service keyword = keyword-regex = .* catch-all = yes max-messages = 0 get-url = http://localhost/inbound.php?from=%pto=%Qtext=%audh=%u; i tried with concatenation=true but it appears this only refers to the outbound response messages. so i'm just wondering if anyone has any advice on decoding that UDH to stitch the messages together using PHP. also, the %P and %Q parameters are coming through as the port number of my send sms port rather than the destination that the number was sent to, has anyone seen this before?? cheers iain
Re: inbound sms concatenation
Hi iain, Its in the core config sms-combine-concatenated-mo = true but there is an issue with VAS related shortcode services : consider this: the SMSC charge each part of a long MO message as one MO so imagine you receive LONG LONG MO concatenated from 5 messages. you will get one MO from the SMSC, but they will charge the client for 5 ... hope the above to save you from getting in troubles :) cheers seik -Original Message- From: users@kannel.org [EMAIL PROTECTED] Sent: 15 Март 2008 г. To: seikath Subject:inbound sms concatenation hi all, i'm still researching this but thought i'd send off a message here in case anyone had some sample code they could share. i have the following sms-service defined: # SERVICES group = sms-service keyword = keyword-regex = .* catch-all = yes max-messages = 0 get-url = http://localhost/inbound.php?from=%pto=%Qtext=%audh=%u; i tried with concatenation=true but it appears this only refers to the outbound response messages. so i'm just wondering if anyone has any advice on decoding that UDH to stitch the messages together using PHP. also, the %P and %Q parameters are coming through as the port number of my send sms port rather than the destination that the number was sent to, has anyone seen this before?? cheers iain
Re: inbound sms concatenation
hi seik, Its in the core config sms-combine-concatenated-mo = true hmmm what version is that for? i'm running 1.4.1 and when i startup with that in my core config: group = core admin-port = PORT smsbox-port = PORT admin-password = PASS dlr-storage = internal admin-deny-ip = *.*.*.* admin-allow-ip = 127.0.0.1 log-file = /tmp/kannel.log log-level = 1 box-deny-ip = *.*.*.* box-allow-ip = 127.0.0.1 access-log = /tmp/access.log sms-combine-concatenated-mo = true i get the error on startup ERROR: Group 'core' may not contain field 'sms-combine-concatenated-mo'. but there is an issue with VAS related shortcode services : consider this: the SMSC charge each part of a long MO message as one MO so imagine you receive LONG LONG MO concatenated from 5 messages. you will get one MO from the SMSC, but they will charge the client for 5 ... this is being used for a non-premuim service, but thanks for the advice! i'll keep it in mind for future reference. cheers iain
Bind Failed
Dear all, Last time i've write about gw/smsbox.c:http_queue_thread connect failed The problem already solved now, but i'm facing another problem now. The server unable to bind to port 13000. I've already try to change the port and search for same port that might already been used on conf file but the port was not used and changing port was not solved the problem. ++ [EMAIL PROTECTED]:/var/log/kannel$ bearerbox /etc/kannel/kannel.conf 2008-03-15 18:11:42 [8031] [0] INFO: Debug_lvl = -1, log_file = none, log_lvl = 0 2008-03-15 18:11:42 [8031] [0] DEBUG: Loading include file `/etc/kannel/smsc.conf' (on line 23 of file /etc/kannel/kannel.conf). 2008-03-15 18:11:42 [8031] [0] DEBUG: Loading include file `/etc/kannel/modems.conf' (on line 22 of file /etc/kannel/smsc.conf). 2008-03-15 18:11:42 [8031] [0] WARNING: DLR: using default 'internal' for storage type. 2008-03-15 18:11:42 [8031] [0] INFO: DLR using storage type: internal 2008-03-15 18:11:42 [8031] [0] DEBUG: Kannel bearerbox version `1.4.1'. Build `Nov 11 2006 21:58:18', compiler `4.1.2 20061103 (prerelease) (Ubuntu 4.1.1-18ubuntu2)'. System Linux, release 2.6.22-14-generic, version #1 SMP Tue Feb 12 02:46:46 UTC 2008, machine x86_64. Hostname unknown-localhost, IP 127.0.1.1. Libxml version 2.6.26. Using OpenSSL 0.9.8b 04 May 2006. Compiled with MySQL 5.0.26, using MySQL 5.0.45. Using native malloc. 2008-03-15 18:11:42 [8031] [0] INFO: Added logfile `/var/log/kannel/kannel.log' with level `0'. 2008-03-15 18:11:42 [8031] [0] INFO: Started access logfile `/var/log/kannel/access.log'. 2008-03-15 18:11:42 [8031] [0] INFO: HTTP: Opening server at port 13000. 2008-03-15 18:11:42 [8031] [0] ERROR: bind failed 2008-03-15 18:11:42 [8031] [0] ERROR: System error 98: Address already in use 2008-03-15 18:11:42 [8031] [0] DEBUG: Started thread 1 (gw/bb_http.c:httpadmin_run) 2008-03-15 18:11:42 [8031] [0] DEBUG: starting smsbox connection module 2008-03-15 18:11:42 [8031] [0] INFO: BOXC: 'smsbox-max-pending' not set, using default (100). 2008-03-15 18:11:42 [8031] [0] DEBUG: Started thread 2 (gw/bb_boxc.c:sms_to_smsboxes) 2008-03-15 18:11:42 [8031] [0] DEBUG: Started thread 3 (gw/bb_boxc.c:smsboxc_run) 2008-03-15 18:11:42 [8031] [0] INFO: Set SMS resend frequency to 60 seconds. 2008-03-15 18:11:42 [8031] [0] INFO: SMS resend retry set to 5. 2008-03-15 18:11:42 [8031] [0] INFO: DLR rerouting for smsc id modem0 disabled. 2008-03-15 18:11:42 [8031] [0] INFO: AT2[modem0]: configuration shows modemtype wavecom 2008-03-15 18:11:42 [8031] [0] DEBUG: AT2[modem0]: Reading modem definitions from /etc/kannel/kannel.conf 2008-03-15 18:11:42 [8031] [3] DEBUG: Thread 3 (gw/bb_boxc.c:smsboxc_run) maps to pid 8031. 2008-03-15 18:11:42 [8031] [3] ERROR: bind failed 2008-03-15 18:11:42 [8031] [3] ERROR: System error 98: Address already in use 2008-03-15 18:11:42 [8031] [3] PANIC: Could not open smsbox port 13001 2008-03-15 18:11:42 [8031] [0] DEBUG: Loading include file `/etc/kannel/smsc.conf' (on line 23 of file /etc/kannel/kannel.conf). 2008-03-15 18:11:42 [8031] [3] PANIC: bearerbox(gw_panic+0x193) [0x4725f3] 2008-03-15 18:11:42 [8031] [3] PANIC: bearerbox [0x4116a9] 2008-03-15 18:11:42 [8031] [3] PANIC: bearerbox [0x46a275] 2008-03-15 18:11:42 [8031] [3] PANIC: /lib/libpthread.so.0 [0x2af84317b317] 2008-03-15 18:11:42 [8031] [3] PANIC: /lib/libc.so.6(clone+0x6d) [0x2af843f40d5d] ++ Is there any workaround to solved this problem...?? Thank you, Iqbal
Re: Locating the bottleneck
Just a follow up to say I feel I've ruled out the carrier connection. I routed everything through another bind, to a different carrier and still found 150 messages took 82 seconds. I know this is something very basic, I'm just not seeing it. Dave On 3/15/08, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Dave, It certainly looks like a bottleneck on the link, but there are so many variables involved that it's quit difficult to pinpoint the problem without a lot of analysis and tests. One more question: if you access the http interface on kannel, the store and queued values gets higher and higher? Could you please post some figures on what's showing on the admin interface? Regards, Alejandro On Fri, Mar 14, 2008 at 9:56 PM, Dave Clarke [EMAIL PROTECTED] wrote: Thanks for this Alejandro I'll look at trying the fake smsc. The carrier has given me a throughput of 50, and advised that I split this across 2 binds, which I have done, setting the throughput figures at 25 and 25. I never see any throttling erors. The reason I set the max-pending-submits to 100 was that, with log level 0, and max-pending-submits set to 10, I was able to see that I was only able to send 10 submit_sm, and would then have to wait for a submit_sm_resp before I could submit another message. I thought that increasing to 100 would give me a better window, as sometimes my submit_sm_resp seem to take forever. Maybe I need to talk to the carrier about the length of time it takes to get the submit_sm_resp back from them. Thank for your input. I think I'll open a ticket with the carrier in case it's simply a misconfig on their side. Dave On 3/15/08, *Alejandro* Guerrieri [EMAIL PROTECTED] wrote: Dave, I can't make a 100% accurate diagnostic without further tests, but looks like the bottleneck is on the links with the carrier. You can try using the fake smsc module instead of your links, and queue a fair amount of traffic. If the bottleneck is on those links, you'll get much better performance when using the fake smsc. Probably, what it's happening is that the smsc is only accepting a small amount of traffic, and maybe you should lower the throughput values to avoid retries and throttling on the other side. What I'd try: * Try reducing max-pending-submits to 10. Experiment with other values also. 100 looks rather high imho. * Check on your logfiles if there's any throttling errors. * Also ask your smsc what's the maximum accepted rate and set the thorughput value to that value. Hope it helps, Alejandro On Fri, Mar 14, 2008 at 9:14 PM, Dave Clarke [EMAIL PROTECTED] wrote: Hi, Having used kannel for a couple of years, I am now at a point where I need to start ramping up my throughput, but I am finding that I can't sustain any more than 2-3 messages a second through my 2x25 SMPP binds. If I walk through my application: - PHP/Apache/Postgresql application presents messages to smsbox. On this occasion I try to send 2200 messages through. They are delivered to smsbox in blocks of 25 numbers. If I study smsbox.log, I see the entire process of passing the messages to smsbox takes 26 seconds. - smsbox then chops these up into individual messages and queues them. If I study smsbox-access.log, again I see all 2200 send-SMS requests added in about 26 seconds. So far so good. - If I now go to access.log, I see that I'm taking 22 MINUTES to do the 2200 transmits. Because this is so long, more customers come along with big sends, and soon I have 10,000 messages queued and waiting. Result is a system churning through 2-3 messages per second. I'm guessing this is a simple matter of my not understanding the correct settings for my max-pendings etc. What I'm hoping is to kick off a slightly high-level discussion on the factors I need to look at to achieve X messages per second, and sustain this level of trafic before I get a snowball effect with queued messages and a flood of DLRs. My thinking, which seems to have been wrong, was that if I have a through put to SMSC of 50msgs per second, and an ACK takes say 3 seconds to come back, then I should handle 3x50=150 pending messages, so I set max-pending-submits = 100 on both binds. Doesn't seem to have done the trick. I'd appreciate any views or suggestions on how I scale this thing. Let me know if you need more info. Thanks, Dave Points to note: - This is CVS today (20080314) - using file as store - All messages have DLR mask 31, so lots of DLRs coming in. - using mysql for dlrs - everything currently on a single Dual P4 IBM Netfinity, 4GB RAM. Not cutting edge, but a good solid system, RAID array etc. Config: # CORE group
Re: Locating the bottleneck
may it be your internet connection? what kind of connection do you have? what available bandwidth? is it used only by kannel, or also by other services? On Sat, Mar 15, 2008 at 10:16 AM, Dave Clarke [EMAIL PROTECTED] wrote: Just a follow up to say I feel I've ruled out the carrier connection. I routed everything through another bind, to a different carrier and still found 150 messages took 82 seconds. I know this is something very basic, I'm just not seeing it. Dave On 3/15/08, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Dave, It certainly looks like a bottleneck on the link, but there are so many variables involved that it's quit difficult to pinpoint the problem without a lot of analysis and tests. One more question: if you access the http interface on kannel, the store and queued values gets higher and higher? Could you please post some figures on what's showing on the admin interface? Regards, Alejandro On Fri, Mar 14, 2008 at 9:56 PM, Dave Clarke [EMAIL PROTECTED] wrote: Thanks for this Alejandro I'll look at trying the fake smsc. The carrier has given me a throughput of 50, and advised that I split this across 2 binds, which I have done, setting the throughput figures at 25 and 25. I never see any throttling erors. The reason I set the max-pending-submits to 100 was that, with log level 0, and max-pending-submits set to 10, I was able to see that I was only able to send 10 submit_sm, and would then have to wait for a submit_sm_resp before I could submit another message. I thought that increasing to 100 would give me a better window, as sometimes my submit_sm_resp seem to take forever. Maybe I need to talk to the carrier about the length of time it takes to get the submit_sm_resp back from them. Thank for your input. I think I'll open a ticket with the carrier in case it's simply a misconfig on their side. Dave On 3/15/08, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Dave, I can't make a 100% accurate diagnostic without further tests, but looks like the bottleneck is on the links with the carrier. You can try using the fake smsc module instead of your links, and queue a fair amount of traffic. If the bottleneck is on those links, you'll get much better performance when using the fake smsc. Probably, what it's happening is that the smsc is only accepting a small amount of traffic, and maybe you should lower the throughput values to avoid retries and throttling on the other side. What I'd try: * Try reducing max-pending-submits to 10. Experiment with other values also. 100 looks rather high imho. * Check on your logfiles if there's any throttling errors. * Also ask your smsc what's the maximum accepted rate and set the thorughput value to that value. Hope it helps, Alejandro On Fri, Mar 14, 2008 at 9:14 PM, Dave Clarke [EMAIL PROTECTED] wrote: Hi, Having used kannel for a couple of years, I am now at a point where I need to start ramping up my throughput, but I am finding that I can't sustain any more than 2-3 messages a second through my 2x25 SMPP binds. If I walk through my application: - PHP/Apache/Postgresql application presents messages to smsbox. On this occasion I try to send 2200 messages through. They are delivered to smsbox in blocks of 25 numbers. If I study smsbox.log, I see the entire process of passing the messages to smsbox takes 26 seconds. - smsbox then chops these up into individual messages and queues them. If I study smsbox-access.log, again I see all 2200 send-SMS requests added in about 26 seconds. So far so good. - If I now go to access.log, I see that I'm taking 22 MINUTES to do the 2200 transmits. Because this is so long, more customers come along with big sends, and soon I have 10,000 messages queued and waiting. Result is a system churning through 2-3 messages per second. I'm guessing this is a simple matter of my not understanding the correct settings for my max-pendings etc. What I'm hoping is to kick off a slightly high-level discussion on the factors I need to look at to achieve X messages per second, and sustain this level of trafic before I get a snowball effect with queued messages and a flood of DLRs. My thinking, which seems to have been wrong, was that if I have a through put to SMSC of 50msgs per second, and an ACK takes say 3 seconds to come back, then I should handle 3x50=150 pending messages, so I set max-pending-submits = 100 on both binds. Doesn't seem to have done the trick. I'd appreciate any views or suggestions on how I scale this thing. Let me know if you need more info. Thanks, Dave Points to note: - This is CVS today (20080314) - using file as store - All messages have DLR mask 31, so lots of DLRs
Re: inbound sms concatenation
okay, so i've fiddled around a bit and reckon i've got this working pretty well now. i wanted to stay with release 1.4.1 so i can keep using the freebsd package as it's easier to maintain but i needed MO concatenation. after looking at some inbound UDH i put this script together. i've added comments so everyone can see how it works: http://www.workingsoftware.com.au/concatenate_mo.php.txt hope it helps someone! cheers iain
Re: Locating the bottleneck
Thanks Juan, but definitely not bandwidth issue. Got 3Mb both ways uncontended, and it's working fine. Dave On 3/15/08, Juan Nin [EMAIL PROTECTED] wrote: may it be your internet connection? what kind of connection do you have? what available bandwidth? is it used only by kannel, or also by other services? On Sat, Mar 15, 2008 at 10:16 AM, Dave Clarke [EMAIL PROTECTED] wrote: Just a follow up to say I feel I've ruled out the carrier connection. I routed everything through another bind, to a different carrier and still found 150 messages took 82 seconds. I know this is something very basic, I'm just not seeing it. Dave On 3/15/08, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Dave, It certainly looks like a bottleneck on the link, but there are so many variables involved that it's quit difficult to pinpoint the problem without a lot of analysis and tests. One more question: if you access the http interface on kannel, the store and queued values gets higher and higher? Could you please post some figures on what's showing on the admin interface? Regards, Alejandro On Fri, Mar 14, 2008 at 9:56 PM, Dave Clarke [EMAIL PROTECTED] wrote: Thanks for this Alejandro I'll look at trying the fake smsc. The carrier has given me a throughput of 50, and advised that I split this across 2 binds, which I have done, setting the throughput figures at 25 and 25. I never see any throttling erors. The reason I set the max-pending-submits to 100 was that, with log level 0, and max-pending-submits set to 10, I was able to see that I was only able to send 10 submit_sm, and would then have to wait for a submit_sm_resp before I could submit another message. I thought that increasing to 100 would give me a better window, as sometimes my submit_sm_resp seem to take forever. Maybe I need to talk to the carrier about the length of time it takes to get the submit_sm_resp back from them. Thank for your input. I think I'll open a ticket with the carrier in case it's simply a misconfig on their side. Dave On 3/15/08, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Dave, I can't make a 100% accurate diagnostic without further tests, but looks like the bottleneck is on the links with the carrier. You can try using the fake smsc module instead of your links, and queue a fair amount of traffic. If the bottleneck is on those links, you'll get much better performance when using the fake smsc. Probably, what it's happening is that the smsc is only accepting a small amount of traffic, and maybe you should lower the throughput values to avoid retries and throttling on the other side. What I'd try: * Try reducing max-pending-submits to 10. Experiment with other values also. 100 looks rather high imho. * Check on your logfiles if there's any throttling errors. * Also ask your smsc what's the maximum accepted rate and set the thorughput value to that value. Hope it helps, Alejandro On Fri, Mar 14, 2008 at 9:14 PM, Dave Clarke [EMAIL PROTECTED] wrote: Hi, Having used kannel for a couple of years, I am now at a point where I need to start ramping up my throughput, but I am finding that I can't sustain any more than 2-3 messages a second through my 2x25 SMPP binds. If I walk through my application: - PHP/Apache/Postgresql application presents messages to smsbox. On this occasion I try to send 2200 messages through. They are delivered to smsbox in blocks of 25 numbers. If I study smsbox.log, I see the entire process of passing the messages to smsbox takes 26 seconds. - smsbox then chops these up into individual messages and queues them. If I study smsbox-access.log, again I see all 2200 send-SMS requests added in about 26 seconds. So far so good. - If I now go to access.log, I see that I'm taking 22 MINUTES to do the 2200 transmits. Because this is so long, more customers come along with big sends, and soon I have 10,000 messages queued and waiting. Result is a system churning through 2-3 messages per second. I'm guessing this is a simple matter of my not understanding the correct settings for my max-pendings etc. What I'm hoping is to kick off a slightly high-level discussion on the factors I need to look at to achieve X messages per second, and sustain this level of trafic before I get a snowball effect with queued messages and a flood of DLRs. My thinking, which seems to have been wrong, was that if I have a through put to SMSC of 50msgs per second, and an ACK takes say 3 seconds to come back, then I should handle 3x50=150 pending messages, so I set max-pending-submits = 100 on both binds. Doesn't seem to have
%P in sms-service
has anyone else seen the problem where %P in your get-url of an sms-service configuration sends the port number rather than the destination number? cheers iain
RE: inbound sms concatenation
Does this script work with this UDH (Siemens CX65)? UDH FOR MSG1: 060804005D0201 UDH FOR MSG2: 060804005D0202 I got this UDH from my access.log, %u will be with escape strings (%). Ivars Date: Sun, 16 Mar 2008 01:46:17 +1100 (EST) From: Iain Dooley [EMAIL PROTECTED] Subject: Re: inbound sms concatenation To: seikath [EMAIL PROTECTED] Cc: users@kannel.org Message-ID: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed okay, so i've fiddled around a bit and reckon i've got this working pretty well now. i wanted to stay with release 1.4.1 so i can keep using the freebsd package as it's easier to maintain but i needed MO concatenation. after looking at some inbound UDH i put this script together. i've added comments so everyone can see how it works: http://www.workingsoftware.com.au/concatenate_mo.php.txt hope it helps someone! cheers iain
RE: inbound sms concatenation
Does this script work with this UDH (Siemens CX65)? UDH FOR MSG1: 060804005D0201 UDH FOR MSG2: 060804005D0202 well, i don't really know but it appears to me that it's still the last three chars that contain the most important bits, and they're in the same order as the script i wrote is using. so like, $chars[3] is the id (in this case 5D), $chars[4] is the number of parts (2 in this case) and $chars[5] is what the current part is. i don't really know, but as far as i can work out the first three chars are different for different phones, then there's a zero character, then the three parameters i listed above. correct me if i'm wrong! cheers iain I got this UDH from my access.log, %u will be with escape strings (%). Ivars Date: Sun, 16 Mar 2008 01:46:17 +1100 (EST) From: Iain Dooley [EMAIL PROTECTED] Subject: Re: inbound sms concatenation To: seikath [EMAIL PROTECTED] Cc: users@kannel.org Message-ID: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed okay, so i've fiddled around a bit and reckon i've got this working pretty well now. i wanted to stay with release 1.4.1 so i can keep using the freebsd package as it's easier to maintain but i needed MO concatenation. after looking at some inbound UDH i put this script together. i've added comments so everyone can see how it works: http://www.workingsoftware.com.au/concatenate_mo.php.txt hope it helps someone! cheers iain
RE: inbound sms concatenation
UDH is used not only for concatenation! How about this: 050A0304 This UDH in not for concatenated message. The Information Element Identifier for concatenated message must be 00. Normal UDH for concatenated message looks like this: 0500030A0201 05 = Length of User Data Header (not include itself) 00 = Information-Element-Identifier (Concatenated short messages) 03 = Length of Information-Element (not include itself) Information-Element Data: 0A = Concatenated short message reference number 02 = Maximum number of short messages in the concatenated short message 01 = Sequence number of the current short message But who can explane what is this: 060804005D0201 Maybe: 06 = Length of User Data Header (not include itself) 08 = ??? 04 = Length of Information-Element (not include itself) 00 = Information-Element-Identifier (Concatenated short messages) 5D = Concatenated short message reference number 02 = Maximum number of short messages in the concatenated short message 01 = Sequence number of the current short message Ivars -Original Message- From: Iain Dooley [mailto:[EMAIL PROTECTED] Sent: Saturday, March 15, 2008 5:31 PM To: Ivars Jukams Cc: users@kannel.org Subject: RE: inbound sms concatenation Does this script work with this UDH (Siemens CX65)? UDH FOR MSG1: 060804005D0201 UDH FOR MSG2: 060804005D0202 well, i don't really know but it appears to me that it's still the last three chars that contain the most important bits, and they're in the same order as the script i wrote is using. so like, $chars[3] is the id (in this case 5D), $chars[4] is the number of parts (2 in this case) and $chars[5] is what the current part is. i don't really know, but as far as i can work out the first three chars are different for different phones, then there's a zero character, then the three parameters i listed above. correct me if i'm wrong! cheers iain I got this UDH from my access.log, %u will be with escape strings (%). Ivars Date: Sun, 16 Mar 2008 01:46:17 +1100 (EST) From: Iain Dooley [EMAIL PROTECTED] Subject: Re: inbound sms concatenation To: seikath [EMAIL PROTECTED] Cc: users@kannel.org Message-ID: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed okay, so i've fiddled around a bit and reckon i've got this working pretty well now. i wanted to stay with release 1.4.1 so i can keep using the freebsd package as it's easier to maintain but i needed MO concatenation. after looking at some inbound UDH i put this script together. i've added comments so everyone can see how it works: http://www.workingsoftware.com.au/concatenate_mo.php.txt hope it helps someone! cheers iain
RE: GSM DLR from GSM operator for MTs
I found a solution. sim-buffering = true Im not very happy with it (because of latency and concern of buffer overrun) but it does the job. Im looking now at AT+CNMI hoping there is a way to instruct the phone not to store DLRs to SIM but forward them directly to kannel. _ From: info.ubichip [mailto:[EMAIL PROTECTED] Sent: 13 March 2008 08:18 To: 'Alvaro Cornejo'; 'Raul Igrisan' Cc: users@kannel.org Subject: RE: GSM DLR from GSM operator for MTs it is in the dlr feature of kannel if you want some examples of AT command. regards _ From: Alvaro Cornejo [mailto:[EMAIL PROTECTED] Sent: mercredi 12 mars 2008 08:59 To: Raul Igrisan Cc: users@kannel.org Subject: Re: GSM DLR from GSM operator for MTs As fas as I know, this is not possible. operator usually block this feature for modems/phones On Wed, Mar 12, 2008 at 5:17 AM, Raul Igrisan [EMAIL PROTECTED] wrote: Does anyone know how to instruct (perhaps AT command or PDU parameter) a GSM SMSC (phone/modem) to request DLR from GSM network when sending MT? By default the modem doesn't receive the a delivery report from operator when the message is delivered to the target mobile phone. Thanks -- |--- --| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.smsglobal.com.mx y www.pravcom.com _ Antivirus avast! http://www.avast.com : message Sortant sain. Base de donnees virale (VPS) : 080312-0, 12/03/2008 Analyse le : 12/03/2008 23:17:41 avast! - copyright (c) 1988-2008 ALWIL Software.
Re: Locating the bottleneck
Are you 100% sure that the problem's not within your application? I'd go nailing one possible point of failure at a time. If you can afford making some tests offline, I'd connect the fake-smsc and simulate a few hundred MO's and see how it perform. If you still have issues using fake-smsc, then the usual suspect is the external application. Have you checked the server's syslog? How's server load BTW? Regards, Alejandro On Sat, Mar 15, 2008 at 11:58 AM, Dave Clarke [EMAIL PROTECTED] wrote: Thanks Juan, but definitely not bandwidth issue. Got 3Mb both ways uncontended, and it's working fine. Dave On 3/15/08, Juan Nin [EMAIL PROTECTED] wrote: may it be your internet connection? what kind of connection do you have? what available bandwidth? is it used only by kannel, or also by other services? On Sat, Mar 15, 2008 at 10:16 AM, Dave Clarke [EMAIL PROTECTED] wrote: Just a follow up to say I feel I've ruled out the carrier connection. I routed everything through another bind, to a different carrier and still found 150 messages took 82 seconds. I know this is something very basic, I'm just not seeing it. Dave On 3/15/08, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Dave, It certainly looks like a bottleneck on the link, but there are so many variables involved that it's quit difficult to pinpoint the problem without a lot of analysis and tests. One more question: if you access the http interface on kannel, the store and queued values gets higher and higher? Could you please post some figures on what's showing on the admin interface? Regards, Alejandro On Fri, Mar 14, 2008 at 9:56 PM, Dave Clarke [EMAIL PROTECTED] wrote: Thanks for this Alejandro I'll look at trying the fake smsc. The carrier has given me a throughput of 50, and advised that I split this across 2 binds, which I have done, setting the throughput figures at 25 and 25. I never see any throttling erors. The reason I set the max-pending-submits to 100 was that, with log level 0, and max-pending-submits set to 10, I was able to see that I was only able to send 10 submit_sm, and would then have to wait for a submit_sm_resp before I could submit another message. I thought that increasing to 100 would give me a better window, as sometimes my submit_sm_resp seem to take forever. Maybe I need to talk to the carrier about the length of time it takes to get the submit_sm_resp back from them. Thank for your input. I think I'll open a ticket with the carrier in case it's simply a misconfig on their side. Dave On 3/15/08, Alejandro Guerrieri [EMAIL PROTECTED] wrote: Dave, I can't make a 100% accurate diagnostic without further tests, but looks like the bottleneck is on the links with the carrier. You can try using the fake smsc module instead of your links, and queue a fair amount of traffic. If the bottleneck is on those links, you'll get much better performance when using the fake smsc. Probably, what it's happening is that the smsc is only accepting a small amount of traffic, and maybe you should lower the throughput values to avoid retries and throttling on the other side. What I'd try: * Try reducing max-pending-submits to 10. Experiment with other values also. 100 looks rather high imho. * Check on your logfiles if there's any throttling errors. * Also ask your smsc what's the maximum accepted rate and set the thorughput value to that value. Hope it helps, Alejandro On Fri, Mar 14, 2008 at 9:14 PM, Dave Clarke [EMAIL PROTECTED] wrote: Hi, Having used kannel for a couple of years, I am now at a point where I need to start ramping up my throughput, but I am finding that I can't sustain any more than 2-3 messages a second through my 2x25 SMPP binds. If I walk through my application: - PHP/Apache/Postgresql application presents messages to smsbox. On this occasion I try to send 2200 messages through. They are delivered to smsbox in blocks of 25 numbers. If I study smsbox.log, I see the entire process of passing the messages to smsbox takes 26 seconds. - smsbox then chops these up into individual messages and queues them. If I study smsbox-access.log, again I see all 2200 send-SMS requests added in about 26 seconds. So far so good. - If I now go to access.log, I see that I'm taking 22 MINUTES to do the 2200 transmits. Because this is so long, more customers come along with big sends, and soon I have 10,000 messages queued and waiting. Result is a system churning through 2-3
RE: GSM DLR from GSM operator for MTs
It seems init-string = AT+CNMI=2,2,2,1,0 is the right way to do it. The phone forwards the DLR to kannel as soon as it receives it (very few seconds after the message is sent). _ From: Raul Igrisan [mailto:[EMAIL PROTECTED] Sent: 15 March 2008 19:02 To: 'info.ubichip'; 'Alvaro Cornejo' Cc: users@kannel.org Subject: RE: GSM DLR from GSM operator for MTs I found a solution. sim-buffering = true Im not very happy with it (because of latency and concern of buffer overrun) but it does the job. Im looking now at AT+CNMI hoping there is a way to instruct the phone not to store DLRs to SIM but forward them directly to kannel. _ From: info.ubichip [mailto:[EMAIL PROTECTED] Sent: 13 March 2008 08:18 To: 'Alvaro Cornejo'; 'Raul Igrisan' Cc: users@kannel.org Subject: RE: GSM DLR from GSM operator for MTs it is in the dlr feature of kannel if you want some examples of AT command. regards _ From: Alvaro Cornejo [mailto:[EMAIL PROTECTED] Sent: mercredi 12 mars 2008 08:59 To: Raul Igrisan Cc: users@kannel.org Subject: Re: GSM DLR from GSM operator for MTs As fas as I know, this is not possible. operator usually block this feature for modems/phones On Wed, Mar 12, 2008 at 5:17 AM, Raul Igrisan [EMAIL PROTECTED] wrote: Does anyone know how to instruct (perhaps AT command or PDU parameter) a GSM SMSC (phone/modem) to request DLR from GSM network when sending MT? By default the modem doesn't receive the a delivery report from operator when the message is delivered to the target mobile phone. Thanks -- |--- --| Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier celular y Nextel en México y en mas de 180 paises. Use aplicaciones 2 vias via SMS y GPRS online Visitenos en www.smsglobal.com.mx y www.pravcom.com _ Antivirus avast! http://www.avast.com : message Sortant sain. Base de donnees virale (VPS) : 080312-0, 12/03/2008 Analyse le : 12/03/2008 23:17:41 avast! - copyright (c) 1988-2008 ALWIL Software.
Re: Bind Failed
2008-03-15 18:11:42 [8031] [0] INFO: HTTP: Opening server at port 13000.
2008-03-15 18:11:42 [8031] [0] ERROR: bind failed
2008-03-15 18:11:42 [8031] [0] ERROR: System error 98: Address already in
now, this says it all: the port is in use as the underlying IO socket
for that port can't be acquired.
Obviously some other process is binded to it, or you try to run 2
bearerbox instances with the same config.
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: %P in sms-service
I think it is not destination number. it is my-number in your smsc group. could you send your configuration file? On Sat, Mar 15, 2008 at 11:02 PM, Iain Dooley [EMAIL PROTECTED] wrote: has anyone else seen the problem where %P in your get-url of an sms-service configuration sends the port number rather than the destination number? cheers iain -- Head Technology Department G-Mobile Corporation Ulaanbaatar, Mongolia Mobile: +976-9810 Tel: +976-11-311198 Fax: +976-11-311195 Web: http://www.g-mobile.mn
