UCP keepalive ack problems
Hello list, We have several UCP links to a certain operator's SMSC, here's one of the smscs configuration (excluding sensitive information of course) group = smsc smsc = emi smsc-id = smsc_x_mo2 log-file = /var/log/kannel/x_mo2.log log-level = 0 host = 1.2.3.4 port = 1234 smsc-username = xxx smsc-password = yyy keepalive = 30 idle-timeout = 120 source-addr-autodetect = yes allowed-smsc-id = smsc_x_mo2 flow-control = 0 window = 1 wait-ack = 60 wait-ack-expire = 0x00 (all the links are configured with keepalive=30 and idle-timeout=120 so that the links are never considered idle by kannel) some of the links are for outgoing traffic only, MT and DLR travel on these others are for incoming traffic only, MO travel there. naturally, most of our traffic is outgoing so the MT links are rarely idle, however even when they are, we see steady keepalive requests and ACKs for them going on on the MO links however, the situation is different. these are mostly idle, and keepalive requests do not work as expected. sometimes we get ACK on keepalive an *hour* after the original packet was sent (actually, this happens to every second keepalive packet according to the logs i'm looking at) To illustrate the problem, here's the log from such smsc link filtered by 60 and 31 packets dumped: (note that login *requests* are not listed as they are not dumped by kannel) Check out the bold lines - these are ack responses from the smsc that come back after an hour! 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 00/00019/R/60/A//6D 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 24/00025/O/31/201/0539/8E 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 24/00023/R/31/A//2C 2011-04-07 07:19:28 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 25/00025/O/31/201/0539/8F *2011-04-07 08:19:00 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 25/00023/R/31/A//2D * 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 00/00019/R/60/A//6D 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 26/00025/O/31/201/0539/90 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 26/00023/R/31/A//2E 2011-04-07 08:19:41 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 27/00025/O/31/201/0539/91 *2011-04-07 09:19:04 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 27/00023/R/31/A//2F * 2011-04-07 09:19:04 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 00/00019/R/60/A//6D So, the first question that arises is: why doesnt kannel re-connect automatically after 60 seconds like wait-ack* settings imply, and instead this happens only when the ack finally arrives after an hour? The second question is - in case the remote smsc fails to produce acks to keepalives properly, whats the way of ensuring the link is really alive? Lately, we're experiencing a lot of problems when the link went down on the other side and kannel does not notice that and keeps thinking the link is still alive. Moreover, when we're trying to reset such a undead link individually, everything fails, including killing the socket with tcpkill - kannel still does not bring the smsc down, and the only option left is shut down the kannel completely, *including kill -9 bearerbox* (because otherwise kannel never even finishes shutdown sequence) and performing a full restart.
RE: UCP keepalive ack problems
Hi Konstantin, I think the problem you have is misappropriating variables for example Wait-ack means duration to wait for acknowledgment before the resending a message. Each message has to get an ack (acknowledgement) from the SMSC. Check user guide wait-ack number (seconds) A message is resent if the acknowledge from SMSC takes more than this time. Defaults to 60 seconds. It goes hand in hand with wait-ack-expire wait-ack-expire number Defines what kind of action should be taken if the the ack of a message expires. The options for this value are: 0x00 - disconnect/reconnect, (default) 0x01 - as is now, re-queue, but this could potentially result in the msg arriving twice 0x02 – just carry on waiting (given that the wait-ack should never expire this is the mst accurate) I believe what you are referring to for checking whether SMSC has gone away is enquire-link. If you set it to say 30 secs then it will keep enquiring every 30secs and if the SMSC is not available kannel will initiate a reconnect. You can also use reconnect-delay to control how much time before kannel tries to reconnect after it ‘discovers’ it is unbound default is 10secs. Rapture From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On Behalf Of Konstantin Vayner Sent: Tuesday, April 12, 2011 12:15 PM To: Kannel Users Subject: UCP keepalive ack problems Hello list, We have several UCP links to a certain operator's SMSC, here's one of the smscs configuration (excluding sensitive information of course) group = smsc smsc = emi smsc-id = smsc_x_mo2 log-file = /var/log/kannel/x_mo2.log log-level = 0 host = 1.2.3.4 port = 1234 smsc-username = xxx smsc-password = yyy keepalive = 30 idle-timeout = 120 source-addr-autodetect = yes allowed-smsc-id = smsc_x_mo2 flow-control = 0 window = 1 wait-ack = 60 wait-ack-expire = 0x00 (all the links are configured with keepalive=30 and idle-timeout=120 so that the links are never considered idle by kannel) some of the links are for outgoing traffic only, MT and DLR travel on these others are for incoming traffic only, MO travel there. naturally, most of our traffic is outgoing so the MT links are rarely idle, however even when they are, we see steady keepalive requests and ACKs for them going on on the MO links however, the situation is different. these are mostly idle, and keepalive requests do not work as expected. sometimes we get ACK on keepalive an *hour* after the original packet was sent (actually, this happens to every second keepalive packet according to the logs i'm looking at) To illustrate the problem, here's the log from such smsc link filtered by 60 and 31 packets dumped: (note that login *requests* are not listed as they are not dumped by kannel) Check out the bold lines - these are ack responses from the smsc that come back after an hour! 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 00/00019/R/60/A//6D 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 24/00025/O/31/201/0539/8E 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 24/00023/R/31/A//2C 2011-04-07 07:19:28 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 25/00025/O/31/201/0539/8F 2011-04-07 08:19:00 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 25/00023/R/31/A//2D 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 00/00019/R/60/A//6D 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 26/00025/O/31/201/0539/90 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 26/00023/R/31/A//2E 2011-04-07 08:19:41 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 27/00025/O/31/201/0539/91 2011-04-07 09:19:04 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 27/00023/R/31/A//2F 2011-04-07 09:19:04 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 00/00019/R/60/A//6D So, the first question that arises is: why doesnt kannel re-connect automatically after 60 seconds like wait-ack* settings imply, and instead this happens only when the ack finally arrives after an hour? The second question is - in case the remote smsc fails to produce acks to keepalives properly, whats the way of ensuring the link is really alive? Lately, we're experiencing a lot of problems when the link went down on the other side and kannel does not notice that and keeps thinking the link is still alive. Moreover, when we're trying to reset such a undead link individually, everything fails, including killing the socket with tcpkill - kannel still does not bring the smsc down, and the only option left is shut down the kannel completely, including kill -9 bearerbox (because otherwise kannel never even finishes shutdown sequence) and performing a full restart.
Re: Ussd development with kannel
Hiii, I have received the gateway from my operator. We have successfully pushed the ussd message to the handset. The only problem is that when i give the value 2 to service_op then i don't get the *answer* option in my handset. According to my knowledge, value 2 in service_op stands for USSN request, right? I have tried various values in service_op but with no avail. I am still not getting the *answer* option in the handset. What am i missing. The Bind mode of the account that the operator has given me is Tx. The url that i m hitting is:- http:// ***.***.***.***:***/cgi-bin/sendsms?username=**password=from=***to=smsc=text=**metadata=smpp_service_op=*its_session_info=** 2011/3/15 gautam sasikumar gautam...@gmail.com Thank you.. 2011/3/15 Elton Hoxha elt...@gmail.com Download and install recent version, no patch is needed. 2011/3/15 gautam sasikumar gautam...@gmail.com H, Does this mean that kannel doesn't need a patch for USSD.??? 2011/3/15 Elton Hoxha elt...@gmail.com Its better to upgrade your kannel with latest version. After it, add to your conf file following lines, so you can talk to your USSDC. group = smpp-tlv name = mydata tag = 0x0501 type = integer length = 1 smsc-id = YourID After successfull binding, the following line within sms-service section, is an example of receiving MO USSD requests, sending all needed parameters to your application. get-url = http://IP:PORT /UssdServices.asmx/GetUssdRequest?metadata=%Doriginator=%pchoice=%areceiver=%PussdId=%I You can read the user guide about explanation of these parameters. 2011/3/15 gautam sasikumar gautam...@gmail.com h, I have an operator who is forwarding the request from his USSD to my server in smpp protocol. I was wondering about how am i to catch that request in kannel and forward it to my application. Will i be able to get the parameters like the mmi that the user sent, Any input that the user gives( Like 1 for sports, 2 for News etc), the session id of that particular session in the TLV parameters of the kannel or will i get all these parameters in the text of the message. 2011/3/14 Marcin Bockowski boc...@gmail.com 2011/3/14 gautam sasikumar gautam...@gmail.com: Hiii, I am developing USSD application which is at a basic stage. I was looking for a patch for USSD in kannel version 1.4.3. I have searched the whole web but in vain. I have three basic questions. 1 Does Kannel require a patch for implementing ussd?? 2 If Kannel does require a patch, then where can i find a patch? 3 What parameters do i have set in kannel to avail ussd facilities. Hey, it all depends on your USSDC provider and supported protocols... Kannel may be used as HTTP to SMPP gateway in some case. Kind Regards, -- Marcin Boćkowski tel. %2B48%2079%2069%200%2069%2079+48 79 69 0 69 79
Re: smpp throughput
What Kannel version are you using? I believe that up until 1.4.3 there were still issues with throughput which were finally fixed on CVS (now SVN) On Tue, Apr 12, 2011 at 2:13 AM, Konstantin Vayner pon...@appcell.net wrote: Hi List, When configuring thoughput for smpp connections, what may lead Kannel to send more submit_sm per second than the configured limit? Sometimes i see it trying to send up to 80 mps when configured to 50. (the counts are done by analyzing the logfile, since i dont see any normal way of doing this) And then - when it goes higher than the limit - it hits throttling error from the operator and the speed falls to the ground for a couple of seconds. Which overall results in us not being able to use the limit fully, because the setback after throttling error. Regards, Konstantin
Re: Re: Compile problems - any Mac OS X 10.6 users?
Hi Hujumuju, I'm having a problem very similar to the one you've posted. Were you able to solve it? Please let me know. Many thanks in advance and all the best, Francisco Oliveira (Fran) Here's your original post: Hello. I am trying to compile Kannel under Mac OS X 10.6 (Snow Leopard). I have Xcode 3.2 for Mac OS X 10.6 Snow Leopard + MacPorts configure goes fine and i have attached config,log to this message. Anyway, make fails: 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/usr/include/libxml2 -I/usr/include/openssl -L/opt/local/lib -o wmlscript/wmlsc wmlscript/wmlsc.o libgw.a libwmlscript.a libwap.a libgwlib.a -lssl -lresolv -lm -lpthread -lxml2 -lz -lpthread -licucore -lm -L/usr/lib -lcrypto -lssl Undefined symbols: _iconv_close, referenced from: _charset_convert in libgwlib.a(charset.o) _iconv, referenced from: _charset_convert in libgwlib.a(charset.o) _iconv_open, referenced from: _charset_convert in libgwlib.a(charset.o) ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [wmlscript/wmlsc] Error 1 Does anyone have experience with Max OS X? I've compile kannel sucesfully before on 10.5 (Leopard) machine. Thanks for any tips in advance.
Re: UCP keepalive ack problems
Ok , so this is irrelevant, my mistake ;) I assumed that this applied to any packet, and it only applies to op 51 (submit_sm in terms of ucp)? This explains why this doens have any effect on the behavior. To the other point however, this is UCP smsc, so configuration differs from smpp Instead of enquire-link theres keepalive and idle-timeout settings - which define how keepalive packets are sent And i have them configured, too... The question then remains, how do i control handling of broken keepalives on the other side? :( wait-ack* was my last bet... On Tue, Apr 12, 2011 at 4:42 PM, Rapture supp...@ims.co.ke wrote: Hi Konstantin, I think the problem you have is misappropriating variables for example Wait-ack means duration to wait for acknowledgment before the resending a message. Each message has to get an ack (acknowledgement) from the SMSC. Check user guide wait-ack number (seconds) A message is resent if the acknowledge from SMSC takes more than this time. Defaults to 60 seconds. It goes hand in hand with wait-ack-expire wait-ack-expire number Defines what kind of action should be taken if the the ack of a message expires. The options for this value are: 0x00 - disconnect/reconnect, (default) 0x01 - as is now, re-queue, but this could potentially result in the msg arriving twice 0x02 – just carry on waiting (given that the wait-ack should never expire this is the mst accurate) I believe what you are referring to for checking whether SMSC has gone away is enquire-link. If you set it to say 30 secs then it will keep enquiring every 30secs and if the SMSC is not available kannel will initiate a reconnect. You can also use reconnect-delay to control how much time before kannel tries to reconnect after it ‘discovers’ it is unbound default is 10secs. Rapture *From:* users-boun...@kannel.org [mailto:users-boun...@kannel.org] *On Behalf Of *Konstantin Vayner *Sent:* Tuesday, April 12, 2011 12:15 PM *To:* Kannel Users *Subject:* UCP keepalive ack problems Hello list, We have several UCP links to a certain operator's SMSC, here's one of the smscs configuration (excluding sensitive information of course) group = smsc smsc = emi smsc-id = smsc_x_mo2 log-file = /var/log/kannel/x_mo2.log log-level = 0 host = 1.2.3.4 port = 1234 smsc-username = xxx smsc-password = yyy keepalive = 30 idle-timeout = 120 source-addr-autodetect = yes allowed-smsc-id = smsc_x_mo2 flow-control = 0 window = 1 wait-ack = 60 wait-ack-expire = 0x00 (all the links are configured with keepalive=30 and idle-timeout=120 so that the links are never considered idle by kannel) some of the links are for outgoing traffic only, MT and DLR travel on these others are for incoming traffic only, MO travel there. naturally, most of our traffic is outgoing so the MT links are rarely idle, however even when they are, we see steady keepalive requests and ACKs for them going on on the MO links however, the situation is different. these are mostly idle, and keepalive requests do not work as expected. sometimes we get ACK on keepalive an *hour* after the original packet was sent (actually, this happens to every second keepalive packet according to the logs i'm looking at) To illustrate the problem, here's the log from such smsc link filtered by 60 and 31 packets dumped: (note that login *requests* are not listed as they are not dumped by kannel) Check out the bold lines - these are ack responses from the smsc that come back after an hour! 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 00/00019/R/60/A//6D 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 24/00025/O/31/201/0539/8E 2011-04-07 07:18:57 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 24/00023/R/31/A//2C 2011-04-07 07:19:28 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 25/00025/O/31/201/0539/8F *2011-04-07 08:19:00 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 25/00023/R/31/A//2D * 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 00/00019/R/60/A//6D 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 26/00025/O/31/201/0539/90 2011-04-07 08:19:01 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 26/00023/R/31/A//2E 2011-04-07 08:19:41 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 sending packet: 27/00025/O/31/201/0539/91 *2011-04-07 09:19:04 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 27/00023/R/31/A//2F * 2011-04-07 09:19:04 [8237] [19] DEBUG: EMI2[smsc_x_mo2]: emi2 parsing packet: 00/00019/R/60/A//6D So, the first question that arises is: why doesnt kannel re-connect automatically after 60 seconds like wait-ack* settings imply, and instead this happens only when the ack finally arrives after an hour? The second
Re: smpp throughput
The SVN trunk is rock solid, actually more stable than 1.4.3 for what matters. We've been using the SVN head for ages in production, handling _lots_ of traffic and never had any issues with it. Regards, Alex On Tue, Apr 12, 2011 at 8:34 PM, Konstantin Vayner pon...@appcell.netwrote: 1.4.3 :( And i do have a problem upgrading production environment to SVN / 1.5.0 - the client is not going to like the fact it's not *stable* release. On Tue, Apr 12, 2011 at 6:08 PM, Juan Nin jua...@gmail.com wrote: What Kannel version are you using? I believe that up until 1.4.3 there were still issues with throughput which were finally fixed on CVS (now SVN) On Tue, Apr 12, 2011 at 2:13 AM, Konstantin Vayner pon...@appcell.net wrote: Hi List, When configuring thoughput for smpp connections, what may lead Kannel to send more submit_sm per second than the configured limit? Sometimes i see it trying to send up to 80 mps when configured to 50. (the counts are done by analyzing the logfile, since i dont see any normal way of doing this) And then - when it goes higher than the limit - it hits throttling error from the operator and the speed falls to the ground for a couple of seconds. Which overall results in us not being able to use the limit fully, because the setback after throttling error. Regards, Konstantin
