Re: next dlr question
Iain, The queued DLRs, are as you initially suggest, they are waiting on the final response from the SMSC, i.e. until they get either delivered or an undeliverable (or a rejected submission) they will hang around waiting for that (assuming the mask you set is looking for them). I think queued is perhaps the wrong word to use really. Pending might well be better. As far as I am aware, if a DLR fails to be delivered it is not queued for a redelivery attempt. Regards Ben On 3 Apr 2007, at 05:32, Iain Dooley wrote: okay, so i understand that store-status is for queued messages, not for queued dlrs, but what does it mean when a dlr is queued? ie: DLR: 12 queued, using internal storage in my status report. does this mean that kannel is waiting to hear back from the smsc? or that kannel is waiting to deliver them to the dlr-url? every time a message is sent, i see: 2007-04-03 13:58:16 [94229] [4] INFO: Starting delivery report USER from SOURCE in my smsbox log. sometimes i see the error i reported earlier (connection reset by peer, error reading from fd 28). so if i see the 'starting delivery report' every single time i send a message, and then sometimes i see the error reading from fd 28, does that mean that these dlrs that fail remain queued or something? cheers iain
Special Characters and Kannel 1.4.1
Hi, I have a problem sending special characters in mobile terminated messages through Kannel. The Setup: Debian (Sarge), Kannel 1.4.1 (from .deb packages), libxml 2.6.16-7 SMSC: Vodafone Germany, EMI The Problem: I want to send the following test message: ABCDäöüÄÖÜß Each time I send this message I receive ABCDäößÄÖ§ñ on the mobile phone. Here are my requests to kannel: ISO-8859-1 encoded: http://SERVER:PORT/cgi-bin/sendsms?user=USERpassword=PASSto=RECIPIENTtext=ABCD%e4%f6%fc%c4%d6%dc%dfcharset=ISO-8859-1from=SHORTNUMBER smsbox.log says: 2007-04-03 11:23:49 [762] [3] INFO: sendsms sender:smsSender:SHORTNUMBER (IPADDRESS) to:RECIPIENT msg:ABCDäöüÄÖÜß This at least tells me that the characters are transmitted to kannel correctly but on the mobile I receive ABCDäößÄÖ§ñ If I send the following UTF-8 encoded request: http://SERVER:PORT/cgi-bin/sendsms?user=USERpassword=PASSto=RECIPIENTtext=ABCD%c3%a4%c3%b6%c3%bc%c3%84%c3%96%c3%9c%c3%9fcharset=UTF-8from=SHORTNUMBER smsbox.log says: 2007-04-03 11:29:12 [762] [3] INFO: sendsms sender:smsSender:SHORTNUMBER (IPADDRESS) to:RECIPIENT msg:ABCDäöüÃ84Ã96Ã9CÃ9F The Mobile still receives ABCDäößÄÖ§ñ It is interesting that at least ö, ä, Ö and Ä pass through correctly. How can I find out, why ü, Ü and ß get garbled? Regards, Markus
OTA DLR help needed!!!
Hi all, I am trying to configure ota-settings in kannel and also was able to send it thru http, but the problem is that , the dlrs r not getting saved at the time when I m sending message. If anybody knaow anything about this please help. Message s r going but , dlrs are not getting saved.[:-(] Thanx and regards, Tushar
OTA DLR help needed!!!
Hi all, I am trying to configure ota-settings in kannel and also was able to send it thru http, but the problem is that , the dlrs r not getting saved at the time when I m sending message. If anybody knaow anything about this please help. Message s r going but , dlrs are not getting saved. HOW TO GET DLRs FOR OTA PUSH MESSAGES? [:-(] Thanx and regards, Tushar
Re: One SMSC conf per shot code
Normally SMPP can act as a transmitter, a receiver or a transceiver (transmit+receiver). The carrier want you to know that you need to create a connection with transmit and one connection with receive, and not only one with transceiver. J Diego Helmann ha scritto: Hi all I have to connect to one cell operartor that is asking me to make one connection per shortnumber: Information for connecting: --- (Shortcode 1234) IP: aaa.bbb.ccc.ddd Port: 4000 *Source: 1234* System ID: Password: System Type: smpp Source TON: 2 Source NPI: 1 Destination TON: 2 Destination NPI: 1 One bind for Rx, and one bind for Tx. --- My conf is like: group = smsc smsc = smpp smsc-id = carrier1 allowed-smsc-id = carrier1 host = aaa.bbb.ccc.ddd port = 4000 receive-port = 4000 smsc-username = smsc-password = system-type = smpp reconnect-delay = 10 address-range = connect-allow-ip = aaa.bbb.ccc.ddd source-addr-ton = 2 source-addr-npi = 1 dest-addr-ton = 2 dest-addr-npi = 1 But, I need to connec for short number 1234 and 5678 1) How can I tell kannel that a connection is for certain short number? 2) What One bind for Rx, and one bind for Tx. means? That I have to set: port = 4000 receive-port = 4000 ??? Thanks in advance Regards Diego
RE: One SMSC conf per shot code
Hi, Please find the how to route the sms part in the user guide, it can help you to solve the problem. Regards Willy
html tags not working in SMS
Dear All, i want to send formatted text msg which can support new line character i have tried echo stringbrstring but displays stringstring echo string.chr(13).string but string string echo nl2br(string\nstring) but stringstring plz help me in this case, i am using php with kannel for sms request reply. Regards, Iftikhar.
Re: Latest CVS problem
Ashwani, Thanks for your reply. I'm calling the sendsms the same way I was doing for the last 3 years: http://url:port/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmsctext=Hello No big deal there, pretty regular stuff. I've lowered the log level and found that they are pretty normal, except for smsbox.log: 2007-04-03 02:53:42 [14437] [2] DEBUG: HTTP: Created HTTPClient area 0x83f37c0. 2007-04-03 02:53:42 [14437] [3] INFO: smsbox: Got HTTP request /cgi-bin/sendsms from 190.64.196.8 2007-04-03 02:53:42 [14437] [3] INFO: sendsms used by foo 2007-04-03 02:53:42 [14437] [3] INFO: sendsms sender:foo:1234 (1.2.3.4) to:59899790830 msg:HOLA 2007-04-03 02:53:42 [14437] [3] DEBUG: Stored UUID 60225f41-f5d5-44bc-bc40-d5ec0adf5c35 2007-04-03 02:53:42 [14437] [3] DEBUG: message length 4, sending 1 messages 2007-04-03 02:53:42 [14437] [3] DEBUG: Status: 202 Answer: Sent. 2007-04-03 02:53:42 [14437] [3] DEBUG: Delayed reply - wait for bearerbox 2007-04-03 02:53:42 [14437] [0] DEBUG: Got ACK (0) of 302d1d81-c96f-47ee-8c0f-db51d6a5a283 2007-04-03 02:53:42 [14437] [0] DEBUG: No client - multi-send or ACK to pull-reply If I'm not wrong, that means that smsbox keeps waiting for bearerbox to return something, but then when the ACK arrives the no client error arises. Setting immediate-sendsms-reply to false I can solve the problem, but then I lost the ability to detect some failed messages (I always get a Sent). I rely on those failures to mitigate the lack of DLRs (the carriers we are working with does not allow for DLRs so we use all sort of workarounds to try to get closer to reality in terms of message statistics). Thank you in advance, Alejandro Guerrieri On 4/3/07, ashwani [EMAIL PROTECTED] wrote: Hello, How are u submitting the message to kannel? Kindly share the URL. Also, please paste the bearbox log when u submit the message. BTW you have chosen log level as 2 which means critical logs only. Change it to 0 and then check the logs. Ashwani Kumar Sr. Engineer Professional Services Phone: +91 11 26686000 Fax: +91 11 26671230 Mobile: +91 9911761010 Web: www.telegentelecom.com Express More Everybody has changed 2 SMS in Color. U should 2 This message contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended exclusively for the use of the addressee(s) named above. Any disclosure, distribution, copying or use of the information by others is strictly prohibited. If you are not the addressee, or a person responsible for delivering the message to the addressee, or if you have simply received this message in error, please do not make any use of it nor disclose any of its contents to anyone and please advise the sender by immediate reply and delete the original message. E-mails are susceptible to corruption, interception and unauthorized amendment, Tele-Gen does not accept any liability for any such changes or for their consequences and maintains the right to take legal action where necessary. Thank you for your co-operation and compliance. -Original Message- From: Alejandro Guerrieri [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 12:17 AM To: users@kannel.org Subject: Latest CVS problem Hi all, I'm having problems in getting the latest CVS to run on CentOS 4.4. It compiles and runs OK, but when I try sending a message from the sendsms HTTP interface, the message gets sent but the HTTP connection doesn't return nor displays anything on the browser. It just get stuck there. Anybody else experienced the same problem? I'm currently using a 2006-11-13 snapshot with no problems, but when I update it to the latest CVS this problem arise. I've never had this problem before (I've compiled and upgraded Kannel tenths of times on CentOS without any issues). Here is part of my conf file: group = core admin-port = 13000 smsbox-port = 13001 #wapbox-port = 13002 wdp-interface-name = * admin-password = oo status-password = xx dlr-storage = mysql #admin-deny-ip = admin-allow-ip = xx box-deny-ip = *.*.*.* box-allow-ip = x access-log = /var/log/kannel/access.log log-file = /var/log/kannel/kannel.log log-level = 2 store-file = /home/kannel/kannel.store # SMSBOX SETUP group = smsbox bearerbox-host = localhost sendsms-port = 13013 log-file = /var/log/kannel/smsbox.log access-log = /var/log/kannel/access.log log-level = 2 http-request-retry = 5 # SEND-SMS USERS group = sendsms-user username = password = Am I missing something? Maybe some new parameters that I should include, or is it a bug on the code? Thank you in advance, Alejandro. -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri
Re: Special Characters and Kannel 1.4.1
Hi Markus, Have you tried with another SMSC connection. I know that TDC in Denmark for instance can't handle the swedish characters ÄÖ, and they will replace it with hte danosh characters ÆØ. I'm not sure, but it might be the issue, so try to test it with another SMSC, or try asking Vodafone. .. Med venlig hilsen / Best Regards *Mads N. Vestergaard* *Teknisk ansvarlig / CTO CoolSMS* www.coolsms.com http://www.coolsms.com/ Phone: +45 7026 1272 Fax:+45 7630 1046 Mobile: +45 5050 4222 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Markus R. skrev: Hi, I have a problem sending special characters in mobile terminated messages through Kannel. The Setup: Debian (Sarge), Kannel 1.4.1 (from .deb packages), libxml 2.6.16-7 SMSC: Vodafone Germany, EMI The Problem: I want to send the following test message: ABCDäöüÄÖÜß Each time I send this message I receive ABCDäößÄÖ§ñ on the mobile phone. Here are my requests to kannel: ISO-8859-1 encoded: http://SERVER:PORT/cgi-bin/sendsms?user=USERpassword=PASSto=RECIPIENTtext=ABCD%e4%f6%fc%c4%d6%dc%dfcharset=ISO-8859-1from=SHORTNUMBER smsbox.log says: 2007-04-03 11:23:49 [762] [3] INFO: sendsms sender:smsSender:SHORTNUMBER (IPADDRESS) to:RECIPIENT msg:ABCDäöüÄÖÜß This at least tells me that the characters are transmitted to kannel correctly but on the mobile I receive ABCDäößÄÖ§ñ If I send the following UTF-8 encoded request: http://SERVER:PORT/cgi-bin/sendsms?user=USERpassword=PASSto=RECIPIENTtext=ABCD%c3%a4%c3%b6%c3%bc%c3%84%c3%96%c3%9c%c3%9fcharset=UTF-8from=SHORTNUMBER smsbox.log says: 2007-04-03 11:29:12 [762] [3] INFO: sendsms sender:smsSender:SHORTNUMBER (IPADDRESS) to:RECIPIENT msg:ABCDäöüÃ84Ã96Ã9CÃ9F The Mobile still receives ABCDäößÄÖ§ñ It is interesting that at least ö, ä, Ö and Ä pass through correctly. How can I find out, why ü, Ü and ß get garbled? Regards, Markus
DLR with EMI interface
Hi I'm trying to get DLR working with EMI backend over Swisscom. As it seams kannel does not set NRq (Notification Request) flag. I have the following configuration: group = smsc smsc = emi smsc-id = swisscom host = xxx.xxx.xxx.xxx port = 4100 smsc-username = smsc-password = x notification-pid = 0539 notification-addr = 2020 receive-port = 2020 connect-allow-ip = xxx.xxx.xxx.xxx keepalive = 55 idle-timeout = 60 throughput = 1 log-file = /var/log/kannel/smsc-swisscom.log log-level = 0 Do you have any idea ? Do I miss something? Best regards Matthias Cramer -- Matthias Cramer / mc322-ripe System Network Manager Interway Communication GmbHPhone +41 43 500 Josefstrasse 225 Fax +41 44 271 3535 CH-8005 Zürich http://www.interway.ch/ GnuPG 1024D/2D208250 = DBC6 65B6 7083 1029 781E 3959 B62F DF1C 2D20 8250 signature.asc Description: OpenPGP digital signature
DLR with EMI interface
Hi Please forgive me ... forget my previous mail... I was unable to write dlr-mask correctly. Best regards Matthias Cramer -- Matthias Cramer / mc322-ripe System Network Manager Interway Communication GmbHPhone +41 43 500 Josefstrasse 225 Fax +41 44 271 3535 CH-8005 Zürich http://www.interway.ch/ GnuPG 1024D/2D208250 = DBC6 65B6 7083 1029 781E 3959 B62F DF1C 2D20 8250 signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: Anyone having a working wap setup with huawei 20001x
Goksie wrote:
Hello all,
I have a kannel wap setup and i want to interconnect with huawei smsc /
pdsn.
What i need now... i am looking for someone who can give me a working
config especially anyone that has a working connection with huawei cdma
20001x settings.
Hello Goksie,
now, it's not clear to me what you are demanding?
You want Kannel act as WAP PPG (push proxy gateway) to connect to a HUAWEI SMSC?
is that correct?
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: Special Characters and Kannel 1.4.1
Hi, this one did the trick, thanks! It's a hack, but now, it works as expected. When I find much time, I'll dig for the real solution (probably never :-). Thanks again, Markus On 4/3/07, Rodrigo Cremaschi [EMAIL PROTECTED] wrote: Hi Markus, A hack for this problem: generate an MO with the special chars and send it to Kannel. Use the characters you receive as a dictionary to encode your MTs. Regards, Rodrigo. On 4/3/07, Markus R. [EMAIL PROTECTED] wrote: Hi, I have a problem sending special characters in mobile terminated messages through Kannel. The Setup: Debian (Sarge), Kannel 1.4.1 (from .deb packages), libxml 2.6.16-7 SMSC: Vodafone Germany, EMI The Problem: I want to send the following test message: ABCDäöüÄÖÜß Each time I send this message I receive ABCDäößÄÖ§ñ on the mobile phone. Here are my requests to kannel: ISO-8859-1 encoded: http://SERVER:PORT/cgi-bin/sendsms?user=USERpassword=PASSto=RECIPIENTtext=ABCD%e4%f6%fc%c4%d6%dc%dfcharset=ISO-8859-1from=SHORTNUMBER smsbox.log says: 2007-04-03 11:23:49 [762] [3] INFO: sendsms sender:smsSender:SHORTNUMBER (IPADDRESS) to:RECIPIENT msg:ABCDäöüÄÖÜß This at least tells me that the characters are transmitted to kannel correctly but on the mobile I receive ABCDäößÄÖ§ñ If I send the following UTF-8 encoded request: http://SERVER:PORT/cgi-bin/sendsms?user=USERpassword=PASSto=RECIPIENTtext=ABCD%c3%a4%c3%b6%c3%bc%c3%84%c3%96%c3%9c%c3%9fcharset=UTF-8from=SHORTNUMBER smsbox.log says: 2007-04-03 11:29:12 [762] [3] INFO: sendsms sender:smsSender:SHORTNUMBER (IPADDRESS) to:RECIPIENT msg:ABCDäöüÃ84Ã96Ã9CÃ9F The Mobile still receives ABCDäößÄÖ§ñ It is interesting that at least ö, ä, Ö and Ä pass through correctly. How can I find out, why ü, Ü and ß get garbled? Regards, Markus
Re: Latest CVS problem
Alejandro Guerrieri wrote:
Ashwani,
Thanks for your reply.
I'm calling the sendsms the same way I was doing for the last 3 years:
http://url:port/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmsctext=Hello
No big deal there, pretty regular stuff.
I've lowered the log level and found that they are pretty normal,
except for smsbox.log:
2007-04-03 02:53:42 [14437] [2] DEBUG: HTTP: Created HTTPClient area
0x83f37c0.
2007-04-03 02:53:42 [14437] [3] INFO: smsbox: Got HTTP request
/cgi-bin/sendsms from 190.64.196.8
2007-04-03 02:53:42 [14437] [3] INFO: sendsms used by foo
2007-04-03 02:53:42 [14437] [3] INFO: sendsms sender:foo:1234
(1.2.3.4) to:59899790830 msg:HOLA
2007-04-03 02:53:42 [14437] [3] DEBUG: Stored UUID
60225f41-f5d5-44bc-bc40-d5ec0adf5c35
2007-04-03 02:53:42 [14437] [3] DEBUG: message length 4, sending 1 messages
2007-04-03 02:53:42 [14437] [3] DEBUG: Status: 202 Answer: Sent.
2007-04-03 02:53:42 [14437] [3] DEBUG: Delayed reply - wait for bearerbox
2007-04-03 02:53:42 [14437] [0] DEBUG: Got ACK (0) of
302d1d81-c96f-47ee-8c0f-db51d6a5a283
2007-04-03 02:53:42 [14437] [0] DEBUG: No client - multi-send or ACK
to pull-reply
If I'm not wrong, that means that smsbox keeps waiting for bearerbox
to return something, but then when the ACK arrives the no client
error arises.
hmmm... this is strange.
The last debug() we see here is from this block in smsbox:
client = dict_remove(client_dict, os);
if (client == NULL) {
debug(sms.http, 0, No client - multi-send or ACK to pull-reply);
octstr_destroy(os);
return;
}
which means, we pull the HTTPClient structure out of the hash dict in order to
be able to send back the HTTP response to it. While we do dict_remove(), which
should return the referenced hash entry of the msg UUID, you get NULL as result,
and hence debug() is dumped.
Are you sure that the HTTP client is waiting for the response of smsbox's HTTP
server? Can you try to use test/test_http as HTTP client to do the call and log
the output and send it to the list for review.
There must be some issue 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: Special Characters and Kannel 1.4.1
Markus R. wrote:
Hi,
I have a problem sending special characters in mobile terminated
messages through Kannel.
The Setup: Debian (Sarge), Kannel 1.4.1 (from .deb packages), libxml
2.6.16-7
SMSC: Vodafone Germany, EMI
The Problem: I want to send the following test message: ABCDäöüÄÖÜß
Each time I send this message I receive ABCDäößÄÖ§ñ on the mobile phone.
Here are my requests to kannel:
ISO-8859-1 encoded:
http://SERVER:PORT/cgi-bin/sendsms?user=USERpassword=PASSto=RECIPIENTtext=ABCD%e4%f6%fc%c4%d6%dc%dfcharset=ISO-8859-1from=SHORTNUMBER
smsbox.log says:
2007-04-03 11:23:49 [762] [3] INFO: sendsms
sender:smsSender:SHORTNUMBER (IPADDRESS) to:RECIPIENT
msg:ABCDäöüÄÖÜß
This at least tells me that the characters are transmitted to kannel
correctly but on the mobile I receive ABCDäößÄÖ§ñ
If I send the following UTF-8 encoded request:
http://SERVER:PORT/cgi-bin/sendsms?user=USERpassword=PASSto=RECIPIENTtext=ABCD%c3%a4%c3%b6%c3%bc%c3%84%c3%96%c3%9c%c3%9fcharset=UTF-8from=SHORTNUMBER
smsbox.log says:
2007-04-03 11:29:12 [762] [3] INFO: sendsms
sender:smsSender:SHORTNUMBER (IPADDRESS) to:RECIPIENT
msg:ABCDäöüÃ84Ã96Ã9CÃ9F
The Mobile still receives ABCDäößÄÖ§ñ
It is interesting that at least ö, ä, Ö and Ä pass through correctly.
How can I find out, why ü, Ü and ß get garbled?
now, I recall all this for Vodafone D2 years ago. I added the alt-charset things
for Vodafone D2 here to the EMI/UCP module of Kannel.
See user's guide section for UCP smsc group:
http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN1382
where you find:
alt-charset - number - Defines which character conversion kludge may be used for
this specific link. Currently implemented alternative charsets are defined in
alt_charsets.h and new ones can be added.
and in alt_charsets.h:
/*
* for CMG's EMI/UCP, operators may use NCR (national representation
* codes), like ISO 21 German for the german Umlauts.
* i.e. Vodafone D2 uses this charset kludges.
*/
#define EMI_NRC_ISO_21 3
this means setting:
group = smsc
smsc = emi
...
alt-charset = 3
...
should do the kludge to use ISO 21 German representation for UCP/EMI connection
and will map the ISO latin1 values internally. ;)
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
---
email2sms.pl script
Hi Does anyone has this script ? and some instructions on how to use it? I've been googling arround and it is not available anymore on the web www.easitext.com in not longer available... as far as I could found ... well NOT found ;-) Regards Alvaro
Re: Latest CVS problem
Stipe,
I've tried with wget on localhost and firefox remotely.
wget keep on waiting after showing HTTP request sent, awaiting
response... . Firefox displays the spinning gear for hours. It
doesn't timeout in either case.
I've dig into the code and found the same block. I think some other
people experienced this problem in the past (I've Googled for it and
found some posts on this list) but never get answered.
I'll try with the test_http and post the results.
Regards,
Alejandro
On 4/3/07, Stipe Tolj [EMAIL PROTECTED] wrote:
Alejandro Guerrieri wrote:
Ashwani,
Thanks for your reply.
I'm calling the sendsms the same way I was doing for the last 3 years:
http://url:port/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmsctext=Hello
No big deal there, pretty regular stuff.
I've lowered the log level and found that they are pretty normal,
except for smsbox.log:
2007-04-03 02:53:42 [14437] [2] DEBUG: HTTP: Created HTTPClient area
0x83f37c0.
2007-04-03 02:53:42 [14437] [3] INFO: smsbox: Got HTTP request
/cgi-bin/sendsms from 190.64.196.8
2007-04-03 02:53:42 [14437] [3] INFO: sendsms used by foo
2007-04-03 02:53:42 [14437] [3] INFO: sendsms sender:foo:1234
(1.2.3.4) to:59899790830 msg:HOLA
2007-04-03 02:53:42 [14437] [3] DEBUG: Stored UUID
60225f41-f5d5-44bc-bc40-d5ec0adf5c35
2007-04-03 02:53:42 [14437] [3] DEBUG: message length 4, sending 1 messages
2007-04-03 02:53:42 [14437] [3] DEBUG: Status: 202 Answer: Sent.
2007-04-03 02:53:42 [14437] [3] DEBUG: Delayed reply - wait for bearerbox
2007-04-03 02:53:42 [14437] [0] DEBUG: Got ACK (0) of
302d1d81-c96f-47ee-8c0f-db51d6a5a283
2007-04-03 02:53:42 [14437] [0] DEBUG: No client - multi-send or ACK
to pull-reply
If I'm not wrong, that means that smsbox keeps waiting for bearerbox
to return something, but then when the ACK arrives the no client
error arises.
hmmm... this is strange.
The last debug() we see here is from this block in smsbox:
client = dict_remove(client_dict, os);
if (client == NULL) {
debug(sms.http, 0, No client - multi-send or ACK to pull-reply);
octstr_destroy(os);
return;
}
which means, we pull the HTTPClient structure out of the hash dict in order to
be able to send back the HTTP response to it. While we do dict_remove(), which
should return the referenced hash entry of the msg UUID, you get NULL as result,
and hence debug() is dumped.
Are you sure that the HTTP client is waiting for the response of smsbox's HTTP
server? Can you try to use test/test_http as HTTP client to do the call and log
the output and send it to the list for review.
There must be some issue 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
---
--
Alejandro Guerrieri
Magicom
http://www.magicom-bcn.net/
LinkedIn: http://www.linkedin.com/in/aguerrieri
Re: Latest CVS problem
OK, I've made tests using test_http with and without inmediate-sendsms-reply (i-s-r from now on). With i-s-r line commented: ]# ./test_http -v0 http://localhost:13013/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA; 2007-04-03 17:44:45 [4145] [0] INFO: Starting fetch 0 2007-04-03 17:44:45 [4145] [0] DEBUG: Started thread 1 (gwlib/fdset.c:poller) 2007-04-03 17:44:45 [4145] [0] DEBUG: Started thread 2 (gwlib/http.c:write_request_thread) 2007-04-03 17:44:45 [4145] [0] DEBUG: Started request 0 with url: 2007-04-03 17:44:45 [4145] [0] DEBUG: Octet string at 0x99531e0: 2007-04-03 17:44:45 [4145] [0] DEBUG: len: 123 2007-04-03 17:44:45 [4145] [0] DEBUG: size: 124 2007-04-03 17:44:45 [4145] [0] DEBUG: immutable: 0 2007-04-03 17:44:45 [4145] [0] DEBUG: data: 68 74 74 70 3a 2f 2f 6c 6f 63 61 6c 68 6f 73 74 http://localhost 2007-04-03 17:44:45 [4145] [0] DEBUG: data: 3a 31 33 30 31 33 2f 63 67 69 2d 62 69 6e 2f 73 :13013/cgi-bin/s 2007-04-03 17:44:45 [4145] [0] DEBUG: data: 65 6e 64 73 6d 73 3f 75 73 65 72 6e 61 6d 65 3d endsms?username= ... 2007-04-03 17:44:45 [4145] [0] DEBUG: data: 6c 26 74 65 78 74 3d 48 4f 4c 41 text=HOLA 2007-04-03 17:44:45 [4145] [0] DEBUG: Octet string dump ends. 2007-04-03 17:44:45 [4145] [1] DEBUG: Thread 1 (gwlib/fdset.c:poller) maps to pid 4145. 2007-04-03 17:44:45 [4145] [2] DEBUG: Thread 2 (gwlib/http.c:write_request_thread) maps to pid 4145. 2007-04-03 17:44:45 [4145] [2] DEBUG: Parsing URL `http://localhost:13013/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA': 2007-04-03 17:44:45 [4145] [2] DEBUG: Scheme: http:// 2007-04-03 17:44:45 [4145] [2] DEBUG: Host: localhost 2007-04-03 17:44:45 [4145] [2] DEBUG: Port: 13013 2007-04-03 17:44:45 [4145] [2] DEBUG: Username: (null) 2007-04-03 17:44:45 [4145] [2] DEBUG: Password: (null) 2007-04-03 17:44:45 [4145] [2] DEBUG: Path: /cgi-bin/sendsms 2007-04-03 17:44:45 [4145] [2] DEBUG: Query: username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA 2007-04-03 17:44:45 [4145] [2] DEBUG: Fragment: (null) 2007-04-03 17:44:45 [4145] [2] DEBUG: HTTP: Opening connection to `localhost:13013' (fd=13). 2007-04-03 17:44:45 [4145] [2] DEBUG: Socket connecting 2007-04-03 17:44:45 [4145] [1] DEBUG: Get info about connecting socket 2007-04-03 17:44:45 [4145] [1] DEBUG: HTTP: Sending request: 2007-04-03 17:44:45 [4145] [1] DEBUG: Octet string at 0x993fb80: 2007-04-03 17:44:45 [4145] [1] DEBUG: len: 178 2007-04-03 17:44:45 [4145] [1] DEBUG: size: 1024 2007-04-03 17:44:45 [4145] [1] DEBUG: immutable: 0 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 47 45 54 20 2f 63 67 69 2d 62 69 6e 2f 73 65 6e GET /cgi-bin/sen ... 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 74 65 78 74 3d 48 4f 4c 41 20 48 54 54 50 2f 31 text=HOLA HTTP/1 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 2e 31 0d 0a 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 .1..Host: localh 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 6f 73 74 3a 31 33 30 31 33 0d 0a 43 6f 6e 6e 65 ost:13013..Conne 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 63 74 69 6f 6e 3a 20 6b 65 65 70 2d 61 6c 69 76 ction: keep-aliv 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 65 0d 0a 58 2d 54 68 72 65 61 64 3a 20 30 0d 0a e..X-Thread: 0.. 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 0d 0a .. 2007-04-03 17:44:45 [4145] [1] DEBUG: Octet string dump ends. And it stays there forever. With i-s-r set to TRUE: ]# ./test_http -v0 http://localhost:13013/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA; ]# ./test_http -v0 http://localhost:13013/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA; 2007-04-03 17:47:02 [4199] [0] INFO: Starting fetch 0 2007-04-03 17:47:02 [4199] [0] DEBUG: Started thread 1 (gwlib/fdset.c:poller) 2007-04-03 17:47:02 [4199] [0] DEBUG: Started thread 2 (gwlib/http.c:write_request_thread) 2007-04-03 17:47:02 [4199] [0] DEBUG: Started request 0 with url: 2007-04-03 17:47:02 [4199] [0] DEBUG: Octet string at 0x9f9c1e0: 2007-04-03 17:47:02 [4199] [0] DEBUG: len: 123 2007-04-03 17:47:02 [4199] [0] DEBUG: size: 124 2007-04-03 17:47:02 [4199] [0] DEBUG: immutable: 0 2007-04-03 17:47:02 [4199] [0] DEBUG: data: 68 74 74 70 3a 2f 2f 6c 6f 63 61 6c 68 6f 73 74 http://localhost ... 2007-04-03 17:47:02 [4199] [0] DEBUG: data: 6c 26 74 65 78 74 3d 48 4f 4c 41 ltext=HOLA 2007-04-03 17:47:02 [4199] [0] DEBUG: Octet string dump ends. 2007-04-03 17:47:02 [4199] [1] DEBUG: Thread 1 (gwlib/fdset.c:poller) maps to pid 4199. 2007-04-03 17:47:02 [4199] [2] DEBUG: Thread 2 (gwlib/http.c:write_request_thread) maps to pid 4199. 2007-04-03 17:47:02 [4199] [2] DEBUG: Parsing URL `http://localhost:13013/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA': 2007-04-03 17:47:02 [4199] [2] DEBUG: Scheme: http:// 2007-04-03 17:47:02 [4199] [2] DEBUG:
RE: Forcing SMSC doesn't work
Hello all I seem to have cracked this problem by making sure all the other SMSCs are listed under denied-smsc-id. For example, under SMSC-T1.A should be the following configuration parameters: group = smsc smsc = smpp smsc-id = SMSC-T1.A allowed-prefix = 027;6427;+6427;021;6421;+6421; preferred-prefix = 027;6427;+6427 denied-smsc-id = SMSC-T1.B;SMSC-T1.C;SMSC-T2.A -- had to include the SMSC(s) for the other telco here preferred-smsc-id = SMSC-T1.A Messages have been pushed out on the requested SMSC 100% of the time now. David -Original Message- From: David Ritchie [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 April 2007 1:48 p.m. To: users@kannel.org Subject: Forcing SMSC doesn't work Hi -- when doing an MT push, I want to force the SMSC I want messages to go out on, regardless of what the handset's prefix happens to be. However, it doesn't seem to work -- messages just go out on a random SMSC, even when I include a smsc= value in the MT push URL. We're recently suffering the overhead of the telcos rolling out number portability, and want to achieve the following: -- force a message to be pushed to a specific SMSC, provided the SMSC is specified in the push URL -- set a default SMSC (or group of SMSCs) for a prefix, in case the SMSC *isn't* specified -- and have confidence it'll all work. I am currently connected to 4 SMSCs, 3 providing connectivity to telco T1 (call these SMSC-T1.A through SMSC-T1.C), and one connected to telco T2 (SMSC-T2.A). Previously if I pushed out to a handset prefixed with 6427, it went out (randomly) through one of the 3 SMSCs connected to telco T1. The three smsc groups looked like this: group = smsc smsc = smpp smsc-id = SMSC-T1.A [ this changed between SMSCs ] allowed-prefix = 027;6427;+6427 denied-smsc-id = SMS-T1.B;SMS-T1.C [ obviously this was different between SMSCs ] preferred-smsc-id = smsc-t1a And the fourth SMSC (to the other telco) was along these lines: group = smsc smsc = smpp smsc-id = SMSC-T2.A allowed-prefix = 021;6421;+6421 (Judging from these prefixes, you can probably guess what country I am in.) With number portability, messages sent to handsets beginning with 6427 could potentially be forced to be sent out through telco T2; likewise handsets prefixed with 6421 might have to have messages pushed out through one of the SMSCs associated with telco T1. So I tried a test -- knowing a handset number which happened to have been ported from T1 to T2, but still keeping the 6427 prefix, I made some changes to the Kannel configuration, namely changing the allowed prefixes for all the SMSCs to allow all prefixes: allowed-prefix = 027;6427;+6427;021;6421;+6421; I also added a preferred-prefix value in case we tried to push out messages without specifying the SMSC preferred-prefix = 021;6421;+6421 The URL I requested included a value for smsc set to SMSC-T2.A (url-encoded), and assumed this would forced the message to go out through SMSC-T2.A; instead the message goes to *any* of the four SMSCs (since they've all got 6427 as a valid prefix). It appears to be a random choice between the four. Your advice is appreciated. David
Re: Latest CVS problem
Alejandro Guerrieri wrote: OK, I've made tests using test_http with and without inmediate-sendsms-reply (i-s-r from now on). With i-s-r line commented: ]# ./test_http -v0 http://localhost:13013/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA; 2007-04-03 17:44:45 [4145] [0] INFO: Starting fetch 0 2007-04-03 17:44:45 [4145] [0] DEBUG: Started thread 1 (gwlib/fdset.c:poller) 2007-04-03 17:44:45 [4145] [0] DEBUG: Started thread 2 (gwlib/http.c:write_request_thread) 2007-04-03 17:44:45 [4145] [0] DEBUG: Started request 0 with url: 2007-04-03 17:44:45 [4145] [0] DEBUG: Octet string at 0x99531e0: 2007-04-03 17:44:45 [4145] [0] DEBUG: len: 123 2007-04-03 17:44:45 [4145] [0] DEBUG: size: 124 2007-04-03 17:44:45 [4145] [0] DEBUG: immutable: 0 2007-04-03 17:44:45 [4145] [0] DEBUG: data: 68 74 74 70 3a 2f 2f 6c 6f 63 61 6c 68 6f 73 74 http://localhost 2007-04-03 17:44:45 [4145] [0] DEBUG: data: 3a 31 33 30 31 33 2f 63 67 69 2d 62 69 6e 2f 73 :13013/cgi-bin/s 2007-04-03 17:44:45 [4145] [0] DEBUG: data: 65 6e 64 73 6d 73 3f 75 73 65 72 6e 61 6d 65 3d endsms?username= ... 2007-04-03 17:44:45 [4145] [0] DEBUG: data: 6c 26 74 65 78 74 3d 48 4f 4c 41 text=HOLA 2007-04-03 17:44:45 [4145] [0] DEBUG: Octet string dump ends. 2007-04-03 17:44:45 [4145] [1] DEBUG: Thread 1 (gwlib/fdset.c:poller) maps to pid 4145. 2007-04-03 17:44:45 [4145] [2] DEBUG: Thread 2 (gwlib/http.c:write_request_thread) maps to pid 4145. 2007-04-03 17:44:45 [4145] [2] DEBUG: Parsing URL `http://localhost:13013/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA': 2007-04-03 17:44:45 [4145] [2] DEBUG: Scheme: http:// 2007-04-03 17:44:45 [4145] [2] DEBUG: Host: localhost 2007-04-03 17:44:45 [4145] [2] DEBUG: Port: 13013 2007-04-03 17:44:45 [4145] [2] DEBUG: Username: (null) 2007-04-03 17:44:45 [4145] [2] DEBUG: Password: (null) 2007-04-03 17:44:45 [4145] [2] DEBUG: Path: /cgi-bin/sendsms 2007-04-03 17:44:45 [4145] [2] DEBUG: Query: username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA 2007-04-03 17:44:45 [4145] [2] DEBUG: Fragment: (null) 2007-04-03 17:44:45 [4145] [2] DEBUG: HTTP: Opening connection to `localhost:13013' (fd=13). 2007-04-03 17:44:45 [4145] [2] DEBUG: Socket connecting 2007-04-03 17:44:45 [4145] [1] DEBUG: Get info about connecting socket 2007-04-03 17:44:45 [4145] [1] DEBUG: HTTP: Sending request: 2007-04-03 17:44:45 [4145] [1] DEBUG: Octet string at 0x993fb80: 2007-04-03 17:44:45 [4145] [1] DEBUG: len: 178 2007-04-03 17:44:45 [4145] [1] DEBUG: size: 1024 2007-04-03 17:44:45 [4145] [1] DEBUG: immutable: 0 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 47 45 54 20 2f 63 67 69 2d 62 69 6e 2f 73 65 6e GET /cgi-bin/sen ... 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 74 65 78 74 3d 48 4f 4c 41 20 48 54 54 50 2f 31 text=HOLA HTTP/1 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 2e 31 0d 0a 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 .1..Host: localh 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 6f 73 74 3a 31 33 30 31 33 0d 0a 43 6f 6e 6e 65 ost:13013..Conne 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 63 74 69 6f 6e 3a 20 6b 65 65 70 2d 61 6c 69 76 ction: keep-aliv 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 65 0d 0a 58 2d 54 68 72 65 61 64 3a 20 30 0d 0a e..X-Thread: 0.. 2007-04-03 17:44:45 [4145] [1] DEBUG: data: 0d 0a .. 2007-04-03 17:44:45 [4145] [1] DEBUG: Octet string dump ends. And it stays there forever. ok, so here we simply never get a response from the HTTP server (smsbox). With i-s-r set to TRUE: ]# ./test_http -v0 http://localhost:13013/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA; 2007-04-03 17:47:02 [4199] [0] INFO: Starting fetch 0 2007-04-03 17:47:02 [4199] [0] DEBUG: Started thread 1 (gwlib/fdset.c:poller) 2007-04-03 17:47:02 [4199] [0] DEBUG: Started thread 2 (gwlib/http.c:write_request_thread) 2007-04-03 17:47:02 [4199] [0] DEBUG: Started request 0 with url: 2007-04-03 17:47:02 [4199] [0] DEBUG: Octet string at 0x9f9c1e0: 2007-04-03 17:47:02 [4199] [0] DEBUG: len: 123 2007-04-03 17:47:02 [4199] [0] DEBUG: size: 124 2007-04-03 17:47:02 [4199] [0] DEBUG: immutable: 0 2007-04-03 17:47:02 [4199] [0] DEBUG: data: 68 74 74 70 3a 2f 2f 6c 6f 63 61 6c 68 6f 73 74 http://localhost ... 2007-04-03 17:47:02 [4199] [0] DEBUG: data: 6c 26 74 65 78 74 3d 48 4f 4c 41 ltext=HOLA 2007-04-03 17:47:02 [4199] [0] DEBUG: Octet string dump ends. 2007-04-03 17:47:02 [4199] [1] DEBUG: Thread 1 (gwlib/fdset.c:poller) maps to pid 4199. 2007-04-03 17:47:02 [4199] [2] DEBUG: Thread 2 (gwlib/http.c:write_request_thread) maps to pid 4199. 2007-04-03 17:47:02 [4199] [2] DEBUG: Parsing URL `http://localhost:13013/cgi-bin/sendsms?username=foopassword=barfrom=1234to=1234567890smsc=mysmstext=HOLA': 2007-04-03 17:47:02 [4199] [2] DEBUG: Scheme: http:// 2007-04-03 17:47:02 [4199] [2] DEBUG: Host:
Re: email2sms.pl script
You can use something like procmail and based on some rules make some kind of alerts . On Apr 3, 2007, at 3:23 PM, Alvaro Cornejo wrote: Hi Does anyone has this script ? and some instructions on how to use it? I've been googling arround and it is not available anymore on the web www.easitext.com in not longer available... as far as I could found ... well NOT found ;-) Regards Alvaro
Re: email2sms.pl script
Hi all Thanks for your advise; however I'm very rookie in programming, so I'll need some guidelines or a base script in order to have some start point. I was able to configure postfix to route all incomming mails to addresses like [EMAIL PROTECTED] to a unique mailbox so they can be parsed to kannel. Now I need to know how to parse those mails in order to extract mail data and feed it into kannel. Regards and thanks for your responses Alvaro On 4/3/07, Iain Dooley [EMAIL PROTECTED] wrote: Does anyone has this script ? and some instructions on how to use it? I've been googling arround and it is not available anymore on the web www.easitext.com in not longer available... as far as I could found ... well NOT found ;-) you could use any email processing script in perl, not just email2sms. just get any mail processing script and at the point where it gets the text from the email, format the appropriate http request to kannel cheers iain
smsbox blocks HTTP response - Re: Latest CVS problem
now, this behaviour is now *confirmed* for a vanila CVS checkout and fakesmsc
usage via gw/smskannel.conf sample config on the following hosts too:
amd64, 2.6.20-1.2307.fc5 x86_64
x86, 2.6.11-1.1369_FC4 i686
so this is considered as generic bug! (that's why I cross-post to devel@ too).
Please review Alejandro's post.
@Alejandro: can you please file this issue to our bug tracking syetem at
http://bugs.kannel.org/, so we keep a clean track of resolving it.
This needs to be cleaned and resolved before any new release can be done!
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
---
