email broken on wiki.kannel.org
Just tried to register with wiki.kannel.org but getting the error Looks like there was an error on sending the password mail. Please contact the admin! Can someone with the proper access please fix the mail problem. The wiki was mentioned on the list so it should be getting more visitors now. See ya... d.c.
Re: Kannel on Ubuntu server
**Reply-To: [EMAIL PROTECTED] **From: Peter Lum [EMAIL PROTECTED] **To: 'Davy Chan' [EMAIL PROTECTED] **Cc: 'Allison Almeida' [EMAIL PROTECTED], **'Kannel' users@kannel.org **Subject: RE: Kannel on Ubuntu server **Date: Thu, 14 Jun 2007 12:18:46 +0800 **Organization: Hotsource ESD **Message-ID: [EMAIL PROTECTED] ** **Hi Davy ** **I realised a strange problem... ** **The directory /var/run/kannel/ disappears everytime I reboot my Ubuntu **server!! **Dun know why?? Some Linux distributions are configured with /var/run as a RAM disk (tmpfs). As a result, any directory created inside of /var/run will not persist between reboots. You will need to modify your startup script to create the /var/run/kannel directory if it does not already exist. Peter, don't take this wrong but--I strongly recommend you get a book about how to admin a linux box. These questions are more basic admin questions rather than Kannel questions. See ya... d.c.
Re: Kannel on Ubuntu server
**Reply-To: [EMAIL PROTECTED] **From: Peter Lum [EMAIL PROTECTED] **To: 'Allison Almeida' [EMAIL PROTECTED], **'Davy Chan' [EMAIL PROTECTED] **Cc: 'Kannel' users@kannel.org **Subject: RE: Kannel on Ubuntu server **Date: Thu, 14 Jun 2007 10:18:14 +0800 **Organization: Hotsource ESD **Message-ID: [EMAIL PROTECTED] ** **Hi Allison ** **I created the folders /var/run/kannel and there is no errors. **When I start kannel, these are the output ** **Stopping WAP gateway: smsbox wapbox bearerbox. **Starting WAP gateway: bearerbox wapbox smsbox. ** **Does the info above tells me that the SMS gateway is also started too, **(smsbox)? ps uw `sudo cat /var/run/kannel/kannel_smsbox.pid` If the above command outputs a process description then that means the smsbox is running. **Also, there are no log files in /tmp? Are you sure your config files specify that the logfiles should be in /tmp? Look for log-file = ... in the config files. For access logs, look for access-log = ... in the config files. See ya... d.c.
Re: Kannel on Ubuntu server
**From: Peter Lum [EMAIL PROTECTED] **To: 'Allison Almeida' [EMAIL PROTECTED], **'Kannel' users@kannel.org **Subject: RE: Kannel on Ubuntu server **Date: Wed, 13 Jun 2007 11:48:49 +0800 **Organization: Hotsource ESD **Message-ID: [EMAIL PROTECTED] **In-Reply-To: [EMAIL PROTECTED] ** **Hi ** **Now I got a error message: **Starting WAP gateway: bearerbox/usr/sbin/run_kannel_box: open: **/var/run/kannel/kannel_bearerbox.pid: No such file or directory ** wapbox/usr/sbin/run_kannel_box: open: /var/run/kannel/kannel_wapbox.pid: No **such file or directory ** smsbox/usr/sbin/run_kannel_box: open: /var/run/kannel/kannel_smsbox.pid: No **such file or directory **. **I checked and there really are no such files on /var/run/. ** **Peter Well, create the /var/run/kannel directory: sudo mkdir -p /var/run/kannel sudo chmod 1777 /var/run/kannel See ya... d.c.
Re: multiple smscs
**Subject: multiple smscs **Date: Mon, 23 Apr 2007 11:32:25 -0300 **Message-ID: [EMAIL PROTECTED] **From: Gabriel Luhers Graca [EMAIL PROTECTED] **To: users@kannel.org ** **Hello, ** ** I'm trying to configure multiple SMSCs without success. ** ** The sms-services are identical for all 3 of my SMSCs, but I need to ** be able to choose which one sends back the reply using the number. ** The actually just have to go back to the same SMSC they came from. ** ** One operator handles all numbers that start with 91, another all ** that start with 96 and a third the remainder. ** ** I've tried the following: ** **group = smsc **smsc-id = xxx3344 **smsc = emi **allowed-smsc-id = xxx3344 **host = 10.xxx.yyy.zzz **port = ppp **my-number = 3344 **keepalive = 30 **idle-timeout = 60 **flow-control = 1 **window = 100 ** **group = sendsms-user **username = jdoe **password = secret **max-messages = 3 **concatenation = true **user-deny-ip = *.*.*.* **user-allow-ip = 127.0.0.1; 10.xxx.yyy.zzz **forced-smsc = xxx3344 **allowed-prefix = 96 ** ** ** I thought allowed-prefix would make all requests from numbers starting with 96 be channeled to this SMSC, but that didn't happen. ** ** How does one configure this? allowed-smsc-id establishes that a particular smsc entry is willing to accept SMS for a specific smsc smsc-id name. What you want to do is to limit the list of smsc-id that can use the smsc. You should also add a denied-smsci-id that lists all the smsc-id's that are forbidden to use that smsc. See ya... d.c.
Re: Forcing SMSC doesn't work
**Subject: RE: Forcing SMSC doesn't work **Date: Wed, 4 Apr 2007 10:09:57 +1200 **Message-ID: [EMAIL PROTECTED] **From: David Ritchie [EMAIL PROTECTED] **To: users@kannel.org ** **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. ** I know I'm scratching a scab... You've just encountered one of the many complexities of Kannel. The problem you encountered was alluded to in the userguide in Table 6-1. SMSC Group Variables: Variable Value Description smsc-id (m) string An optional name or id for the smsc. Any string is acceptable, but semicolon ';' may cause problems, so avoid it and any other special non-alphabet characters. This 'id' is written into log files and can be used to route SMS messages, and to specify the used SMS-service. Several SMSCs can have the same id. The name is case-insensitive. __NOTE THAT IF SMS CENTER CONNECTION HAS AN ASSIGNED SMSC ID, IT DOES NOT AUTOMATICALLY MEAN THAT MESSAGES WITH IDENTICAL SMSC ID ARE ROUTED TO IT; INSTEAD CONFIGURATION VARIABLES denied-smsc-id, allowed-smsc-id AND preferred-smsc-id IS USED FOR THAT__. If you want to use Delivery Reports, you must define this. Here's something else that might be of interest to you from my uncomplete additions to the userguide (I really wish I had some time to finish my additions..): http://202.181.245.115/kannel-doc/1.3.1/userguide.html#EVAL-DRIVER-BBOX I.2 Mobile Originated SMS to the Bearerbox When an MO SMS is forwarded from the Mobile Network Operator, it must pass through the SMSC driver (e.g. SMPP, CIMD, etc.). The MO SMS is converted from the SMSC's proprietary format to Kannel's abstract form (the SMS Msg format). Once the SMS is in the SMS Msg format, it is forwarded to the bearerbox's SMS received function (bb_smscconn_receive()) for routing to the SMSbox or out another SMSC connection. Before the bearerbox forwards the MO SMS to its destination, several processing procedures occur to the SMS: * The origination address (OA) of the SMS is processed by the SMSC-specific unified-prefix. * The OA is processed by the global unified-prefix declared within the group = core section. * The OA is processed through the whitelist declared within the group = core section. * The OA is processed through the whitelist-regex declared within the group = core section. * The OA is processed through the blacklist declared within the group = core section. * The OA is processed through the blacklist-regex declared within the group = core section. * If the SMS passes all the above, then it will be forwarded to it destination for further processing. See ya... d.c.
Re: Queued DLRs [Really Kannel Doc difficulties]
**Message-ID: [EMAIL PROTECTED] **Date: Mon, 2 Apr 2007 02:34:54 +0300 **From: Enver ALTIN [EMAIL PROTECTED] **To: XSG Telecom M.I. de Jong [EMAIL PROTECTED] **Subject: Re: Queued DLRs **In-Reply-To: [EMAIL PROTECTED] **MIME-Version: 1.0 **References: AcdhezITmXnMn8SVR4GNrY3iDIOfBg== ** [EMAIL PROTECTED] **Cc: users@kannel.org ** ** **Try flushing the DLR queue. As always, details in User's Guide. ** **http://www.kannel.org/download/1.4.1/userguide-1.4.1/userguide.html#AEN834 ** **Totally off-topic though, after reading many books on Agile Software **Development processes, including those from Ken Schwaber and Alistair **Cockburn, I think I understand why conventional development processes **tend to regard documentation as a required donkeywork. Now, agile **processes value working software over complete documentation but in **the case of Kannel we have both working software and excellent **documentation yet people actually don't read it. Now it feels like **there's something wrong here. Is this because documentation is so big **and full of so much information, or is it so badly organized that **people are having hard times reading it, or the product is so good **people think they can figure out themselves without the need of **reading the documentation, or people are being just lazy? Anyone? Hmm. I think the problem is: - complexity of Kannel's capabilities - lack of background in the WAP/SMS/MMS implementation of new Kannel users - overwhelming amount of technical information inside the Kannel documentation - not enough detailed/annotated examples - incomplete glossary/bibliography - lack of index I tried to re-write the manual when I was writing a UUID module for Kannel v1.3.1 (which my employer will not allow me to open-source), but ran out of time resources. The major problem is that the document is in DSSL (Docbook) format and there are limited editors (circa 2003) that natively support it in a WYSIWYG mode. Additionally, it did not use a version of DSSSL that can be XML validated. As a result, it's a pain to re-write. I ended up using VI, converting the whole document to dockbookx (to support XML validation of the document), added section numbering to keep myself from getting lost, hand edititing the resulting document, and passing it through openJade to render an HTML version for ever change. VERY time consuming. I've been trying to find time to continue this but real-life intrudes in my open-source ventures. For anyone interested, here's what my old version looked like: http://202.181.245.115/kannel-doc/1.3.1/userguide.html See ya... d.c.
Re: Mail2SMS with Kannel
Your right. This might not be a problem with path to email2sms.pl. But
it's definitely a problem with email2sms.pl. I got caught up with
the command not found and didn't see it was actually refering to
the use statement.
It sounds more like procmail is using /bin/sh to execute the
email2sms.pl instead of perl.
Try changing it to:
perl /full/path/to/email2sms.pl
instead of just:
./email2sms.pl
And make sure the version of perl you specify is really version 5.
Your system might have 2 version of perl (v4 and v5) and procmail
might be using the wrong version of perl to execute the email2sms.pl.
See ya...
d.c.
**Subject: RE: Mail2SMS with Kannel
**Date: Sun, 3 Dec 2006 11:55:08 +0400
**In-Reply-To: [EMAIL PROTECTED]
**From: Divyesh Amipara [EMAIL PROTECTED]
**To: Davy Chan [EMAIL PROTECTED]
**Cc: David E. Meier [EMAIL PROTECTED], users@kannel.org
**
**Hi,
**
**I know it is not a Kannel problem but there are some users who use the
**similar setup (Mail2SMS).
**
**Let me tell you. It is not the problem with PATH.
**
**Thanks for suggestion to buy a book on UNIX.
**
** Divyesh A.
**
**-Original Message-
**From: Davy Chan [mailto:[EMAIL PROTECTED]
**Sent: Sunday, December 03, 2006 11:41 AM
**To: Divyesh Amipara
**Cc: David E. Meier; users@kannel.org
**Subject: Re: Mail2SMS with Kannel
**
Subject: RE: Mail2SMS with Kannel
Date: Sun, 3 Dec 2006 09:09:12 +0400
In-Reply-To: [EMAIL PROTECTED]
Priority: Urgent
Importance: high
From: Divyesh Amipara [EMAIL PROTECTED]
To: David E. Meier [EMAIL PROTECTED], users@kannel.org
Hi,
I am facing problem with procmail, it seems procmail is not working
**properly. Below is my config and logs...
I just want mailto be handled by email2sms.pl. strange thing is when
**I run...
./email2sms.pl /home/admin/Maildir/new/mail (it works fine but
**not with procmail)
1) .procmailrc
:0
| ./email2sms.pl
2) /etc/postfix/main.cf
home_mailbox = Maildir/
mailbox_command = /usr/bin/procmail
virtual_alias_maps = hash:/etc/postfix/virtual
3) /etc/postfix/virtual
@test.com [EMAIL PROTECTED]
4) /var/log/maillog
Dec 2 22:01:10 tecexperts postfix/local[6410]: 1A4981F3EB1:
**to=[EMAIL PROTECTED], orig_to=[EMAIL PROTECTED], relay=local,
**delay=3832, status=SOFTBOUNCE (can't create user output file. Command
**output: procmail: Couldn't create /var/mail/admin ./email2sms.pl: line
**3: use: command not found ./email2sms.pl: line 4: use: command not found
**./email2sms.pl: line 5: use: command not found ./email2sms.pl: line 7:
**use: command not found ./email2sms.pl: line 8: use: command not found
**./email2sms.pl: line 9: syntax error near unexpected token `('
**./email2sms.pl: line 9: `use POSIX qw(strftime);' procmail: Program
**failure (2) of ./email2sms.pl )
Re: Mail2SMS with Kannel
**Subject: RE: Mail2SMS with Kannel
**Date: Sun, 3 Dec 2006 09:09:12 +0400
**In-Reply-To: [EMAIL PROTECTED]
**Priority: Urgent
**Importance: high
**From: Divyesh Amipara [EMAIL PROTECTED]
**To: David E. Meier [EMAIL PROTECTED], users@kannel.org
**
**Hi,
**
**I am facing problem with procmail, it seems procmail is not working
properly. Below is my config and logs...
**
**I just want mailto be handled by email2sms.pl. strange thing is when I run...
**
**./email2sms.pl /home/admin/Maildir/new/mail (it works fine but not
with procmail)
**
**1) .procmailrc
**
**:0
**| ./email2sms.pl
**
**2) /etc/postfix/main.cf
**
**home_mailbox = Maildir/
**mailbox_command = /usr/bin/procmail
**virtual_alias_maps = hash:/etc/postfix/virtual
**
**3) /etc/postfix/virtual
**
**@test.com[EMAIL PROTECTED]
**
**4) /var/log/maillog
**
**Dec 2 22:01:10 tecexperts postfix/local[6410]: 1A4981F3EB1: to=[EMAIL
PROTECTED], orig_to=[EMAIL PROTECTED], relay=local, delay=3832,
status=SOFTBOUNCE (can't create user output file. Command output: procmail:
Couldn't create /var/mail/admin ./email2sms.pl: line 3: use: command not
found ./email2sms.pl: line 4: use: command not found ./email2sms.pl: line 5:
use: command not found ./email2sms.pl: line 7: use: command not found
./email2sms.pl: line 8: use: command not found ./email2sms.pl: line 9: syntax
error near unexpected token `(' ./email2sms.pl: line 9: `use POSIX
qw(strftime);' procmail: Program failure (2) of ./email2sms.pl )
**
This is not a Kannel problembut...
The problem is that procmail is being called from a location that is
not in the same directory as your email2sms.pl program.
You should specify the full path to email2sms.pl in your .procmailrc.
Therefore, if email2sms.pl is located in /home/divyesh, your .procmailrc
should have:
:0
| /home/divyesh/email2sms.pl
I would also suggest obtaining a book on Unix. It would help you with
this problems on how to work in a Unix environment.
See ya...
d.c.
Re: Char encoding problem
**From: Flavio Suguimoto Leite [EMAIL PROTECTED] **To: users@kannel.org **Subject: Char encoding problem **Date: Tue, 7 Feb 2006 10:39:15 -0200 **In-Reply-To: [EMAIL PROTECTED] ** **Hi, ** **I have some issues with some messages in my kannel gateway. I have a **kannel plugged to 9 SMSCs and all of it is working fine. Almost messages **receive from those SMSC are fine encoded in ASCII but a few of it is **reaching my platform in a strange char enconding format : ** **Example: **HOLA?SRES?DE?R?H?+?ME?LLA?MO?CINTHIA?AI?SA?SOY?DE?GONZALEZ?CATAN?MI?DNI? **ES?22366617?YO?TAM?BIEN?MANDO?AMIS?NENES?A???UN?COLEGIO?Q?X?LA?TARDE?ESS **UBENCIONA ** **Other example: **00480049005400200068006F006C00610020007100750069007300690065007200610020 **00640065006A006100720020006D00690073002000760074007300200020007000610072 **00610020005400480041004C0049004100200063006F006E00200041006C006D00610020 **00430065006E00740065006E0063006900610064006100200079 ** **First question, why this messages is reaching to me in this strange **encoding? ** **How can I config the kannel to translate it to ASCII messages? Is it **possible? You are receiving UCS-2 double-byte characters. You can get Kannel's smsbox to convert it to UTF-8 by setting mo-recode=true in your group=smsbox declaration section. See ya... d.c.
Re: RES: Char encoding problem
The userguide is your friend: If enabled, Kannel will try to convert received messages with UCS2 charset to ISO-8859-1 or to UTF-8, simplifying external servers jobs. If Kannel is able to recode messages, it will also change coding to 7 bits and charset to iso-88590-1 or to utf-8. In other words, mo-recode=true will only try to convert UCS2 (the double byte messages). See ya... d.c. **From: Flavio Suguimoto Leite [EMAIL PROTECTED] **To: 'Davy Chan' [EMAIL PROTECTED] **Cc: users@kannel.org **Subject: RES: Char encoding problem **Date: Tue, 7 Feb 2006 14:55:14 -0200 **In-Reply-To: [EMAIL PROTECTED] ** **Davy, ** **Thank you very much. ** **These two messages are the same problem? In the same link a receive **normal messages (ASCII) and sometimes I receive these kind of message. **If I use mo-recode=true all MO messages wil be translated or only **these one? ** ** **-Mensagem original- **De: Davy Chan [mailto:[EMAIL PROTECTED] **Enviada em: ter?a-feira, 7 de fevereiro de 2006 14:21 **Para: Flavio Suguimoto Leite **Cc: users@kannel.org **Assunto: Re: Char encoding problem ** From: Flavio Suguimoto Leite **[EMAIL PROTECTED] To: users@kannel.org Subject: Char encoding problem Date: Tue, 7 Feb 2006 10:39:15 -0200 In-Reply-To: [EMAIL PROTECTED] Hi, I have some issues with some messages in my kannel gateway. I have a kannel plugged to 9 SMSCs and all of it is working fine. Almost **messages receive from those SMSC are fine encoded in ASCII but a few of it is reaching my platform in a strange char enconding format : Example: HOLA?SRES?DE?R?H?+?ME?LLA?MO?CINTHIA?AI?SA?SOY?DE?GONZALEZ?CATAN?MI?D **NI? ES?22366617?YO?TAM?BIEN?MANDO?AMIS?NENES?A???UN?COLEGIO?Q?X?LA?TARDE? **ESS UBENCIONA Other example: 00480049005400200068006F006C00610020007100750069007300690065007200610 **020 00640065006A006100720020006D00690073002000760074007300200020007000610 **072 00610020005400480041004C0049004100200063006F006E00200041006C006D00610 **020 00430065006E00740065006E0063006900610064006100200079 First question, why this messages is reaching to me in this strange encoding? How can I config the kannel to translate it to ASCII messages? Is it possible? ** **You are receiving UCS-2 double-byte characters. You can get Kannel's **smsbox to convert it to UTF-8 by setting mo-recode=true in your **group=smsbox declaration section. ** **See ya... ** **d.c. ** ** **-- **No virus found in this incoming message. **Checked by AVG Free Edition. **Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 6/2/2006 ** ** **-- **No virus found in this outgoing message. **Checked by AVG Free Edition. **Version: 7.1.375 / Virus Database: 267.15.2/252 - Release Date: 6/2/2006 ** ** **
Re: Strange SMS
Try adding mo-recode = yes in your smsbox group. See ya... d.c. **Date: Fri, 18 Nov 2005 21:43:36 +0100 **From: Alejandro Guerrieri [EMAIL PROTECTED] **To: users@kannel.org users@kannel.org **Subject: Re: Strange SMS **In-Reply-To: [EMAIL PROTECTED] ** **I might be wrong, but looks like a misconfiguration on the SMSC **side... I've never dealt with unicode messages on kannel before, maybe **someone else on this list did and can bring some light into this **issue? ** **Regards, ** **On 11/18/05, Flavio Suguimoto Leite **[EMAIL PROTECTED] wrote: ** Some messages come in this format or %00%0A. format. ** But this one comes like I sent to you and my application thinks that is ** a string 0071123001010230 ** ** Anyway I will try to read some Kannel flags... ** ** Thanks anyway... ** ** ** -Mensagem original- ** De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome ** de Alejandro Guerrieri ** Enviada em: sexta-feira, 18 de novembro de 2005 16:12 ** Para: users@kannel.org ** Assunto: Re: Strange SMS ** ** Not sure about Kannel, but anyway you could fix it at application ** level removing every \0 from the string you get. ** ** .I.t. u.s.u.a.l.l.y. l.o.o.k.s. l.i.k.e. t.h.i.s (the unicode string, ** I mean, you'd be able to fix it easily. ** ** Hope it helps, ** ** Alejandro. ** ** On 11/18/05, Flavio Suguimoto Leite ** [EMAIL PROTECTED] wrote: ** Alejandro and all, ** ** I guess that your get it! But how could I know if it is a plain text ** or ** a Unicode number? Could kannel handle it and send me always plain ** text? ** ** Fl?vio Suguimoto ** Pragya Technologies - Brazil ** Development Team Manager ** +55-16-3904-9656 ** -Mensagem original- ** De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome ** de Alejandro Guerrieri ** Enviada em: quinta-feira, 17 de novembro de 2005 21:42 ** Para: users@kannel.org ** Assunto: Re: Strange SMS ** ** That's a Unicode encoded MO message, probably from an argentinean ** girl, ** saying: ** ** pepsi,soy Yani Rivero de Gral Rodriguez)quiero el tema de Gloria Es ** (...tefan i guess) ** ** Isn't it funny how many things could be inferred from a bunch of ** numbers ** ;) ** ** Unicode uses 2 bytes for each character, so max lenght's usually about ** 70 chars instead of the 140-160 you'd expect on most networks. ** ** Sometimes, you can even found some clever guys that send picture ** messages and EMS's to short numbers... ** ** Hope it helps, ** ** On 11/17/05, Flavio Suguimoto Leite ** [EMAIL PROTECTED] wrote: ** ** ** Fl?vio Suguimoto ** Pragya Technologies - Brazil ** Development Team Manager ** +55-16-3904-9656 ** I have a Kannel running perfectly with a lot of SMSC configured and ** working. Sometime I get some MO messages logged in the kannel log ** like ** this: ** ** ** ** 2005-11-17 15:14:56 Receive SMS [SMSC:XX] [SVC:] [ACT:] [BINF:] ** [from:XX] [to:X] [flags:-1:2:-1:0:-1] ** ** ** [msg:134:00700065007000730069002C0073006F0079002000590061006E00690020005 ** ** ** 20069007600650072006F0020006400650020004700720061006C00200052006F0064007 ** ** ** 20069006700750065007A002900710075006900650072006F00200065006C00200074006 ** 5006D006100200064006500200047006C006F007200690061002000450073] ** ** ** ** Someone have a clue what is happen? ** ** ** ** Regards, ** ** Fl?vio Suguimoto ** ** Pragya Technologies - Brazil ** ** Development Team Manager ** ** +55-16-3904-9656 ** ** -- ** No virus found in this outgoing message. ** Checked by AVG Free Edition. ** Version: 7.1.362 / Virus Database: 267.13.3/173 - Release Date: ** 16/11/2005 ** ** ** ** ** ** ** -- ** Alejandro Guerrieri ** Magicom ** http://www.magicom-bcn.net/
Re: [kannel] Connection with smsc UP but no MO/MT traffic
**Date: Fri, 28 Oct 2005 13:14:28 +0100 **From: Zouari Fourat [EMAIL PROTECTED] **To: Davy Chan [EMAIL PROTECTED] **Subject: Re: [kannel] Connection with smsc UP but no MO/MT traffic **In-Reply-To: [EMAIL PROTECTED] **Cc: users@kannel.org ** **Hello, **keeping in mind that i have transceiver-mode set, This is a SMPP 3.4 **only feature and will not work on an earlier SM-SC (from the kannel's **user guide). You misinterpreted the userguide. You can use transceiver-mode to a SMSC that supports v3.4. You can then inform the SMSC that you only understand v3.3 commands like DELIVER_SM, SUBMIT_SM and v3.3 PDU (i.e. no optional TLV). I do the exact thing with a Comverse SMSC. **I cant put interface-version to an earlier version than 34, doing it, **i dont receive anything. **trying to disable the transceiver-mode feature and using a **receive-port instead, but i dont know which port number should i give **and how it work ? **can you help me please ? or give a conf sample that can work ? If your SMSC also supports v3.3 (which it should), you can disable trasceiver-mode and set the kannel receiver-port to be the SMSC's TCP port it is willing to use to receive SMS from you. As someone else pointed out, it most likely is the same as the BIND_TRANSMITTER. You should really talk with your SMSC provider and get all the necessary information from them. In addition to obvious parameters (IP address, port, system-name, password), they will mostly also provide you with the other non-obvious parameters: - Source TON, NPI - Destination TON, NPI - Address range - Throughput (his side and yours) - Hearbeat method (ENQUIRE_LINK/empty SUBMIT_SM/etc) - Min/Max heartbeat rate - Pending SMS expiration Additionally, read the SMPP 3.4 specs and be very familiar with the error codes. As a matter of fact, test your configuration out using the freely available SMPP SMSC simulators to ensure you understand how Kannel interacts with the SMSC. This will provide you with the baseline you need to determine if your production system is out of alignment. See ya... d.c.
Re: [kannel] Connection with smsc UP but no MO/MT traffic
Try setting your SMPP interface version to 3.3 instead of 3.4 in Kannel via: interface-version = 33 Kannel does not support many of the v3.4 PDU like DATA_SM and optional TLV. See ya... d.c. **Date: Fri, 28 Oct 2005 11:01:28 +0100 **From: Zouari Fourat [EMAIL PROTECTED] **To: Davy Chan [EMAIL PROTECTED] **Subject: Re: [kannel] Connection with smsc UP but no MO/MT traffic **In-Reply-To: [EMAIL PROTECTED] ** **thank you for your support, **I have modified my conf file to do transceiver mode (added the line **transceiver-mode = true in the smsc group). **i began receiving MO type messages but viewing the logs there were **allaways a problem when receiving the first message, the bearerbox as **it seems does not accept that message, go offline from the smsc and **reconnect to get it and throw an error and it still repeating... **here's the log : **2005-10-28 10:28:30 ** **2005-10-28 10:28:30 [7] DEBUG: sms_router: time to sleep **2005-10-28 10:28:30 [7] DEBUG: sms_router: list_len = 0 **2005-10-28 10:28:30 [12] DEBUG: udp_die: removing producers from udp-lists **2005-10-28 10:28:30 [12] DEBUG: Thread 12 (gw/bearerbox.c:wdp_router) terminates. **2005-10-28 10:28:30 [6] DEBUG: SMPP[SMPP-01-TT]: Sending PDU: **2005-10-28 10:28:30 [6] DEBUG: SMPP PDU 0x80d4188 dump: **2005-10-28 10:28:30 [6] DEBUG: type_name: bind_transceiver **2005-10-28 10:28:30 [6] DEBUG: command_id: 9 = 0x0009 **2005-10-28 10:28:30 [6] DEBUG: command_status: 0 = 0x **2005-10-28 10:28:30 [6] DEBUG: sequence_number: 0 = 0x **2005-10-28 10:28:30 [6] DEBUG: system_id: tuntest **2005-10-28 10:28:30 [6] DEBUG: password: **2005-10-28 10:28:30 [6] DEBUG: system_type: VMA **2005-10-28 10:28:30 [6] DEBUG: interface_version: 52 = 0x0034 **2005-10-28 10:28:30 [6] DEBUG: addr_ton: 0 = 0x **2005-10-28 10:28:30 [6] DEBUG: addr_npi: 0 = 0x **2005-10-28 10:28:30 [6] DEBUG: address_range: **2005-10-28 10:28:30 [6] DEBUG: SMPP PDU dump ends. **2005-10-28 10:28:30 [6] DEBUG: SMPP[SMPP-01-TT]: Got PDU: **2005-10-28 10:28:30 [6] DEBUG: SMPP PDU 0x80d42b0 dump: **2005-10-28 10:28:30 [6] DEBUG: type_name: bind_transceiver_resp **2005-10-28 10:28:30 [6] DEBUG: command_id: 2147483657 = 0x8009 **2005-10-28 10:28:30 [6] DEBUG: command_status: 0 = 0x **2005-10-28 10:28:30 [6] DEBUG: sequence_number: 0 = 0x **2005-10-28 10:28:30 [6] DEBUG: SMPP PDU dump ends. **2005-10-28 10:28:31 [5] DEBUG: Started thread 13 (gw/bb_boxc.c:function) **2005-10-28 10:28:31 [13] INFO: Client connected from 127.0.0.1 **2005-10-28 10:28:31 [13] DEBUG: Started thread 14 (gw/bb_boxc.c:boxc_sender) **2005-10-28 10:29:03 [6] ERROR: Unknown SMPP_PDU type, internal error. **2005-10-28 10:29:03 [6] ERROR: SMPP[SMPP-01-TT]: PDU unpacking failed. **2005-10-28 10:29:03 [6] DEBUG: SMPP[SMPP-01-TT]: Failed PDU follows. **2005-10-28 10:29:03 [6] DEBUG: Octet string at 0x80d3a88: **2005-10-28 10:29:03 [6] DEBUG: len: 70 **2005-10-28 10:29:03 [6] DEBUG: size: 71 **2005-10-28 10:29:03 [6] DEBUG: immutable: 0 **2005-10-28 10:29:03 [6] DEBUG: data: 00 00 01 03 00 00 00 00 **2005-10-28 10:29:03 [6] DEBUG: data: 00 00 00 01 00 01 01 32 ...2 **2005-10-28 10:29:03 [6] DEBUG: data: 31 36 39 37 35 39 33 32 16975932 **2005-10-28 10:29:03 [6] DEBUG: data: 39 37 00 00 01 38 37 37 97...437 **2005-10-28 10:29:03 [6] DEBUG: data: 37 37 00 00 00 00 04 24 77.$ **2005-10-28 10:29:03 [6] DEBUG: data: 00 1c 47 6f 6c 32 68 6d ..Gol2hm **2005-10-28 10:29:03 [6] DEBUG: data: 69 64 69 61 6e 6f 75 61 idianoua **2005-10-28 10:29:03 [6] DEBUG: data: 72 65 73 73 61 64 65 66 ressadef **2005-10-28 10:29:03 [6] DEBUG: data: 73 6f 75 73 73 65 sousse **2005-10-28 10:29:03 [6] DEBUG: Octet string dump ends.
Re: [kannel] Connection with smsc UP but no MO/MT traffic
**Date: Thu, 27 Oct 2005 23:00:25 +0100 **From: Zouari Fourat [EMAIL PROTECTED] **To: users@kannel.org **Subject: [kannel] Connection with smsc UP but no MO/MT traffic ** **Hello all, **I have a problem setting up kannel to work with smpp smsc, the problem **is discussed here : http://smsforum.net/smf/index.php?topic=2160.0 **(log files and conf file are listed clearly on that link so please **give it a look and try to help me please) group = smsc smsc = smpp smsc-id = SMPP-01-TT host = 192.168.160.18 port = 2775 receive-port = 0 smsc-username = tuntest smsc-password = system-type = VMA address-range = You only specified the BIND_TRANSMITTER destination port of the SMSC via 'port = 2775'. With this configuration, you can only send SMS to the SMSC. If you want to receive SMS from the SMSC you have two options: 1) Tell Kannel the BIND_RECEIVER destination port of the SMSC via the 'receive-port = port_number' in the Kannel config. 2) Tell Kannel it should use BIND_TRANSCEIVER mode when communicating with the SMSC. This can be accomplished with 'transceiver-mode = true' in the Kannel config. See ya... d.c.
Re: SMSBOX
Chinese characters must be sent as UCS-2 double-byte words. Depending on which version of Kannel you are using the charset of UTF-16BE. Depending on which version of Kannel, if you are using v1.3.1 or less, the coding=3. If you are using v1.3.2 or higher, you should set coding=2. See ya... d.c. **From: StephenLim [EMAIL PROTECTED] **To: 'Davy Chan' [EMAIL PROTECTED] **Cc: users@kannel.org **Subject: RE: SMSBOX **Date: Sat, 5 Mar 2005 12:57:29 +0800 ** **May I know what encoding you are using? ** ** **-Original Message- **From: Davy Chan [mailto:[EMAIL PROTECTED] **Sent: Saturday, March 05, 2005 12:51 PM **To: StephenLim **Cc: users@kannel.org **Subject: Re: SMSBOX ** From: StephenLim [EMAIL PROTECTED] To: users@kannel.org Subject: SMSBOX Date: Sat, 5 Mar 2005 10:27:09 +0800 I am using kannel patch engine (smsbox and bearerbox) to send chinese sms. When I send Chinese sms with a [white space] in between, it will fail to send out. How can accommodate this problem? Is there any solution? Thanks in advance! ** **It would really help if you posted your log files, configuration **files, and procedure on how you sent the SMS. ** **I've had no problems with sending and receiving chinese SMS. ** **See ya... ** **d.c. **
Re: Please help : Pbs with quote and backslash
We are not ignoring your posting. We are having a hard time trying
to read your mind since you are providing us with very little information
to try and deduce your current setup.
From the looks of the log, I would say you are not using Kannel
directly but playsms. Playsms uses Kannel as an SMS gateway.
Playsms (from my brief glance of it) is a set of PHP scripts that
handle the communication between you and the SMS gateway.
The sendsms sender ... line comes from the smsbox. The
Parsing URL ... line occurs either from a get-url/post-url inside
a sms-service or a send-url inside the HTTP SMSC declaration.
Since it is coming after the sendsms, I would deduce that your
have setup an HTTP SMSC configuration. When you submit an
sendsms to Kannel, the HTTP SMSC handles the MT SMS and
sends it to the Playsms proxy for handling.
Now, guessing at this possible configuration (since you did not
provide it for us), I would assume that the Playsms proxy PHP
script is the program that is escaping the single (') and double ()
quotes a backslash (\). I believe that the Playsms PHP scripts
are the culprit and not Kannel.
I can tell you that the Kannel source code obtained from www.kannel.org
for the bearerbox and smsbox do not add backslashes to the code.
The bearerbox will convert latin1 to GSM7
(gateway/gwlib/charset.c:charset_latin1_to_gsm()). But, the single
and double quotes are the same in both character sets.
If my assumptions are wrong then please post your configurations
so we can better help you with your problem.
See ya...
d.c.
**Date: Fri, 4 Mar 2005 17:28:21 +0100
**From: [EMAIL PROTECTED]
**To: Guillaume Cottenceau [EMAIL PROTECTED]
**Subject: Re: Please help : Pbs with quote and backslash
**In-Reply-To: [EMAIL PROTECTED]
**
**I'm using this version :
**2005-03-04 11:51:25 [8231] [0] INFO: Kannel bearerbox II version 1.4.0
starting
**
**And yes, I don't understand where is the bug, here is my log :
**
**smsbox.log
**2005-03-04 14:06:24 [8254] [3] INFO: sendsms sender:titext:Cyrille
**(213.41.137.61) to:0033617730247 msg:salut et ' et \
**2005-03-04 14:06:29 [8264] [9] DEBUG: Parsing URL
**`http://127.0.0.1/~playsms/proxy.php?dlr-type=8myid=2384username=password=dlr-mask=31from=Cyrilleto=00336xtext=salut+%22+et+%27+et+%5C':
**2005-03-04 14:06:29 [8264] [9] DEBUG: Query:
**dlr-type=8myid=2384username=password=dlr-mask=31from=Cyrilleto=0033xxtext=salut+%22+et+%27+et+%5C
**2005-03-04 14:07:39 [8264] [9] DEBUG: Parsing URL
**`http://127.0.0.1/~playsms/proxy.php?dlr-type=1myid=2384username=password=dlr-mask=31from=Cyrilleto=0033xtext=salut+%22+et+%27+et+%5C':
**
**2005-03-04 14:06:24 [8254] [3] INFO: sendsms sender::Cyrille
**(xxx.xxx.137.61) to:00336xxx msg:salut et ' et \
**
**And kannel-Access.log :
**2005-03-04 14:06:29 Sent SMS [SMSC:Nokia] [SVC:toto] [ACT:] [BINF:]
**[from:0033xx] [to:+336x] [flags:-1:0:-1:-1:31] [msg:22:salut et /'
**et //] [udh:0:]
**
**What it surprised me (see the additionnal char), that appears in log only in
the
**access log, not before. Do you have idea ?
**
**Thanks
**
**
**
**Quoting Guillaume Cottenceau [EMAIL PROTECTED]:
**
** info.ubichip 'at' free.fr writes:
**
** Here is an example of the text I send :
**
** salut et ' et \
**
** so urlencode(text)=salut+%22+et+%27+et+%5C
**
** and what I receive :
**
** salut et \' et \\
**
** Strange, I receive it correctly (except \ which is removed by my
** application). Are you using an old version? I'm using CVS of a
** little while ago.
**
** smsbox.log:2005-03-04 15:34:17 [32042] [3] INFO: sendsms sender:xxx
** (127.0.0.1) to:+41yyy msg:salut et ' et bye
** smsbox-access.log:2005-03-04 15:34:17 send-SMS request added - sender:xxx
** 127.0.0.1 target:+41yyy request: 'salut et ' et bye'
** kannel-access.log:2005-03-04 15:34:18 Sent SMS [SMSC:xxx] [SVC:xxx] [ACT:]
** [BINF:] [from:xxx] [to:+41yyy] [flags:-1:0:-1:-1:2] [msg:21:salut et ' et
** bye] [udh:0:]
**
Re: Please help : Pbs with quote and backslash
Please provide your configuration files. Are you sure you don't have any HTTP SMSC defined in your configuration files? I'm really curious why it took 2 seconds for the smsbox to submit the SMS to the bearbox's receiver queue. The alt-dcs is not for changing the character set. It's used to indicate how to set/unset bits 7 through 3 of Data Coding Scheme (used to distinguish between MWI or just data coding/mclass). According to your logs, the SMS Msg structure that is extracted out of the bearerbox receive queue already has the single quote with an backslash prepended. It's getting late for me...please post your config files. See ya... d.c. **Date: Sat, 5 Mar 2005 18:07:33 +0100 **From: [EMAIL PROTECTED] **To: Davy Chan [EMAIL PROTECTED] **Cc: Guillaume Cottenceau [EMAIL PROTECTED], users@kannel.org **Subject: Re: Please help : Pbs with quote and backslash **In-Reply-To: [EMAIL PROTECTED] **User-Agent: Internet Messaging Program (IMP) 3.2.5 ** **Thanks for your answer, I will give you more informations : ** **First, I 'm using Playsms but I have make some additionnals tests that not put **Playsms in the problem resolution. ** **I made additionnal test with the following URL (only Kannel cgi-sendsms so no **Playsms at all) : **http://127.0.0.1:13013/cgi-bin/sendsms?username=password=to=06xxtext=salut+%22+et+%27+et+%5C ** **The return code is sent and the sms arrives on the phone but still with the **same issue (\ in front of ' and \). ** **For my point of view, there is something between bearbox and smsbox that add **additionnal backslash but I still do not know where. The logs below shows that **the backslash is not in smsbox but is in bearbox. ** **I do not use alt-dcs variable neither coding in http request, so it must be **default value. ** **I modified the Kannel source in order to add additionnal DEBUG trace, here is **what I retrieve : ** **From the smsbox.log : **2005-03-05 15:57:46 [27066] [2] DEBUG: HTTP: Creating HTTPClient for **`127.0.0.1'. **2005-03-05 15:57:46 [27067] [3] INFO: smsbox: Got HTTP request **/cgi-bin/sendsms from 127.0.0.1 **2005-03-05 15:57:46 [27067] [3] INFO: sendsms used by **2005-03-05 15:57:46 [27067] [3] INFO: sendsms sender::13013 (127.0.0.1) **to:06xx msg:salut et ' et \ **2005-03-05 15:57:46 [27067] [3] INFO: sendsms sender:t:13013 (127.0.0.1) **to:0xxx msg:salut et ' et \ **2005-03-05 15:57:46 [27067] [3] INFO: sendsms sender:after charset-processing **msg:salut et ' et \ **2005-03-05 15:57:46 [27067] [3] DEBUG: AT2[]: sms_split **2005-03-05 15:57:46 [27067] [3] DEBUG: AT2[salut et ' et \]: latin12gsm **2005-03-05 15:57:46 [27067] [3] DEBUG: AT2[salut et ' et /]: apres latin12gsm **2005-03-05 15:57:46 [27067] [3] DEBUG: AT2[salut et ' et \]: sms_split **2005-03-05 15:57:46 [27067] [3] DEBUG: AT2[(null)]: split char CYRIL **2005-03-05 15:57:46 [27067] [3] DEBUG: AT2[salut et ' et \]: latin12gsm **2005-03-05 15:57:46 [27067] [3] DEBUG: AT2[salut et ' et /]: apres latin12gsm **CYRIL **2005-03-05 15:57:46 [27067] [3] DEBUG: AT2[salut et ' et \]: sms_split apres **footer et header CYRIL **2005-03-05 15:57:46 [27067] [3] DEBUG: message length 17, sending 1 messages **2005-03-05 15:57:46 [27067] [3] DEBUG: smsbox : msg [salut et ' et \] **2005-03-05 15:57:46 [27067] [3] DEBUG: smsbox : new_msg [salut et ' et \] **2005-03-05 15:57:46 [27067] [3] DEBUG: Status: 202 Answer: Sent. **2005-03-05 15:57:46 [27067] [3] DEBUG: HTTP: Resetting HTTPClient for **`127.0.0.1'. ** ** ** ** ** **From the Kannel.log (some function name appears in the log, latin12gsm in **charset.c for example): ** ** **2005-03-05 15:57:48 [27073] [12] DEBUG: boxc_receiver: sms received **2005-03-05 15:57:48 [27073] [12] DEBUG: AT2[]: sms_split **2005-03-05 15:57:48 [27073] [12] DEBUG: AT2[salut et \' et \\]: latin12gsm **2005-03-05 15:57:48 [27073] [12] DEBUG: AT2[salut et /' et //]: apres **latin12gsm **2005-03-05 15:57:48 [27073] [12] DEBUG: AT2[salut et \' et \\]: sms_split **2005-03-05 15:57:48 [27073] [12] DEBUG: AT2[(null)]: split char **2005-03-05 15:57:48 [27073] [12] DEBUG: AT2[salut et \' et \\]: latin12gsm **2005-03-05 15:57:48 [27073] [12] DEBUG: AT2[salut et /' et //]: apres **latin12gsm CYRIL **2005-03-05 15:57:48 [27073] [12] DEBUG: AT2[salut et \' et \\]: sms_split **apres footer et header **2005-03-05 15:57:48 [27073] [12] DEBUG: send_msg: sending msg to box: **127.0.0.1 **2005-03-05 15:57:50 [27054] [8] DEBUG: AT2[salut et \' et \\]: **at2_send_one_message CYRIL **2005-03-05 15:57:50 [27054] [8] DEBUG: AT2[salut et \' et \\]: at2_pdu_encode **CYRIL2005-03-05 15:57:50 [27054] [8] DEBUG: AT2[Wave2]: TP-Validity-Period: **24.0 hours **2005-03-05 15:57:50 [27054] [8] DEBUG: AT2[salut et \' et \\]: latin12gsm **CYRIL **2005-03-05 15:57:50 [27054] [8] DEBUG: AT2[salut et /' et //]: apres **latin12gsm **2005-03-05 15:57:50 [27054] [8] DEBUG: AT2[salut et \' et \\]: sms_at **2005-03-05 15:57:50 [27054] [8] DEBUG
Re: group = sms-service problem
I don't see an smsbox-port defined in your core group. Without that the bearerbox and smsbox cannot communicate. Without communication between the 2 boxes, smsbox will not receive any MO SMS for the default sms-service you declared.. Also, as another reader posted, please try upgrding to v1.4.0. It's much more stable than that 4 year old v1.2.1. See ya... d.c. **From: Matteo Calorio [EMAIL PROTECTED] **To: users@kannel.org **Subject: group = sms-service problem **Date: Fri, 4 Mar 2005 17:12:42 +0100 ** **Hello, ** **I installed Kannel 1.2.1 on a Debian Sarge. I can receive SMSs, but I can't **call a URI to pass some data to a web appl (Apache logs don't show anything **about). ** **I read documentation and some old posts into this list, but I can't understand **where's the problem... Any help? ** **This is my config file /etc/kannel/kannel.conf: ** **=== **group = core **admin-port = 13000 **admin-password = foo **log-file = /var/log/kannel/kannel.log **log-level = 1 **access-log = /var/log/kannel/access.log ** **group = smsc **smsc = emi2 **smsc-id = EX **host = 1.2.3.4 **port = 4152 **smsc-username = 98395734 **smsc-password = Xyyth54fuw **our-port = 1070 **receive-port = 1060 **keepalive = 30 **my-number = 98395734 ** **group = smsbox **bearerbox-host = localhost **sendsms-port = 13131 **sendsms-chars = 0123456789 +- **global-sender = 98395734 **log-file = /var/log/kannel/smsbox.log **log-level = 1 **access-log = /var/log/kannel/access.log ** **group = sendsms-user **username = 98395734 **password = Xyyth54fuw ** **group = sms-service **name = default_service **keyword = default **catch-all = true **send-sender = true **omit-empty = true **get-url = http://localhost/admin/insert-SSMS.php?sms_num=%psms_text=%b; **=== ** ** **Cheers, ** Matteo ** **
Re: DLR Status
**Date: Fri, 04 Mar 2005 16:46:00 -0300 **From: Rafael Ugolini [EMAIL PROTECTED] **To: users@kannel.org **Subject: DLR Status ** **Is it possible to see the DLR status in log-level 4 ? ** **Or i need to set dlr-mask in smsc ? ** **Im a knew user of kannel, i realy dont know... ** **And if anyone send me a log file it would be good :D Please read through the users@kannel.org mailing list about DLRs and how to use them in Kannel. Try the following: http://www.mail-archive.com/users@kannel.org/msg03802.html http://www.mail-archive.com/users@kannel.org/msg03948.html See ya... d.c.
Re: SMSBOX
**From: StephenLim [EMAIL PROTECTED] **To: users@kannel.org **Subject: SMSBOX **Date: Sat, 5 Mar 2005 10:27:09 +0800 ** **I am using kannel patch engine (smsbox and bearerbox) to send chinese **sms. When I send Chinese sms with a [white space] in between, it will **fail to send out. How can accommodate this problem? Is there any **solution? Thanks in advance! It would really help if you posted your log files, configuration files, and procedure on how you sent the SMS. I've had no problems with sending and receiving chinese SMS. See ya... d.c.
Re: problem with multiple SMSC
(Sorry for the late reply everyone...been busy with non-kannel related commitments...) my_kannel is an HTTP SMSC module derived from the kannel HTTP SMSC. Look at: http://www.mail-archive.com/users@kannel.org/msg04106.html CosmoStation's situation (and BTW, it would be really nice to have real names instead of nicknames in the full name section of a To: line...) most likely is due to 3 factors: 1) More than one SMSC routing path for an SMS. 2) An allowed-smsc-id declaration restricting access to the SMSC. 3) The different ways the smsbox handles MT SMS as a reply to an MO SMS (an exec/file/text opposed to get-url/post-url/post-xml).. What is happening is that the smsbox generates an MT reply SMS for the sms-services defined as exec, file, and text. But, smsbox does not add the smsc-id to the SMS Msg structure used internally by Kannel to represent an SMS. This behavior differs from the get-url, post-url, post-xml in that all three of the above will include the smsc-id in the SMS Msg structure that will be passed to the bearerbox. Because you have an allowed-smsc-id declaration for each of your SMSCs, the bearerbox could not find a suitable SMSC delivery agent for the MT reply SMS generated from text-based sms-services. Since the smsc-id in the SMS Msg structure was NULL for the text-based sms-services, it did not match any of the smsc-ids listed in any of your allowed-smsc-id declarations for the SMSCs. That is why you go the Cannot find SMSCConn for message to ... warning and subsequent No SMSCes to receive message... warning in your bearerbox logs. But, the sms-service that used a get-url did include an smsc-id into the SMS Msg structure. As a result, it successfully passed the evaluation in the gateway/gw/smscconn.c:smscconn_usable() function and the message was delivered. Is this a bug? Only if you have the same three factors again. If the bearerbox only had one SMSC connection, then this would not be a problem since: 1) You would not need smsc-ids. 2) You would not assign an ACL via an allowed-smsc-id declaration. I'll post a enquire over on the devel@kannel.org group about this issue. For a quick solution without changing the code and still allowing for the use of allowed-smsc-id for access restrictions: - only use get-url, post-url, or post-xml for all your sms-services. If you want to fix the code, then look on the devel@kannel.org mailing list or the Mantis bugtracking system (http://bugs.kannel.org) on Friday for the patch. See ya... d.c. **From: Rodrigo A. Cremaschi [EMAIL PROTECTED] **To: CosmoStation [EMAIL PROTECTED], users@kannel.org **Subject: Re: problem with multiple SMSC **Date: Thu, 24 Feb 2005 09:52:13 -0300 ** **Hi there, ** **Why are you setting system-type = my_kannel ? ** **system-type should be 'kannel', 'brunet', 'xidris' or 'wapme'. **- Original Message - **From: CosmoStation [EMAIL PROTECTED] **To: users@kannel.org **Sent: Thursday, February 24, 2005 8:07 AM **Subject: problem with multiple SMSC ** ** ** When I use only one SMSC everything is ok. ** When I use multiple SMSCs there is a serious problem. It seems that ** only one service is routed properly and the others (including the ** default/catchall) are not routed to provide MT smses. ** The sms-service with keyword HOR functions properly, but the other do **not. ** ** ** I tried allow-smsc-id and deny-smsc-id variables in the group = smsc ** but neither worked as I was exepted. ** ** Here is an abstract from the access.log file: ** ** 2005-02-24 12:55:10 Log begins ** 2005-02-24 12:55:21 Receive SMS [SMSC:car2] [SVC:] [ACT:] [BINF:] [from:30694411] [to:4541] [flags:0:0:0:-1:-1] [msg:7:hor rak] [udh:0:] ** 2005-02-24 12:55:21 Sent SMS [SMSC:car2] [SVC:hor] [ACT:] [BINF:] [from:4541] [to:30694411] [flags:-1:0:-1:-1:-1] [msg:160:Imatemnogo shansove da izpyknete i da lansirate ideite si. Shte imatevyzmozhnostta da obshtuvate s obichani ot vas hora. Intuicijata vishte vi pomogne da nam] [udh:0:] ** 2005-02-24 12:55:21 Sent SMS [SMSC:car2] [SVC:hor] [ACT:] [BINF:] [from:4541] [to:30694411] [flags:-1:0:-1:-1:-1] [msg:77:eritereshenija na problemite, koito vi pritesnjavat. AEGEAN MEDIA HOROSCOPES] [udh:0:] ** 2005-02-24 12:55:31 Receive SMS [SMSC:car1] [SVC:] [ACT:] [BINF:] [from:30697766] [to:3300] [flags:0:0:0:-1:-1] [msg:8:hor deva] [udh:0:] ** 2005-02-24 12:55:31 Sent SMS [SMSC:car1] [SVC:hor] [ACT:] [BINF:] [from:3300] [to:30697766] [flags:-1:0:-1:-1:-1] [msg:160:Obstojatelstvata, koito se syzdavat v zhivota vi, vi pomagat da si izjasnite dosta neshta. Vecherta posvetete na zabavlenija v kompanijata na prijatelite si, no] [udh:0:] ** 2005-02-24 12:55:31 Sent SMS [SMSC:car1] [SVC:hor] [ACT:] [BINF:] [from:3300] [to:30697766] [flags:-1:0:-1:-1:-1] [msg:67: bydete sdyrzhani vyv finansovo otnoshenie. AEGEAN MEDIA HOROSCOPES] [udh:0:] ** 2005-02-24 12:55:48 Receive SMS [SMSC:car1] [SVC:] [ACT:] [BINF:] [from:30697766] [to:3300]
Re: Can't send SMS
That's an ME failure error. Make sure the mobile device (phone, standalone modem) can still be used to manually send an SMS. One major possibility is that the operator has deactivated the SIM you are using in the modem. If it is a prepaid SIM, then it could be because the SIM was not recharged before the expiration of the current activation period. If it's a postpaid (term-subscription) this the operator might have disabled the SIM because it noticed a large amount of SMS traffic without a corresponding amount of Voice traffic. Try the following steps: Check the mobile device first: - Check that the mobile device can send an SMS manually (e.g. if it's a phone, then manually enter an SMS on the keypad and send it). [fails here, then the device might have hardware problems if the next step fails] - Check if a different SIM in the questionable mobile device can manually send an SMS [fails here, it might be a hardware problem] Check the SIM installed in the mobile device: - Check if the SIM can be used in another phone to manually send an SMS. [fails here, then the operator might have deactivated the SIM] - Check if the SIM in another device can send an SMS if in a different location. [succeeds here, then you need to move the mobile device to a location with better signal strength] See ya... d.c. **Date: Mon, 28 Feb 2005 10:27:10 +0300 **From: Allan hank [EMAIL PROTECTED] **To: users@kannel.org **Subject: Can't send SMS **In-Reply-To: [EMAIL PROTECTED] ** **Hello Kannel Users, ** **I've been using kannel for some time ( 1 month) but of recent it has **turned to be a bizarre for me. I start it and it appeard to have **started well but it can't send an sms. Below is a dump of what i see **in kannel.log **There's nothing in bearerbox.* and smsbox.* ** **I appreciate all the help, **Thank you **- **Allan ** **2005-02-28 10:24:40 [5] DEBUG: AT2[/dev/cuaa1]: -- OK **2005-02-28 10:24:40 [5] DEBUG: AT2[/dev/cuaa1]: -- AT+CMGF=0^M **2005-02-28 10:24:40 [5] DEBUG: AT2[/dev/cuaa1]: -- OK **2005-02-28 10:24:40 [5] DEBUG: AT2[/dev/cuaa1]: -- AT+CSMS=?^M **2005-02-28 10:24:40 [5] DEBUG: AT2[/dev/cuaa1]: -- +CSMS: (0) **2005-02-28 10:24:40 [5] DEBUG: AT2[/dev/cuaa1]: -- OK **2005-02-28 10:24:40 [5] DEBUG: AT2[/dev/cuaa1]: -- AT+CNMI=1,2,0,1,0^M **2005-02-28 10:24:41 [5] DEBUG: AT2[/dev/cuaa1]: -- OK **2005-02-28 10:24:41 [5] INFO: AT2[/dev/cuaa1]: AT SMSC successfully opened. **2005-02-28 10:24:54 [4] DEBUG: Started thread 7 (gw/bb_boxc.c:function) **2005-02-28 10:24:54 [7] INFO: Client connected from 127.0.0.1 **2005-02-28 10:24:54 [7] DEBUG: Started thread 8 (gw/bb_boxc.c:boxc_sender) **2005-02-28 10:27:33 [7] DEBUG: boxc_receiver: sms received **2005-02-28 10:27:35 [5] DEBUG: AT2[/dev/cuaa1]: TP-Validity-Period: 24.0 hours **2005-02-28 10:27:35 [5] DEBUG: AT2[/dev/cuaa1]: -- AT+CMGS=49^M **2005-02-28 10:27:35 [5] DEBUG: AT2[/dev/cuaa1]: -- **2005-02-28 10:27:35 [5] DEBUG: AT2[/dev/cuaa1]: send command status: 1 **2005-02-28 10:27:35 [5] DEBUG: AT2[/dev/cuaa1]: -- **11000B915276818899F1A7276171FA1C168741D7347BFE7683D27310BD3CA7A7DD6785 **51FE6EEB40F7347BFE768300 **2005-02-28 10:27:35 [5] DEBUG: AT2[/dev/cuaa1]: -- ^Z **2005-02-28 10:27:39 [5] DEBUG: AT2[/dev/cuaa1]: -- **2005-02-28 10:27:39 [5] DEBUG: AT2[/dev/cuaa1]: -- +CMS ERROR: 130 **2005-02-28 10:27:39 [5] ERROR: AT2[/dev/cuaa1]: CMS ERROR: +CMS ERROR: 130 **2005-02-28 10:27:39 [5] DEBUG: AT2[/dev/cuaa1]: send command status: 1 **2005-02-28 10:27:39 [5] DEBUG: AT2[/dev/cuaa1]: -- AT+CMGS=49^M **2005-02-28 10:27:39 [5] DEBUG: AT2[/dev/cuaa1]: -- **2005-02-28 10:27:39 [5] DEBUG: AT2[/dev/cuaa1]: send command status: 1 **2005-02-28 10:27:39 [5] DEBUG: AT2[/dev/cuaa1]: -- **11000B915276818899F1A7276171FA1C168741D7347BFE7683D27310BD3CA7A7DD6785 **51FE6EEB40F7347BFE768300 **2005-02-28 10:27:39 [5] DEBUG: AT2[/dev/cuaa1]: -- ^Z **2005-02-28 10:27:42 [5] DEBUG: AT2[/dev/cuaa1]: -- **2005-02-28 10:27:42 [5] DEBUG: AT2[/dev/cuaa1]: -- +CMS ERROR: 130 **2005-02-28 10:27:42 [5] ERROR: AT2[/dev/cuaa1]: CMS ERROR: +CMS ERROR: 130 **2005-02-28 10:27:42 [5] DEBUG: AT2[/dev/cuaa1]: send command status: 1 **2005-02-28 10:27:42 [5] DEBUG: AT2[/dev/cuaa1]: -- AT+CMGS=49^M **2005-02-28 10:27:42 [5] DEBUG: AT2[/dev/cuaa1]: -- **2005-02-28 10:27:42 [5] DEBUG: AT2[/dev/cuaa1]: send command status: 1 **2005-02-28 10:27:42 [5] DEBUG: AT2[/dev/cuaa1]: -- **11000B915276818899F1A7276171FA1C168741D7347BFE7683D27310BD3CA7A7DD6785 **51FE6EEB40F7347BFE768300 **2005-02-28 10:27:42 [5] DEBUG: AT2[/dev/cuaa1]: -- ^Z **2005-02-28 10:27:44 [5] DEBUG: AT2[/dev/cuaa1]: -- **2005-02-28 10:27:44 [5] DEBUG: AT2[/dev/cuaa1]: -- +CMS ERROR: 130 **2005-02-28 10:27:44 [5] ERROR: AT2[/dev/cuaa1]: CMS ERROR: +CMS ERROR: 130 **2005-02-28 10:27:44 [5] DEBUG: AT2[/dev/cuaa1]: send command status: 1 **
Re: DLR handling
**Date: Fri, 25 Feb 2005 16:20:08 +0200 **From: Kaspars Foigts [EMAIL PROTECTED] **To: users@kannel.org **Subject: DLR handling ** ** ** Hello! ** ** I got a problem with DLR handling in Kannel (latest). When kannel ** submits short message via SMPP v3.4, it receives message_id in ** decimal format. Delivery reports contain this message_id in decimal ** format too. So, in corresponding SMSC group i set msg-id-type to ** 0x00 (which means deliver_sm decimal, submit_sm_resp decimal). ** ** However, log shows following (excerpts only): ** **2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP PDU dump ends. **2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP[Zimbabwe]: Sending PDU: **2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP PDU 0x81ab440 dump: **2005-02-25 16:01:20 [10232] [7] DEBUG: type_name: submit_sm **2005-02-25 16:01:20 [10232] [7] DEBUG: command_id: 4 = 0x0004 **2005-02-25 16:01:20 [10232] [7] DEBUG: command_status: 0 = 0x **2005-02-25 16:01:20 [10232] [7] DEBUG: sequence_number: 3 = 0x0003 **2005-02-25 16:01:20 [10232] [7] DEBUG: service_type: NULL **2005-02-25 16:01:20 [10232] [7] DEBUG: source_addr_ton: 2 = 0x0002 **2005-02-25 16:01:20 [10232] [7] DEBUG: source_addr_npi: 1 = 0x0001 **2005-02-25 16:01:20 [10232] [7] DEBUG: source_addr: 930730301 **2005-02-25 16:01:20 [10232] [7] DEBUG: dest_addr_ton: 2 = 0x0002 **2005-02-25 16:01:20 [10232] [7] DEBUG: dest_addr_npi: 1 = 0x0001 **2005-02-25 16:01:20 [10232] [7] DEBUG: destination_addr: 92379150131039958 **2005-02-25 16:01:20 [10232] [7] DEBUG: esm_class: 3 = 0x0003 **2005-02-25 16:01:20 [10232] [7] DEBUG: protocol_id: 0 = 0x **2005-02-25 16:01:20 [10232] [7] DEBUG: priority_flag: 0 = 0x **2005-02-25 16:01:20 [10232] [7] DEBUG: schedule_delivery_time: NULL **2005-02-25 16:01:20 [10232] [7] DEBUG: validity_period: NULL **2005-02-25 16:01:20 [10232] [7] DEBUG: registered_delivery: 0 = 0x **2005-02-25 16:01:20 [10232] [7] DEBUG: replace_if_present_flag: 0 = 0x **2005-02-25 16:01:20 [10232] [7] DEBUG: data_coding: 0 = 0x **2005-02-25 16:01:20 [10232] [7] DEBUG: sm_default_msg_id: 0 = 0x **2005-02-25 16:01:20 [10232] [7] DEBUG: sm_length: 11 = 0x000b **2005-02-25 16:01:20 [10232] [7] DEBUG: short_message: Information **2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP PDU dump ends. ** **2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP[Zimbabwe]: Got PDU: **2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP PDU 0x81ab440 dump: **2005-02-25 16:01:20 [10232] [7] DEBUG: type_name: submit_sm_resp **2005-02-25 16:01:20 [10232] [7] DEBUG: command_id: 2147483652 = 0x8004 **2005-02-25 16:01:20 [10232] [7] DEBUG: command_status: 0 = 0x **2005-02-25 16:01:20 [10232] [7] DEBUG: sequence_number: 3 = 0x0003 **2005-02-25 16:01:20 [10232] [7] DEBUG: message_id: 26774754 **2005-02-25 16:01:20 [10232] [7] DEBUG: SMPP PDU dump ends. Where's the log entry stating the bearerbox has created a DLR entry? It should look something like: 2005-02-25 16:01:20 [10232] [7] DEBUG: DLR[internal]: Adding DLR smsc=Zimbabwe, ts=, src=930730301, dst=92379150131039958, mask=X, boxc= Where X was the dlr-mask you issued for the MT SMS. ** **2005-02-25 16:01:38 [10232] [7] DEBUG: SMPP[Zimbabwe]: Got PDU: **2005-02-25 16:01:38 [10232] [7] DEBUG: SMPP PDU 0x81ab440 dump: **2005-02-25 16:01:38 [10232] [7] DEBUG: type_name: deliver_sm **2005-02-25 16:01:38 [10232] [7] DEBUG: command_id: 5 = 0x0005 **2005-02-25 16:01:38 [10232] [7] DEBUG: command_status: 0 = 0x **2005-02-25 16:01:38 [10232] [7] DEBUG: sequence_number: 2 = 0x0002 **2005-02-25 16:01:38 [10232] [7] DEBUG: service_type: NULL **2005-02-25 16:01:38 [10232] [7] DEBUG: source_addr_ton: 0 = 0x **2005-02-25 16:01:38 [10232] [7] DEBUG: source_addr_npi: 0 = 0x **2005-02-25 16:01:38 [10232] [7] DEBUG: source_addr: 930730301 **2005-02-25 16:01:38 [10232] [7] DEBUG: dest_addr_ton: 0 = 0x **2005-02-25 16:01:38 [10232] [7] DEBUG: dest_addr_npi: 0 = 0x Why is your Operator telling you that the destination TON and NPI is zero (0)? They should be returning TON=2/NPI=1 (what you submitted to them) unless your operator is using async TON/NPI...which would be really weird. **2005-02-25 16:01:38 [10232] [7] DEBUG: destination_addr: 92379150131039958 **2005-02-25 16:01:38 [10232] [7] DEBUG: esm_class: 4 = 0x0004 **2005-02-25 16:01:38 [10232] [7] DEBUG: protocol_id: 0 = 0x **2005-02-25 16:01:38 [10232] [7] DEBUG: priority_flag: 0 = 0x **2005-02-25 16:01:38 [10232] [7] DEBUG: schedule_delivery_time: NULL **2005-02-25 16:01:38 [10232] [7] DEBUG: validity_period: NULL **2005-02-25 16:01:38 [10232] [7] DEBUG: registered_delivery: 0 = 0x **2005-02-25 16:01:38 [10232] [7] DEBUG: replace_if_present_flag: 0 = 0x **2005-02-25 16:01:38 [10232] [7] DEBUG: data_coding: 0 = 0x
Re: Kannel with dlr and wavecom
**From: Nicola Provenzano [EMAIL PROTECTED] **To: users@kannel.org **Subject: Re: Kannel with dlr and wavecom **Date: Mon, 28 Feb 2005 10:57:53 +0100 **In-Reply-To: [EMAIL PROTECTED] ** **Hello, **is there a way for sending a sms, from a gsm modem, with a phone number **different from that one of sim card? ** **I expain myself better, i think that i could send a sms from a gsm modem and **retrive the correspondent dlr from an other gsm modem. ** **Probably, in this way, i could bypass the AT problems. ** **Is it an unattainable idea? The MSISDN is associated with the SIM. If you send out an SMS using the GSM network (over the radio waves) then you have no control over the origination address. The MSC determines this before forwarding your SMS to the SMSC via an SS7 MAP signal. See ya... d.c.
Re: source_addr_ton/npi and dest_addr_ton/npi
**Date: Mon, 28 Feb 2005 15:22:46 +0200 **From: Kaspars Foigts [EMAIL PROTECTED] **To: users@kannel.org **Subject: source_addr_ton/npi and dest_addr_ton/npi ** ** ** Still noone bothered answering my mail about DLR's. Anyone, one more ** question. This time about source/dest_addr_ton/npi PDU parameters ** and delivery reports (again). ** ** On delivery reports - is it possible to request delivery reports, if ** incoming short message is processed by kannel? For example: ** **group = sms-service **keyword = info **keyword-regex = ^(info|i)$ **text = Information **faked-sender = 123456701 ** ** I would like to know, if this message is delivered to user, but ** kannel does not set registered_delivery PDU parameter. I guess this ** could be related to my first mail about DLR's not being processed. No. The reson why you cannot get a DLR for this type of sms-service is because you cannot set the dlr-mask needed to indicate to Kannel which DLR's you are interested in receiving from the SMSC. If, instead of a text=, you use a get-url or post-url to an external service (and the accept-x-kannel-headers is set for the service), and the external service issues back the two Kannel HTTP optional headers: X-Kannel-DLR-URL: http://some.url/... X-Kannel-DLR-Mask: 31 Then, you could get DLR's for that sms-service. Read the thread about receiving DLRs in the users@kannel.org archive: http://www.mail-archive.com/users@kannel.org/msg03945.html ** ** Why it is not possible to modify source-addr-ton/npi and ** destination-addr-ton/npi? I'm trying to set them in configuration ** file: ** **group = smsc **smsc = smpp **smsc-id = MyOperator **system-type = VMA **host = xxx.xxx.xxx.xxx **port = **smsc-username = **smsc-password = **source-addr-autodetect = no **msg-id-type = 0x00 **# source-addr-ton = 2 **source-addr-ton = 23 What's TON=23? TON is only 3 bits long. **dest-addr-ton = 1 **log-file = /var/log/kannel/smsc-myoperator.log ** ** No matter, what I set, Kannel submits sm with its own TON/NPI's ** **2005-02-28 15:11:44 [1264] [7] DEBUG: source_addr_ton: 2 = 0x0002 **2005-02-28 15:11:44 [1264] [7] DEBUG: source_addr_npi: 1 = 0x0001 **2005-02-28 15:11:44 [1264] [7] DEBUG: source_addr: 1234567890123456701 **2005-02-28 15:11:44 [1264] [7] DEBUG: dest_addr_ton: 2 = 0x0002 **2005-02-28 15:11:44 [1264] [7] DEBUG: dest_addr_npi: 1 = 0x0001 **2005-02-28 15:11:44 [1264] [7] DEBUG: destination_addr: 3711234567 ** ** Probably related question - if/when will it be available to ** configure these parameters? For example, one of our operators uses some ** non-standard ton/npi settings. If they do not correspond to ** operator's preferences, message is not accepted. Type Of Number (TON) range for Kannel: 0 0 0 = 0 = unknown 0 0 1 = 1 = International 0 1 0 = 2 = National number 0 1 1 = 3 = Network specific 1 0 0 = 4 = Subscriber number 1 0 1 = 5 = Alphanumeric 1 1 0 = 6 = Abbreviated 1 1 1 = 7 = Reserved Number Plan Identifier (NPI) range for Kannel: 0 0 0 0 = 0 = unknown 0 0 0 0 = 1 = ISDN/E.164/E.163 0 0 1 0 = 2 = reserved 0 0 1 1 = 3 = Data numbering plan (X.121) 0 1 0 0 = 4 = Telex numbering plan 0 1 0 1 = 5 = Service Center specific plan to External Short Msg Entity attach 0 1 1 0 = 6 = Service Center specific plan ESME attached to SMSC 0 1 1 1 = 7 = reserved 1 0 0 0 = 8 = national numbering plan 1 0 0 1 = 9 = private numbering plan 1 0 1 0 = 10 = ERMES numbering plan 1 0 1 1 = 11 = reserved 1 1 0 0 = 12 = reserved 1 1 0 1 = 13 = reserved 1 1 1 0 = 14 = reserved 1 1 1 1 = 15 = reserved Set the TON and NPI and then restart the bearerbox. If set the bearerbox loglevel to 0, then each time an MT SMS is sent through Kannel, you should see a log message like: SMPP[MyOperator]: Manually forced dest addr ton = x, dest add npi = y or SMPP[MyOperator]: Manually forced source addr ton = x, source add npi = y depending on whether you set source-addr-ton/source-addr-npi or destination-addr-ton/destination-addr-npi. And, x = TON number, y = NPI number. See ya... d.c.
Re: denied host error on version 1.4.0
**Date: Sat, 26 Feb 2005 03:04:33 +1100 (EST) **From: Pak Bei [EMAIL PROTECTED] **Subject: denied host error on version 1.4.0 **To: users@kannel.org ** **I'm trying using Kannel bearerbox II version 1.4.0 **But denied host error occure while box-allow-ip **already define.. ** **Any help would be apprecciated. ** **Best Regards. ** **Attached is my kannel.conf ** **While i'd like to sendsms (push sms), **the bearerbox denied the request... **I'm sure sendsms coming from PC with IP already define **inside box-allow-ip. ** **Here is my error Log(...tried from denied host...): ** **2005-02-25 23:10:39 [14148] [2] DEBUG: HTTP: Creating **HTTPClient for `10.87.19.6'. **2005-02-25 23:10:39 [14148] [6] DEBUG: **HTTP[smsc_http]: Got request `/cgi-bin/sendsms' **2005-02-25 23:10:39 [14148] [6] INFO: HTTP[smsc_http]: **Connection `/cgi-bin/sendsms' tried from denied host **10.87.19.6, ignored **2005-02-25 23:10:39 [14148] [6] DEBUG: HTTP: **Destroying HTTPClient area 0x81d1f98. **2005-02-25 23:10:39 [14148] [6] DEBUG: HTTP: **Destroying HTTPClient for `10.87.19.6'. **2005-02-25 23:10:39 [14148] [6] DEBUG: **HTTP[smsc_http]: Destroying client information HTTP SMSC does not use the box-allow-ip from the core group. It uses it's own connect-allow-ip declaration. If connect-allow-ip is not declared, then only localhost can access the port the HTTP SMSC listens on. See ya... d.c.
Re: smsc_http, MO msg from SMSC Simulation and denied host error
**Date: Sat, 26 Feb 2005 13:32:52 +1100 (EST) **From: Pak Bei [EMAIL PROTECTED] **Subject: smsc_http, MO msg from SMSC Simulation and denied host error **To: users@kannel.org ** **I'm using kannel 1.4.0. **I'd like to use smsc_http. ** **group = smsc **smsc = http **smsc-id = smsc_http **system-type = kannel **smsc-username = foo **smsc-password = bar **port = 13020 **send-url = **http://10.1.2.3:8080/smsc/push?user=foopass=barfrom=%pto=%Ptext=%r ** **My Question is how to simulate MO message incoming **from **fake smsc (using web browser for example)? ** **In my previuos test: **1. Kannel succesfully deliver smspush via **/cgi-bin/sendsms to appropriate SMSC. **2. While i tried to simulate MO message form SMSC, **using: **http://10.1.2.2:13020/username=foopassword=barto=62811909401text=test ** **Kannel will produce exeption error like this: **2005-02-25 23:10:39 [14148] [6] INFO: HTTP[smsc_http]: **... tried from denied host 10.1.2.3, ignored ** **I expect incoming MO message should replied to **destination SMSC. ** **Any hints, help, sugestions would be appreciated. Answer to denied host error... As I stated in another reply, Kannel's HTTP SMSC uses the connect-allow-ip declaration to specify which hosts have access to inject an MO SMS via a connection to the port specified in the port = declaration. About the HTTP SMSC... An MO SMS entering the port specified by the HTTP SMSC does not get forwarded to the URL specified by the send-url declaration. Instead, the MO SMS is sent up to the smsbox for processing. An MT SMS submitted to the smsbox with the smsc-id of the HTTP SMSC will be forwarded to the URL specified by the send-url declaration. See ya... d.c.
Re: RE : Kannel with dlr and wavecom
Here's an explanation of how the GSM modem sends and receives SMS and DLRs. Based on the setting for the +CNMI (New Message Indictor), an MO SMS (one originating from a phone and heading to your GSM modem) can get the GSM modem to inform Kannel when it receives an SMS. The first way is an unsolicited notification with the hexadecimal representation of the PDU. This would be the +CMT: ,## followed by a long string of hexadecimal numbers in your bearerbox log. When the bearerbox receives this, it will respond back to the GSM network that it has received the SMS via a +CNMA (New Message Acknowledgement). If the modem does not receive an AT+CNMA from the bearerbox with a specified time, the GSM modem will send back a RP-ERROR to the GSM network's SMSC indicating problems receiving the SMS. The Operator's SMSC will reschedule the SMS for another delivery attempt. Therefore, DELAYING THE NEW MESSAGE ACKNOWLEDGEMENT CAN RESULT IN RECEPTION OF DUPLICATE SMS. Another method the GSM modem can use to inform Kannel of an incoming MO SMS is with a unsolicited notification with the PDU stored in the store memory (be it the device's [ME] or SIM [SM]). This would be the +CMTI: XX,# you see in your bearerbox logs. The XX indicates the store memory used (again ME means the device's memory and SM means the SIM card's memory) and the # indicates the index number of of the storage location holding the received MO SMS. In this case, no New Mesage Acknowledgement is submitted by the bearerbox because the GSM modem automatically acknowledges the reception for you. BUT YOU STILL GET THAT UNSOLICITED NOTIFICATION INTERRUPTING ANY CURRENT TRANSACTION HAPPENING ON THE MODEM! As you might have noticed, that unsolicited notification (+CMT: or +CMTI:) can pop up at anytime...even during the middle of the bearerbox sending out an SMS via the AT+CMGS command. When that unsolicited notification show up in the middle of a send, the bearerbox freak out and assumes an error because it expects the GSM modem to send a '' at the beginning of the line when it issues the AT+CMGS command. Actually, depending on wheter that '' appears before the +CMT:/+CMTI: or after it, Kannel might see it. Now, for those of you adding DLR's to the mix, there's an additional problem. DLR's are sent to the GSM modem as special SMS and the GSM modem will inform Kannel about a DLR via another unsolicited notification, the +CDS: ,## (Delivery Status) followed by a long string of hexadecimal numbers you see in the bearerbox logs. +CDS also needs an AT+CNMA acknowledgement. And, just like +CMT, +CDS has the same ramifications for delaying that acknowledgement. And just like +CMTI:, a delivery report can slip into store memory and pop up an unsolicited notification of +CDSI: XX,# right in the middle of things. But one new twist is that newer GSM modems seem to have additional store memory specifically for delivery reports. This new SR store memory complicates the issue. Kannel has the capability to check the store memory for both the device and one other storage location (determined by the message-storage declaration of the modems section). This is the sim-buffering declaration you see in the AT SMSC. Unfortunately, the bearerbox does not know how to look at 3 different stores (ME, SM, SR) yet. The consequences are that DLRs could slip into the SR memory and be overlooked by the check memory store for incoming SMS/DLR thread that runs periodcally based on the keepalive value or 60 seconds if the keepalive is not set. Also, this thread is responsible for draining the queue inside of the memory store. If that thread does not know about the SR memory, then the only time a DLR can be retrieve from the SR memory would be when the +CDSI: shows up...and then only one DLR will be retrieved from the SR memory. I have a feeling that might be the reason why JML was seeing multiple DLRs for the same message ID (ts field in Kannel's DLR logging, +CMGS: ## from the GSM modem). So, in addition to incoming SMS/DLR interrupting out-going SMS you might also have the problem of DLR slipping into a memory store overlooked by the bearerbox. What is a solution to this problem? Rewrite the AT driver with a more robust state engine that can support unsolicited notifications better. Also, update the driver to support dipping into more that two memory stores for SMS/DLR. Just a note. The AT driver (what us oldies actually call AT2 for historical reasons) was originally written back in 2001. It was not designed for high traffic but more of a convenience for testing services or sending VERY low traffic. Given the fact that circa 2001, most GSM modems where 9600 baud DCE and one SMS too about 5 seconds to transmit over-the-air, you can understand how the AT driver was not really in the same league as a real connection to an SMSC. See ya... d.c. **From: JML [EMAIL PROTECTED] **To: 'B. Indrawan' [EMAIL PROTECTED], 'Kannel' users@kannel.org **Subject: RE : Kannel with dlr and
Re: Public SMSC ?? / Best GSM Modem with Kannel - will appreciate
**Date: Mon, 21 Feb 2005 15:03:31 +0530 **From: TecExperts [EMAIL PROTECTED] **To: users@kannel.org **Subject: Public SMSC ?? / Best GSM Modem with Kannel - will appreciate ** **Looking for best GSM modem (name with price) to work with Kannel. Will **be using for bulkSMS as well. ** **Any Public SMSC (IP) running for testing anywhere ? If you just want to test (without sending/receiving real SMS to/from a phone), then I would suggest starting up the JAVA SMPP simulator available from opensmpp (http://opensmpp.logica.com). They have an SMSC simulator (with JAVA source code). I had to hack it a bit to correct DLR (added Origination/Destination address, esm_class 4, protocol id 1, stat as an ASCII word instead of a decimal number) generation. Otherwise, it works fine. See ya... d.c.
Re: WAP users filtering
**From: Carel, Michael P. (Digitel-GSM) [EMAIL PROTECTED] **To: users@kannel.org **Subject: WAP users filtering **Date: Tue, 22 Feb 2005 10:15:31 +0800 ** **Hi to all, ** **Can kannel block/allow specific number(MSISDN) users via white-list regex? **For what I've read in the users manual it is only for SMS/SMSC filtering... **Can I do the same for the WAP users? I need to set rules for specific MSISDN **who can use WAP. ** **Thanks in advance.. The WAP specifications do not define any way to provide to a WAP gateway the MSISDN associated with the IP connection. As a result, there is no standard method to limit access to the WAP gateway via an MSISDN. However, if you have direct access to the Network Access Server (NAS) or the Serving GPRS Support Node (SGSN) AND it uses RADIUS accounting, then you could configure Kannel to act as a RADIUS accounting proxy. Once Kannel is in between the NAS/SGSN and the real RADIUS server, Kannel can obtain the MSISDN to IP address mapping. From there, it would be simple for the WAP gateway to support access lists. Of course, getting this type of access either means you are setting up your own dial-in server (NAS) or are paying mucho dollars to the Mobile Network Operator to gain access to the information. Oh Wait! If you are part of Digitel Mobile in the Philippines, then you might be able to access the provisioning system. In that case, you would only need to modify gateway/gw/bb_udp.c:udp_receiver() and in the else block of the validation of the IP address (if (!is_allowed_ip(..)): - Add a query for IP-MSISDN mapping (probably cache the results for 1/4 the lifetime of the default DHCP lease). - Create the MSG structure (and populate it) only if the MSISDN is allowed. See ya... d.c.
Re: box deny ip
**From: Carel, Michael P. (Digitel-GSM) [EMAIL PROTECTED] **To: users@kannel.org **Subject: box deny ip **Date: Tue, 22 Feb 2005 12:45:34 +0800 ** **Hi, ** **Im limiting my server wap connection to certain IP's, I used to set my **kannel.config as: ** ** **group = core **admin-port = 13000 **wapbox-port = 13002 **admin-password = bar **#status-password = foo **admin-allow-ip = 192.168.5.1;127.0.0.1 **wdp-interface-name = * **log-file = /var/log/kannel/bearerbox.log **log-level = 1 **box-deny-ip = 10.*.*.* **box-allow-ip = 192.168.5.1 **udp-allow-ip = 192.168.5.1 **access-log = /var/log/kannel/access.log ** **group = wapbox **bearerbox-host = localhost **log-file = /var/log/kannel/wapbox.log **log-level = 1 **syslog-level = none **access-log = /var/log/kannel/wapaccess.log ** ** **I'm blocking all 10.0.0.0 networks to use the wap gateway... But still this **IP can continue to connect and successfully browse thru the gateway.. Any **idea why? Do I miss something? It a peculiarity of the gateway/gwlib/util.c:is_allowed_ip() function. You MUST set a deny list as well as an allow list. Configure your udp-deny-ip = *.*.*.* and the filtering will work. I'll add this to my update of the Kannel userguide. See ya... d.c.
Re: Pbs with some characters in SMS
**Date: Sun, 20 Feb 2005 16:16:06 +0100 **From: [EMAIL PROTECTED] **To: users@kannel.org **Subject: Pbs with some characters in SMS **User-Agent: Internet Messaging Program (IMP) 3.2.5 ** **When submitting SMS through Kannel, I've got some troubles in the SMS, are **wrote \ on the SMS, same for ' . Does someone meet the same issues ? It appears that the application submitting the SMS (via sendsms) is escaping the quote marks. You can verify this by looking at your smsbox.log. Chances are, you will see that your application send a back-slash in front of all your quotes (single and double quote). The sendsms-user service inside the smsbox does not perform any character escaping. See ya... d.c.
Re: Can't send more than 9 sms ! Help !!!
**From: JML [EMAIL PROTECTED] **To: users@kannel.org **Subject: Can't send more than 9 sms ! Help !!! **Date: Sun, 20 Feb 2005 14:51:37 +0100 ** **Hi ! **Using kannel 1.4.0, with wavecom modems, on mandrake 10.1. **We use a http interface for sending sms. **Everything is ok with a one by one SMS( sending, receiving, Mysql DLR's, **etc.) ** **But as soon as we try more ( as few as 30!) we get errors : Here is the **debug : **[...] [ ... lines deleted ... ] **What's going wrong ??? **Please heellp !! Think about what is going on in the modem. You are not only asking the modem to send the SMS, but also to receive any DLRs coming from the Operator at the same time. What is most likely happening is that the bearerbox's sending out of SMS is being interrupted by the unsolicited notifications caused by reception of the DLR from the operator. Here is how the bearerbox sends an SMS through the GSM modem: - When the bearerbox tries to send out an SMS, it issues an AT+CMGS command to the modem. - The bearerbox expects an '' symbol to indicate the modem is ready to receive the hexadecimal representation of PDU. - The bearerbox sends the hexadecimal representation of the PDU and then a ^Z (ASCII character 0x1A) to indicate it is done with the PDU. - The bearerbox expects the GSM modem to respond back with: +CMGS: ## where ## is a number representing the current outgoing SMS count. At any time the above sequence is interrupted (for example by a reception of a DLR), then the bearerbox assumes the sending of the SMS failed and will retry to submit the scenario specified about again (up to 2 addition attempts). When the DLR is sent by the Operator, the GSM modem will receive it and interrupt anything currently happening and issue an unsolicited notification (in this case a +CMT or +CMTI) to indicate it received something from the operator. This DLR can and does interfer with the bearerbox's expected send/response sequence. The only thing to do would be to: - Not request the DLR - Not send SMS until you received the DLR from the previous sent SMS - Send out the SMS but set the deferred delivery option so that you can send out all the SMS first and then get the DLR afterwards. - Re-write the AT driver to have a more robust state machine. See ya... d.c.
Re: HTTP proxy settings
**From: Carel, Michael P. (Digitel-GSM) [EMAIL PROTECTED] **To: users@kannel.org **Subject: HTTP proxy settings **Date: Mon, 21 Feb 2005 12:36:34 +0800 ** **I'm just new in Kannel... Just wanna know if Kannel is capable of routing **internet connection via HTTP proxy server? I don't have any Direct Internet **connection, instead I'm connecting via an HTTP proxy server. If ever may I **know which part should it be configured. ** Try reading the userguide. There's a section on how to configure Kannel's bearerbox (group = core) to use an HTTP proxy. See ya... d.c.
Re: Using Siemens MC35i as smsc AT2
**From: Pedro Braz?o Ferreira [EMAIL PROTECTED] **To: 'Davy Chan' [EMAIL PROTECTED] **Subject: RE: Using Siemens MC35i as smsc AT2 **Date: Thu, 17 Feb 2005 15:54:20 - ** **Your explanation was very hopeful! Now, the creation of AT smsc instances is **good. Glad to hear it. So what was the problem? 1) smsc is mispelled 2) extra characters (e.g. double-byte characters instead of ASCII) 3) incorrect parsing due to the extra blank line between group = smsc and smsc = at? 4) Something else. See ya... d.c.
Re: message_id uniqueness?
**To: users@kannel.org **From: Matthew Hixson [EMAIL PROTECTED] **Subject: message_id uniqueness? **Date: Tue, 15 Feb 2005 11:41:52 -0800 ** **As I understand things the SMSC is in charge of creating message_ids **for each SMS. Should there ever be a case where two consecutive SMS **messages are assigned the same message_id? I ask because this is what **I see from a recent test while sending a ringtone that was chopped into **two SMS messages. The message_ids in bearerbox.log were identical. ** Is this normal? I guess now you know why Kannel has a 'ts' field instead of a 'unique-id' field in its dlr storage for such a long time ;-). Looks like your SMPP server does not return unique message-id's to you. You should ask them. They might (as you speculated before) have a SMPP server that using some variation of time in seconds as their message-id. Talk with them to verify this. About the only recourse would be to tell the they are not in specs with SMPP v3.4: 5.2.23 messsage_id The unique message identifier reference assigned by the SMSC to each submitted short message. It is an opaque value and is set according to SMSC implementation. It is returned by the SMSC in the submit_sm_resp, submit_multi_resp, deliver_sm_resp and data_sm_resp PDUs and my be used by the ESME in subsequent SMPP operations relating to the short message, e.g., the ESME can use the query_sm operation to query a previously submitted message using the SMSC message_id as the message handle. But, I'm know sure of v3.3. Anyone have the old Logica v3.3 SMPP specs anywhere? See ya... d.c.
Re: Setting DCS field
**From: J. Kizito [EMAIL PROTECTED] **To: users@kannel.org **Subject: Setting DCS field **Date: Mon, 14 Feb 2005 14:25:33 +0100 **User-Agent: KMail/1.7.92 ** **Hi list, **I am using kannel 1.3.1 and having problems setting the DCS (Data Coding **Scheme) field when sending the message from kannel to the SMS-C. My provider **requires me to use DCS=0xF5. I see a number of parameters like mclass, coding **and mwi that all set certain bits of the DCS field but I have no idea on what **values they should take on (if I am supposed to use them) in order for me to **achieve my goal. Does anyone have an idea on this? Hope I remember this right... DCS = 0xF5 means the following: 0101 ||++--- Message Class 1 |+- 8-bit data +-- Reserved Contains only data coding and message class info Therefore, I think you need to set the following when sending an SMS to your v1.3.1 Kannel: alt-dcs=1 coding=2 mclass=2 For Kannel versions after 1.3.1: alt-dcs=1 coding=1 mclass=1 See ya... d.c.
Re: setting the Content-Type HTTP POST header
**To: users@kannel.org **From: Matthew Hixson [EMAIL PROTECTED] **Subject: setting the Content-Type HTTP POST header **Date: Fri, 11 Feb 2005 15:40:56 -0800 ** **When POSTing to Kannel should I always use a content type of **text/plain for SMS text messages and application/octet-stream for **all binary SMS messages? The binary messages we will be sending will **contain ringtones. Yes. Based on your content type declaration in the HTTP headers, Kannel will set it's coding to the proper value. Just remember there's one exception to this rule. If you are sending UCS-2 encoded text then you will need to set the content-type to: text/plain; charset=UTF-16BE Also, ensure you have a correct content-length HTTP header declaration for any 8-bit content you send with content-type of application/octet-stream. Making it guess will waste alot of time growing the input buffer. See ya... d.c.
Re: need help on SMSC hhtp
**Date: Tue, 8 Feb 2005 22:59:54 +0200
**From: CosmoStation [EMAIL PROTECTED]
**To: users@kannel.org
**Subject: need help on SMSC hhtp
**
**Dear users/developers,
**
**I use kannel for SMS (MO/MT) using smpp connection to SMSC.
**
**I want to receive/send messages via an http api, because this is the
**only way for one carrier (they do not give any smpp access).
**But the api I am ofered is not one of these coded in smsc_http.c. I
**searched the mailing list archives for documentation and thought I
**should add a new http api. Since I am not familiarised with C, I did
**not manage to find out how this should be done.
**It seems it is too complex to me. Unfortunately, my efforts to just
**edit a few arguments to achieve what I need was not successful.
**I would appreciated it, if someone could help me on that.
**
**You can see how this http api works
**
**MO-Receiving messages:
**http://*.*.*.*/path/script?id=1from_gsm=49171234567to_gsm=msg=hallo%20worldtimestamp=20050208224735
**
**where arguments are as follows:
**id: unique SMS identifiacation
**from_gsm: from number
**to_gsm: to number
**msg: text
**timestamp: year/month/day/hour/min/sec
1) Edit gateway/gw/smsc/smsc_http.c
2) Copy the function static void kannel_receive_sms() to
static void my_kannel_receive_sms().
3) Edit the function: my_kannel_receive_sms()
3a) Define another Octstr that will be used to store the incoming value
of the timestamp:
Octstr *asc_timestamp;
3b) Define a variable to hold the timestamp:
time_t t = (time_t) 0;
3c) Add the following before the user = http... line:
asc_timestamp = http_cgi_variable(cgivars, timestamp);
3d) Comment out:
user = http_cgi_variable(cgivars, username);
3e) Comment out:
pass = http_cgi_variable(cgivars, password);
3f) Change
from = http_cgi_variable(cgivars, from);
to:
from = http_cgi_variable(cgivars, from_gsm);
3g) Change
to = http_cgi_variable(cgivars, to);
to:
to = http_cgi_variable(cgivars, to_gsm);
3h) Change
text = http_cgi_variable(cgivars, text);
to:
text = http_cgi_variable(cgivars, msg);
3i) Change
tmp_string = http_cgi_variable(cgivars, coding);
if(tmp_string) {
sscanf(octstr_get_cstr(tmp_string),%d, coding);
}
to:
tmp_string = http_cgi_variable(cgivars, Bin);
if(tmp_string) {
sscanf(octstr_get_cstr(tmp_string),%d, coding);
if (coding1) coding=1;
}
3j) Change
debug(smsc.http.kannel, 0, HTTP[%s]: Received an HTTP request,
octstr_get_cstr(conn-id));
to:
debug(smsc.http.my_kannel, 0, MY_HTTP[%s]: Received an HTTP request,
octstr_get_cstr(conn-id));
3k) Search for the line:
if (user == NULL || pass == NULL ||
Delete everything from that line until the
else if (from == NULL || to == NULL || text == NULL) {
Then delete the 'else' in front of the 'if' in the above line.
3l) Search for the following line within the kannel_receive_sms() function:
msg-sms.time = time(NULL);
Replace with:
if ( octstr_len(asc_timestamp) == 14 ) {
struct tm tm;
char num[5];
octstr_get_many_chars(num, asc_timestamp, 0, 4); num[4] = '\0';
tm.tm_year = 1900 - atoi(num);
octstr_get_many_chars(num, asc_timestamp, 4, 2); num[2] = '\0';
tm.tm_mon = atoi(num) - 1;
octstr_get_many_chars(num, asc_timestamp, 6, 2); num[2] = '\0';
tm.tm_mday = atoi(num);
octstr_get_many_chars(num, asc_timestamp, 8, 2); num[2] = '\0';
tm.tm_hour = atoi(num);
octstr_get_many_chars(num, asc_timestamp, 10, 2); num[2] = '\0';
tm.tm_min = atoi(num);
octstr_get_many_chars(num, asc_timestamp, 12, 2); num[2] = '\0';
tm.tm_sec = atoi(num);
t = timelocal(tm);
}
if ( t != (time_t)0 ) {
msg-sms.time = t;
}
msg-sms.time = time(NULL);
}
**For Sending messages I must use an HTTP GET:
**http://*.*.*.*/path/send.html?from_gsm=to_gsm=234567Bin=0msg=hallo%20again
**
**almost same as above, but:
**to_gsm without country/carrier code
**Bin: 0:text message, 1:binary data (actually I never send any binary SMS)
**
**Users authenticate on a IP and from_gsm combination.
**
4) Copy the function static void kannel_send_sms() to
static void my_kannel_send_sms().
5) Edit the function: static void my_kannel_send_sms()
5a) Change
url = octstr_format(%S?
username=%Epassword=%Eto=%Etext=%E,
conndata-send_url,
conndata-username, conndata-password,
sms-sms.receiver, sms-sms.msgdata);
to:
url = octstr_format(%S?
to_gsm=%Emsg=%E,
conndata-send_url,
sms-sms.receiver, sms-sms.msgdata);
In the if as well as the else clauses.
5b) Change
if (!conndata-no_sender)
Re: Stupid Q: where do incoming SMS go ?
**Date: Tue, 08 Feb 2005 08:17:51 +0100 **From: Linkas [EMAIL PROTECTED] **To: users@kannel.org **Subject: Stupid Q: where do incoming SMS go ? ** **I've never even tried to do it, so pardon me in advance. ** **If I do connect a phone with a cable to a pc with kannel on it and **ensure a serial communication, where do I receive messages ? ** **I use kannel to send, and I use to work on the db where DLR are stored. ** **Will the kannel act as an HTTP client to a URL I set where receives an **SMS ? Will the kannel store it somewhere in a db ? What you are referring to is Kannel using a Virtual SMSC. Virtual because Kannel is not talking directly to a real SMSC but through a GSM modem that communicates with the real SMSC of your operator. The GSM modem (i.e. the one in your phone) can be programmed with AT command (per 3GPP TS 27.07) to send and receive SMS. The SMS will be sent through the phone just as if you typed the message into your phone and hit the send button. Therefore, you will still need a real Mobile Network Operator that provides service to the SIM module your GSM modem uses. From now on, I will refer to your phone as the GSM modem. Now, when someone sends an Mobile Originated (MO) SMS to the phone number associated with the SIM in your GSM modem, your GSM modem will issue a +CMT: ... unsolicited notification to serial port connected to the PC. Since you have configured Kannel to listen on that serial port, Kannel will see that there's an incoming SMS via the +CMT: ... issued by your GSM modem. Kannel's bearerbox will issue an AT+CMGR... command to read the message from your GSM modem. The bearerbox will then forward the SMS to the smsbox for processing. Kannel's smsbox will receive the MO SMS and look through it's list of sms-service definitions to see how to handle the SMS. If you have sms-service's defined with 'keyword = ...' then the smsbox will extract out the first word of the SMS (actually everything up to the first Unicode 0x20 character) and see if it matches the keyword defined in your sms-service's. If the first word inside the SMS does not match any keywords defined in any of your sms-services, then the smsbox will use the sms-service defined with the keyword 'default'. In the sms-service, 3 behaviors that you might be interested in is 'get-url', 'post-url', and 'post-xml'. These three declarations allow you to access services outside of Kannel by issuing and HTTP_GET, HTTP_POST, and HTTP_POST of an xml document. If you wish to have all SMS messages forward to another system to process then the easiest sms-service definition would be: group = sms-service name = default_service keyword = default catch-all = true send-sender = true omit-empty = true post-url = http://another.host:port/some_url; The above definition will tell the smsbox to forward all SMS to the URL: http://another.host:port/some_url; as an HTTP_POST. Assuming that an MO SMS with an Origination address of: +39080123456 being sent to your phone number of: +39080456789 with the message content of This is an SMS message, you will receive the following HTTP_POST at the URL's endpoint: POST /some_url HTTP/1.1 Host: another.host:port User-Agent: Kannel/1.4.0 Content-Type: text/plain X-Kannel-From: +39080123456 X-Kannel-To: +39080456789 X-Kannel-Time: 2005-02-08 08:01:02 X-Kannel-Coding: 0 X-Kannel-Service: default_service Content-Length: 22 This is an SMS message If the program behind the http://another.host:port/some_url produces any output, then it will be sent back to the smsbox where Kannel will take the content, formulate an SMS and send it back to the originator of the SMS (+39080123456) as an Mobile Terminated (MT) SMS. If the program behind the http://another.host:port/some_url does not wish to produce any output, then the omit-empty = true statement will force Kannel not to generate any MT SMS as a response to the MO SMS from (+39080123456). Now, in addition to having Kannel automatically creating an MT SMS via the output from the program behind http://another.host:port/some_url, you can choose to send your own MT SMS. This would be done by making an HTTP_GET or HTTP_POST to Kannel's sendsms service. For more information about how to do that, consult the users@kannel.org mailing list archive. Search with the keywords HTTP_GET HTTP_POST. See ya... d.c.
Re: MO receiving troubles
**In-Reply-To: [EMAIL PROTECTED] **From: Sewa AGBODJAN delalom [EMAIL PROTECTED] **To: users@kannel.org **Subject: Re: MO receiving troubles **Date: Mon, 07 Feb 2005 13:17:10 + ** **Thanks for you reply Alejandro. **I did not fing in my logs section when the MO is receiving. I sent that **part because it was the only one talking about the receiver. **Below more log details. It could probably help, however as you have **mentioned it, I will try to see with the SMSC admin. ** **Sewa ** **2005-02-04 18:35:01 [3069] [10] DEBUG: send_msg: sending msg to box: **127.0.0.1 **2005-02-04 18:35:01 [3069] [10] DEBUG: boxc_sender: sent message to **127.0.0.1 **2005-02-04 18:35:01 [3069] [9] DEBUG: boxc_receiver: got ack **2005-02-04 18:35:01 [3069] [1] DEBUG: Dumping 0 messages and 0 acks to store **2005-02-04 18:35:19 [3069] [7] DEBUG: SMPP[mcel]: Sending enquire link: **2005-02-04 18:35:19 [3069] [7] DEBUG: SMPP PDU 0x812ca00 dump: **2005-02-04 18:35:19 [3069] [7] DEBUG: type_name: enquire_link **2005-02-04 18:35:19 [3069] [7] DEBUG: command_id: 21 = 0x0015 **2005-02-04 18:35:19 [3069] [7] DEBUG: command_status: 0 = 0x **2005-02-04 18:35:19 [3069] [7] DEBUG: sequence_number: 2 = 0x0002 **2005-02-04 18:35:19 [3069] [7] DEBUG: SMPP PDU dump ends. **2005-02-04 18:35:19 [3069] [7] DEBUG: SMPP[cafe]: Got PDU: **2005-02-04 18:35:19 [3069] [7] DEBUG: SMPP PDU 0x812ca00 dump: **2005-02-04 18:35:19 [3069] [7] DEBUG: type_name: enquire_link_resp **2005-02-04 18:35:19 [3069] [7] DEBUG: command_id: 2147483669 = 0x8015 **2005-02-04 18:35:19 [3069] [7] DEBUG: command_status: 0 = 0x **2005-02-04 18:35:19 [3069] [7] DEBUG: sequence_number: 2 = 0x0002 **2005-02-04 18:35:19 [3069] [7] DEBUG: SMPP PDU dump ends. **2005-02-04 18:35:31 [3069] [9] DEBUG: boxc_receiver: heartbeat with load **value 0 received **2005-02-04 18:35:49 [3069] [7] DEBUG: SMPP[mcel]: Sending enquire link: **2005-02-04 18:35:49 [3069] [7] DEBUG: SMPP PDU 0x812ca00 dump: **2005-02-04 18:35:49 [3069] [7] DEBUG: type_name: enquire_link **2005-02-04 18:35:49 [3069] [7] DEBUG: command_id: 21 = 0x0015 **2005-02-04 18:35:49 [3069] [7] DEBUG: command_status: 0 = 0x **2005-02-04 18:35:49 [3069] [7] DEBUG: sequence_number: 3 = 0x0003 **2005-02-04 18:35:49 [3069] [7] DEBUG: SMPP PDU dump ends. **2005-02-04 18:35:49 [3069] [7] DEBUG: SMPP[mcel]: Got PDU: **2005-02-04 18:35:49 [3069] [7] DEBUG: SMPP PDU 0x812ca00 dump: **2005-02-04 18:35:49 [3069] [7] DEBUG: type_name: enquire_link_resp **2005-02-04 18:35:49 [3069] [7] DEBUG: command_id: 2147483669 = 0x8015 **2005-02-04 18:35:49 [3069] [7] DEBUG: command_status: 0 = 0x **2005-02-04 18:35:49 [3069] [7] DEBUG: sequence_number: 3 = 0x0003 **2005-02-04 18:35:49 [3069] [7] DEBUG: SMPP PDU dump ends. **2005-02-04 18:36:19 [3069] [7] DEBUG: SMPP[mcel]: Sending enquire link: **2005-02-04 18:36:19 [3069] [7] DEBUG: SMPP PDU 0x812ca00 dump: **2005-02-04 18:36:19 [3069] [7] DEBUG: type_name: enquire_link **2005-02-04 18:36:19 [3069] [7] DEBUG: command_id: 21 = 0x0015 **2005-02-04 18:36:19 [3069] [7] DEBUG: command_status: 0 = 0x **2005-02-04 18:36:19 [3069] [7] DEBUG: sequence_number: 4 = 0x0004 **2005-02-04 18:36:19 [3069] [7] DEBUG: SMPP PDU dump ends. **2005-02-04 18:36:19 [3069] [7] DEBUG: SMPP[mcel]: Got PDU: **2005-02-04 18:36:19 [3069] [7] DEBUG: SMPP PDU 0x812ca00 dump: **2005-02-04 18:36:19 [3069] [7] DEBUG: type_name: enquire_link_resp **2005-02-04 18:36:19 [3069] [7] DEBUG: command_id: 2147483669 = 0x8015 **2005-02-04 18:36:19 [3069] [7] DEBUG: command_status: 0 = 0x **2005-02-04 18:36:19 [3069] [7] DEBUG: sequence_number: 4 = 0x0004 **2005-02-04 18:36:19 [3069] [7] DEBUG: SMPP PDU dump ends. **2005-02-04 18:36:49 [3069] [7] DEBUG: SMPP[mcel]: Sending enquire link: **2005-02-04 18:36:49 [3069] [7] DEBUG: SMPP PDU 0x812ca00 dump: **2005-02-04 18:36:49 [3069] [7] DEBUG: type_name: enquire_link **2005-02-04 18:36:49 [3069] [7] DEBUG: command_id: 21 = 0x0015 **2005-02-04 18:36:49 [3069] [7] DEBUG: command_status: 0 = 0x **2005-02-04 18:36:49 [3069] [7] DEBUG: sequence_number: 5 = 0x0005 **2005-02-04 18:36:49 [3069] [7] DEBUG: SMPP PDU dump ends. **2005-02-04 18:36:49 [3069] [7] DEBUG: SMPP[mcel]: Got PDU: **2005-02-04 18:36:49 [3069] [7] DEBUG: SMPP PDU 0x812ca00 dump: **2005-02-04 18:36:49 [3069] [7] DEBUG: type_name: enquire_link_resp **2005-02-04 18:36:49 [3069] [7] DEBUG: command_id: 2147483669 = 0x8015 **2005-02-04 18:36:49 [3069] [7] DEBUG: command_status: 0 = 0x **2005-02-04 18:36:49 [3069] [7] DEBUG: sequence_number: 5 = 0x0005 **2005-02-04 18:36:49 [3069] [7] DEBUG: SMPP PDU dump ends. **2005-02-04 18:37:19 [3069] [7] DEBUG: SMPP[mcel]: Sending enquire link: **2005-02-04 18:37:19 [3069] [7] DEBUG: SMPP PDU 0x812ca00 dump: **2005-02-04 18:37:19 [3069] [7] DEBUG: type_name: enquire_link **2005-02-04 18:37:19 [3069] [7]
Re: SQL Box Table docs
**Date: Mon, 7 Feb 2005 04:12:12 +0100 **From: Alejandro Guerrieri [EMAIL PROTECTED] **To: users@kannel.org users@kannel.org **Subject: SQL Box Table docs **Reply-To: Alejandro Guerrieri [EMAIL PROTECTED] ** **Hi all, ** **I'm starting to try out SQLBOX on Kannel. I've already applied the **latest patch to 1.4.0 and compiled flawlessly. After a few fixes here **and there on my start scripts, I've managed to make it work and even **sent messages inserting on the send_sms table. ** **My question is: Since there is so little documentation around (apart **from a FAQ being attached on many mails on mail-archive I didn't found **anything), where could I get some documentation about the tables **structure. ** **What I've already did was something like this: ** **$query = INSERT INTO send_sms ( . ** momt, sender, receiver, udhdata, msgdata, . ** time, smsc_id, service, account, id, . ** sms_type, mclass, mwi, coding, compress, . ** validity, deferred, dlr_mask, dlr_url, . ** pid, alt_dcs, rpi, charset, boxc_id, binfo . ** ) VALUES ( . ** 'mt', '1234', '12345678', '', 'this+is+a+test', . ** NOW(), 'mysmsc', 'myservice', NULL, NULL, . ** NULL, NULL, NULL, NULL, NULL, . ** NULL, NULL, NULL, NULL, . ** NULL, NULL, NULL, NULL, NULL, NULL . ** ); ** **So there are a lot of NULLS (sort of I don't know what to put there ;) ). ** **I would _love_ to know what all those fields means, which ones could I **ignore, which ones are mandatory and maybe a few examples of simple **inserts! ** **Thank you in advance, I haven't used sqlbox yet nor looked at the source code. But, I can guess what each column might be in the table. It looks similar to the Msg structure that is passed between the bearerbox and the smsbox. As such: momt: Description: Indicates whether the SMS is a Mobile Originated (from mobile user to an sms-service) or Mobile Terminated (from your application to the mobile user). Supported Values: 'mt', 'mo' Kannel SMS Msg structure equivalent: Not Applicable (specific to the sqlbox) sender: Description: The origination address. Supported Values: Any alphanumeric value. Kannel SMS Msg structure equivalent: sms.sender receiver: Description: The destination address. Supported Values: Any alphanumeric value. Kannel SMS Msg structure equivalent: sms.receiver udhdata: Description: The User Data Header that will be prefixed to the SMS message content. Supported Values: Hexadecimal values Kannel SMS Msg structure equivalent: sms.udhdata msgdata: Description: The SMS message payload Supported Values: 140 8-bit values. If a UDH is also specified for the SMS, then the maximum length of the msgdata is 140-length(udhdata). Kannel SMS Msg structure equivalent: sms.msgdata time: Description: The GMT time when the SMS was placed into the sqlbox. This value represents the number of seconds since the UNIX EPOCH (Jan 1, 1970). Supported Values: Any decimal value. Kannel SMS Msg structure equivalent: sms.time smsc_id: Description: The SMSC ID that should or did handle the SMS. Supported Values: Any alphanumeric value. Kannel SMS Msg structure equivalent: sms.smsc_id service: Description: The sms-service name that was executed on behave of the SMS. Supported Values: Any alphanumeric value. Kannel SMS Msg structure equivalent: sms.service account: Description: The auxiliary account name or number associated with the SMS (mustly seen in HTTP relays). Supported Values: Any alphanumeric value. Kannel SMS Msg structure equivalent: sms.account id: Description: The unique ID assigned to each SMS handled by the Kannel system. Supported Values: Format is: ---- - time_low - time_mid - time_hi_and_version - clock_sequence - node_id (usually interface ethernet address that this SMS was received from) Kannel SMS Msg structure equivalent: sms.id sms_type: Description: The Kannel type of the SMS (MO or DLR) Supported Values: 0 = MO (coming from the operator on behave of a mobile user) 1 = MT_REPLY (coming from an sms-service) 2 = MT_PUSH (coming from an application external from Kannel) 3 = REPORT_MO (DLR from the operator) 4 = REPORT_MT (DLR from Kannel to the operator) Kannel SMS Msg structure equivalent: sms.sms_type mclass: Description: The Message Class of the SMS as defined in the Data Coding Scheme (DCS) Field. Supported Values: 0 = sends the message directly to display. 1 = sends to mobile 2 = sends to SIM 3 = sends to SIM Toolkit. Kannel SMS Msg structure equivalent: sms.mclass mwi: Description: The Message Wait Indicate of the SMS as defined in the DCS field.
Re: smpp DLR problem
**Date: Tue, 1 Feb 2005 16:57:11 +0100 (CET) **Subject: Re: smpp DLR problem **From: [EMAIL PROTECTED] **To: users@kannel.org **In-Reply-To: [EMAIL PROTECTED] ** **Hello Dave, ** **thanks for your answer, ** **Here is a dump of the smpp transactions, hopefully this will shed some **more light on what's going wrong ; **I'm wondering, maybe kannel does not find the right DLR because the DLR **for the message sent via smsc is returned to kannel via smsc-rec **.? **Thx, That is exactly the reason. Kannel's dlr_find() function uses the smsc-id, timestamp (message-id in the case of SMPP), destination address, and interested DLR type to query for info from the dlr_entry structure. Since the smsc-id's are different, Kannel could not find the dlr_entry. See ya... d.c.
Re: MO receiving problem
**Date: Wed, 02 Feb 2005 09:11:26 -0400 **From: Pieter Natte [EMAIL PROTECTED] **To: users users@kannel.org **Subject: MO receiving problem ** **Dear list, ** **we just upgraded to Kannel 1.4 from 1.2. Although the compilation and **installation on Redhat 8 went smoothly we are encountering a problem **with receiving MO SMS messages. For one or another reason the new **version refuses to receive the incoming messages. Using the same **configuration file with both versions 1.2 is working fine but 1.4 is **not. Binding to transmitter and receiver and sending messages is no **problem. ** **What can be wrong? What may I have to add or change in the config file? **I added already the smsbox-id and sms-route group to the 1.4 config but **that did not solve the problem. Below snippets from the config file and **the log file. ** **Any help and/or suggestion is welcome. ** **Pieter Natte ** **CONFIG FILE ** **group = core **admin-port = 13000 **smsbox-port = 13001 **admin-password = xx **status-password = x **admin-allow-ip = 127.0.0.1 **log-file = /usr/local/smsgateway-1.4.0/logs/kannel.log **log-level = 0 **box-deny-ip = *.*.*.* **box-allow-ip = xx.xx.xx.xx **unified-prefix = 1 **access-log = /usr/local/smsgateway-1.4.0/logs/access.log **store-file = /usr/local/smsgateway-1.4.0/logs/kannel.store ** **# SMSC CONNECTIONS ** **# Prime account connect for receiving messages **group = smsc **smsc = smpp **smsc-id = kpn-nl **host = nlp.netsizeonline.com **port = xxx **receive-port = x **smsc-username = xxx **smsc-password = xxx **system-type = **keepalive = 5 **address-range = **enquire-link-interval=290 **allowed-smsc-id = kpn-nl **msg-id-type = 0x01 ** ** **# SMSBOX SETUP ** **group = smsbox **smsbox-id = mobile-sms **bearerbox-host = localhost **sendsms-port = 13013 **sendsms-chars = 0123456789 +- **log-file = /usr/local/smsgateway-1.4.0/logs/smsbox.log **log-level = 0 **access-log = /usr/local/smsgateway-1.4.0/logs/sms_access.log ** **# SMS ROUTING **group = smsbox-route **smsbox-id = mobile-sms **smsc-ids = kpn-nl ** **# SERVICES ** **# there should be default always **# Home-XS is defined as the default service **group = sms-service **keyword = default **post-url = **http://xx.com/xxl/x/Handler?from=%pto=%Pskey=%ktext=%rsmscid=%ismscid_time=%tservice=%ncode=%c; **max-messages = 0 **name = Home-XS **accepted-smsc = kpn-nl;dt-nl;ben-nl;telfort-nl;lib-nl ** **# SEND-SMS USERS ** **group = sendsms-user **username = Home-XS **password = x **max-messages = 1 ** ** **LOG FILE ** **2005-02-01 14:59:57 [12983] [9] DEBUG: SMPP[kpn-nl]: Got PDU: **2005-02-01 14:59:57 [12983] [9] DEBUG: SMPP PDU 0x819b1e0 dump: **2005-02-01 14:59:57 [12983] [9] DEBUG: type_name: deliver_sm **2005-02-01 14:59:57 [12983] [9] DEBUG: command_id: 5 = 0x0005 **2005-02-01 14:59:57 [12983] [9] DEBUG: command_status: 0 = 0x **2005-02-01 14:59:57 [12983] [9] DEBUG: sequence_number: 2 = 0x0002 **2005-02-01 14:59:57 [12983] [9] DEBUG: service_type: 20408 **2005-02-01 14:59:57 [12983] [9] DEBUG: source_addr_ton: 2 = 0x0002 **2005-02-01 14:59:57 [12983] [9] DEBUG: source_addr_npi: 3 = 0x0003 **2005-02-01 14:59:57 [12983] [9] DEBUG: source_addr: +31622660160 **2005-02-01 14:59:57 [12983] [9] DEBUG: dest_addr_ton: 2 = 0x0002 **2005-02-01 14:59:57 [12983] [9] DEBUG: dest_addr_npi: 3 = 0x0003 **2005-02-01 14:59:57 [12983] [9] DEBUG: destination_addr: 4010 **2005-02-01 14:59:57 [12983] [9] DEBUG: esm_class: 0 = 0x **2005-02-01 14:59:57 [12983] [9] DEBUG: protocol_id: 0 = 0x **2005-02-01 14:59:57 [12983] [9] DEBUG: priority_flag: 1 = 0x0001 **2005-02-01 14:59:57 [12983] [9] DEBUG: schedule_delivery_time: NULL **2005-02-01 14:59:57 [12983] [9] DEBUG: validity_period: NULL **2005-02-01 14:59:57 [12983] [9] DEBUG: registered_delivery: 0 = 0x **2005-02-01 14:59:57 [12983] [9] DEBUG: replace_if_present_flag: 0 = **0x **2005-02-01 14:59:57 [12983] [9] DEBUG: data_coding: 242 = 0x00f2 **2005-02-01 14:59:57 [12983] [9] DEBUG: sm_default_msg_id: 0 = 0x **2005-02-01 14:59:57 [12983] [9] DEBUG: sm_length: 3 = 0x0003 **2005-02-01 14:59:57 [12983] [9] DEBUG: short_message: XS5 **2005-02-01 14:59:57 [12983] [9] DEBUG: SMPP PDU dump ends. **2005-02-01 14:59:57 [12983] [9] DEBUG: SMPP[kpn-nl]: Sending PDU: **2005-02-01 14:59:57 [12983] [9] DEBUG: SMPP PDU 0x819aef8 dump: **2005-02-01 14:59:57 [12983] [9] DEBUG: type_name: deliver_sm_resp **2005-02-01 14:59:57 [12983] [9] DEBUG: command_id: 2147483653 = 0x8005 **2005-02-01 14:59:57 [12983] [9] DEBUG: command_status: 10 = **0x000a (This value is 0x000 in 1.2) **2005-02-01 14:59:57 [12983] [9] DEBUG: sequence_number: 2 = 0x0002 **2005-02-01 14:59:57 [12983] [9] DEBUG: message_id: NULL **2005-02-01 14:59:57 [12983] [9] DEBUG: SMPP PDU dump ends. The SMSC is returning
Re: wavecom fastrack gsm modem
**From: noorhafizah [EMAIL PROTECTED] **To: users@kannel.org **Subject: wavecom fastrack gsm modem **Date: Tue, 1 Feb 2005 09:22:55 +0800 ** **Hi, **Does anybody know whether kannel supports wavecom fastrack GSM modem or not. If you mean can the Wavecom GSM modems be used as a virtual SMSC to send and receive SMS, then the answer is yes. See ya... d.c.
Re: smpp DLR problem
**Date: Tue, 1 Feb 2005 14:42:47 +0100 (CET) **Subject: smpp DLR problem **From: [EMAIL PROTECTED] **To: users@kannel.org ** **i have this weird problem with DLR reports and SMPP that is breaking my **head. DLR reporting seems to work fine for the other EMI connections but **the SMPP connection however gives **WARNING: DLR[internal]: DLR for DST32 not found. **2005-02-01 13:51:16 [15102] [7] ERROR: SMPP[smsc-rec]: got DLR but could **not find message or was not interestedin it ts1167675259 **dst32, type1 **after calling ** **links **http://localhost:20003/cgi-bin/sendsms?user=testerpassword=lalaato=32Xfrom=32text=Hello+worldsmsc=smscdlr-mask=31 **in the debuglogs. I've tried setting the msg-id-type to all possible **values but without any difference... **I've got following stuff for the smpp connection in my kannel config ** **group = smsc **smsc = smpp **smsc-id = smsc-rec **host = A.B.C.D **port = 0 **receive-port = 8100 **interface-version = 34 **smsc-username = USER **smsc-password = PASSWD **system-type = OK **address-range = **source-addr-autodetect = false **source-addr-ton = 0 **source-addr-npi = 8 **dest-addr-ton = 0 **dest-addr-npi = 8 **msg-id-type = 0x00 **my-number = ** **group = smsc **smsc = smpp **smsc-id = smsc **host = A.B.C.E **port = 8100 **receive-port = 0 **interface-version = 34 **smsc-username = USER **smsc-password = PASSWD **system-type = OK **address-range = **source-addr-autodetect = false **source-addr-ton = 0 **source-addr-npi = 8 **dest-addr-ton = 0 **dest-addr-npi = 8 **msg-id-type = 0x00 **my-number = ** **Any advice on what i could try greatly appreciated, It would be very useful to get a debug level logfile of your bearerbox interactions with the SMPP server. In particular, the things of most interest: - Any logs pertaining to the DLR being added to the dlr_entry - The decoded SMPP PDU of your submit_sm_resp and deliver_sm. - Any log entry indicating Kannel received a DLR but was not interested in it. Based off of the limited debug log you presented, it indicates it me that your message-id types are mismatching. Most likely the submit_sm_resp was sending a hexadecimal representation of the mesage-id '1167675259' (which in the submit_sm_resp would look like '45994F7B'). Again, a dump of the logs from your bearerbox would be most helpful. See ya... d.c.
Re: Application Port Addressing?
**Subject: Re: Application Port Addressing? **From: Enver ALTIN [EMAIL PROTECTED] **To: users@kannel.org **In-Reply-To: [EMAIL PROTECTED] **Date: Thu, 27 Jan 2005 21:32:52 +0200 ** **On Thu, 2005-01-27 at 19:17 +0800, Davy Chan wrote: ** Sorry, not possible. You can only use the X-Kannel-UDH ** HTTP Optional header (and it's corresponding cgi parameter udh=) ** for HTTP-based services (get-url or post-url). sms-service's exec= ** parameter only returns the output from the specified program's ** execution and dumps it directly into the SMS. The smsbox does not ** evaluate the content in any way. Therefore, there's no way to ** inform the smsbox it needs to include extra content (like the ** UDH) into the SMS. ** **Maybe making the script work via Apache as a CGI script would make this **possible. Just my $0.02 :) Yes, I agree. The easiest way would be to change his configuration to use a get-url or post-url. But, in the context of 'exec=', it cannot be done. The question now is whether it is convenient for the original poster can setup and maintain an HTTP server (it doesn't necessarily have to be a full-blown Apache or IIS server) to accomodate his needs. As a matter of fact, this can easily be implemented with a simple shell script wrapper around his exec'ed program being started from inetd. See ya... d.c.
Re: [Kannel-Users] Re: SMS message ids
Answers inline... **Date: Thu, 27 Jan 2005 12:20:22 -0500 (EST) **From: Peter Beckman [EMAIL PROTECTED] **To: Davy Chan [EMAIL PROTECTED] **cc: users@kannel.org **Subject: Re: [Kannel-Users] Re: SMS message ids **In-Reply-To: [EMAIL PROTECTED] ** **On Thu, 27 Jan 2005, Davy Chan wrote: ** 2005-01-26 09:02:43 [394] [7] DEBUG: SMPP[wsc_wireless_services]: Got PDU: 2005-01-26 09:02:43 [394] [7] DEBUG: SMPP PDU 0x81a00a0 dump: 2005-01-26 09:02:43 [394] [7] DEBUG: type_name: submit_sm_resp 2005-01-26 09:02:43 [394] [7] DEBUG: command_id: 2147483652 = 0x8004 2005-01-26 09:02:43 [394] [7] DEBUG: command_status: 0 = 0x 2005-01-26 09:02:43 [394] [7] DEBUG: sequence_number: 1154 = 0x0482 2005-01-26 09:02:43 [394] [7] DEBUG: message_id: F39E35D I was hoping that Kannel 1.4.0 would send me the message_id value when I used the escape code %I, however I'm seeing this instead. /notification?smsc-id=wsc_wireless_servicessmsid=da03662a-731a-4e22 -8a18 -2d982663eb4fmsg=ACK%2Fstatus=8answer=ACK%2Fto=55416from=4252837796 time=2005-01-26+17:02:43 What is da03662a-731a-4e22-8a18-2d982663eb4f from? I can't find it anywhere in bearerbox.log. Is there a way to get Kannel to send me the message_id value of F39E35D? ** **Kannel's dlr-url will only return the message-id embedded in the **deliver_sm, not from the submit_sm_resp. Kannel's bearerbox will **use the message-id from the submit_sm_resp to generate and entry **in its own dlr-url lookup table. But, again, this information is **not forwarded to you via the dlr-url. ** ** That's the question. Why, if the in submit_sm_resp does the message_id ** come over in, does the generated URL by kannel for the dlr report (type=8 ** is generated by kannel, NOT the SMSC) not include the message_id, passed ** exactly how the SMSC passed it? Let the user handle the conversion from ** hex to decimal, or a string or whatnot. Why does kannel not pass it then ** if it stores it in the DLR db? I've explained this in another email to the list, but, just in case a search on this topic does not return my other email... The message-id retrieved from a submit_sm_resp is on available to the bearerbox. Once the information is persisted into storage (be it SQL database or bearerbox memory store) it is thrown away and not passed to the smsbox. Since the smsbox does not have the message-id, it cannot put the information into an HTTP_GET generated from the dlr-url parameter. **Therefore, if your SMPP operator is not returning the message-id **in the short_message part of the deliver_sm (i.e. message body **of a regular SMS...I call it the old embedded method), then the **information must be conveyed through the Tag-Length-Value (TLV) **optional parameters (specifically TLV 0x001E [receipted_message_id]). ** ** This problem has NOTHING to do with the SMPP operator. Kannel in version ** 1.3.2 and later calls the DLR URL with type=8 when the SMPP operator ** accepts (ACK/'s) the message. KANNEL generates the above message, not the ** SMPP operator. Sorry...myoptic vision made me focus only on the message-id stuff. I overlooked the fact that the poster was talking about the value returned via an '%I' parameter. The '%I' (as of v1.3.2) returns the sms.id Kannel assigns to the SMS. This entity is derived from the following information: 32-bit time_low 16-bit time_mid 16-bit time_hi_and_version 16-bit clock_sequence 8-bit node [hashed from ethernet address] The '%I' escape code just prints out a human-digestible form it the UUID. ** **If you can also post to the list the deliver_sm decoding, then **we can get a better idea what happened. It appears to me that **your provider might be generating non-standard DLRs (hence the **message-id of da03662a-731a-4e22-8a18-2d982663eb4f). ** ** I don't know where that message ID comes from... I assume it is kannel's ** primary key for the store table (internal storage I assume, since the ** primary key would be an int). Or it could be an MD5 hash of something. ** Whatever it is, it seems to be useless. ** ** I, too, would find getting the remote SMSC message ID in the ** kannel-generated DLR report at submit_sm_resp success very useful and ** handy, since not all SMSC's and carriers in the US do further delivery ** receipts, unlike Europe. Working on it... **Beckman **--- **Peter Beckman Internet Guy **[EMAIL PROTECTED] http://www.purplecow.com/ **--- See ya... d.c.
Re: Application Port Addressing?
**Date: Thu, 27 Jan 2005 08:27:46 +0300 **From: Roman [EMAIL PROTECTED] **To: users@kannel.org **Subject: Application Port Addressing? ** **How can I set Application Port Addressing parameter in SMS message with **kannel? I'm about 9.2.3.24.4 in GSM 3.40. **Is it possible? Application Port Addressing is encoded into the User Defined Headers (UDH) part of an SMS. Kannel does not have the capability to generate a UDH with a user-defined application port address. But, you can still use Kannel to send SMS with UDH that were hand-coded by you. Create the UDH and then use the cgi parameter udh=... or the HTTP optional header parameter X-Kannel-UDH when communicating with Kannel's smsbox. For example, you want this SMS to be sent to the 16bit application port 1581 and you want the source port to be 3456. Your UDH would look like -- 06050415813456. This decodes to: 06 - SMSC control Parameter 05 - Application port addressing scheme, 16 bit address 04 - Length (in bytes) of the source and destination addresses 1581 - Destination port (in network byte order) 3456 - Originator port (in network byte order) Then, your communication with the smsbox would look like: HTTP_GET: GET /cgi-bin/sendsms?username=foopassword=barto=some_phone_numudh=06050415813456text=hello HTTP/1.0 HTTP_POST: POST /cgi-bin/sendsms HTTP/1.0 X-Kannel-Username: foo X-Kannel-Password: bar X-Kannel-To: some_phone_num X-Kannel-UDH: 06050415813456 Content-Type: text/plain Content-Length: 5 hello See ya... d.c.
Re: Application Port Addressing?
**Date: Thu, 27 Jan 2005 13:31:52 +0300 **From: Roman [EMAIL PROTECTED] **To: Davy Chan [EMAIL PROTECTED] **CC: users@kannel.org **Subject: Re[2]: Application Port Addressing? **In-Reply-To: [EMAIL PROTECTED] ** [ ... lines deleted ... ] ** **Thank You for quick and detailed answer. **Now I use exec= statement to process SMS requests, **but in exec= I can't use X-Kannel headers. **Is it possible to send UDH with exec= statement? Sorry, not possible. You can only use the X-Kannel-UDH HTTP Optional header (and it's corresponding cgi parameter udh=) for HTTP-based services (get-url or post-url). sms-service's exec= parameter only returns the output from the specified program's execution and dumps it directly into the SMS. The smsbox does not evaluate the content in any way. Therefore, there's no way to inform the smsbox it needs to include extra content (like the UDH) into the SMS. See ya... d.c.
Re: different shortcodes possible ?
**Date: Wed, 26 Jan 2005 12:33:03 +0100 (CET) **Subject: different shortcodes possible ? **From: [EMAIL PROTECTED] **To: users@kannel.org ** **Hello all, ** ** **We have a working kannel configuration for several smsc's with several **services for a number of keywords. This all works on an active shortcode **(4 digit). I was wondering how i could best implement another shortcode **into this existing configuration. The problem is that some defined **keywords (like NEW or LIST) are already in use for one shortcode. So how **do you make it clear to kannel that he has to act different for keyword **NEW according to the shortcode the sms was sent to ?What's the best way to have several different shortcodes in one kannel **config ...? **Any advice greatly appreciated, Limit access to the sms-service by specifying the allowed receiving numbers/short-codes using the allowed-receiver-prefix parameter. For example: ### Service: Return General Tech News group = sms-service keyword = NEW allowed-receiver-prefix = 8324 file = new_tech_news ### Service: Return General Sports News group = sms-service keyword = NEW allowed-receiver-prefix = 77678 file = new_sport_news If an MO SMS comes in with the content NEW and was sent to the short code 8324 then and MT SMS will be sent by Kannel with the contents of the file new_tech_news. If the MO SMS was sent to the short code 77678, then the contents of the file new_sport_news will be sent. You can even get trickier with the definitions and specify only different services based on the origination address via an allowed-prefix list: ### Service: Return Sports News for Ohio (prefix 1216 and 1614) group = sms-service keyword = NEW allowed-prefix = 1216;1614 allowed-receiver-prefix = 77678 file = new_OH_sport_news ### Service: Return Sports News for California (prefix 1415 and 1605) group = sms-service keyword = NEW allowed-prefix = 1415;1605 allowed-receiver-prefix = 77678 file = new_CA_sport_news ### Service: Return General Sports News group = sms-service keyword = NEW allowed-receiver-prefix = 77678 file = new_sport_news ### Service: Return General Tech News group = sms-service keyword = NEW allowed-receiver-prefix = 8324 file = new_tech_news The only problem with this technique is that you need to restart the smsbox everytime you add another shortcode or service definition. I would suggest you put the logic into your backend system and have it parse the SMS for the Destination Address (short-code), Origination Address (sender's phonenumber) and SMS content. Just setup a default sms-service and make it do a post-url to your backend (and don't forget to set the send-sender parameter to true). You can then have Kannel just routing SMS for you. See ya... d.c.
Re: SMS message ids
**To: users@kannel.org **From: Matthew Hixson [EMAIL PROTECTED] **Subject: SMS message ids **Date: Wed, 26 Jan 2005 09:11:42 -0800 ** **In bearerbox.log I see this: ** **SMPP PDU 0x81a00a0 dump: [ ... lines deleted ... ] **2005-01-26 09:02:43 [394] [7] DEBUG: SMPP[wsc_wireless_services]: Got **PDU: **2005-01-26 09:02:43 [394] [7] DEBUG: SMPP PDU 0x81a00a0 dump: **2005-01-26 09:02:43 [394] [7] DEBUG: type_name: submit_sm_resp **2005-01-26 09:02:43 [394] [7] DEBUG: command_id: 2147483652 = **0x8004 **2005-01-26 09:02:43 [394] [7] DEBUG: command_status: 0 = 0x **2005-01-26 09:02:43 [394] [7] DEBUG: sequence_number: 1154 = **0x0482 **2005-01-26 09:02:43 [394] [7] DEBUG: message_id: F39E35D ** **I was hoping that Kannel 1.4.0 would send me the message_id value when **I used the escape code %I, however I'm seeing this instead. ** **/notification?smsc-id=wsc_wireless_servicessmsid=da03662a-731a-4e22 **-8a18 **-2d982663eb4fmsg=ACK%2Fstatus=8answer=ACK%2Fto=55416from=4252837796 **time=2005-01-26+17:02:43 ** **What is da03662a-731a-4e22-8a18-2d982663eb4f from? I can't find it **anywhere in bearerbox.log. ** Is there a way to get Kannel to send me the message_id value of **F39E35D? Kannel's dlr-url will only return the message-id embedded in the deliver_sm, not from the submit_sm_resp. Kannel's bearerbox will use the message-id from the submit_sm_resp to generate and entry in its own dlr-url lookup table. But, again, this information is not forwarded to you via the dlr-url. The dlr-url is activated when the DLR comes from the operator via a deliver_sm. Then, and only then, will Kannel make the HTTP_GET to your URL specified in the dlr-url. Therefore, if your SMPP operator is not returning the message-id in the short_message part of the deliver_sm (i.e. message body of a regular SMS...I call it the old embedded method), then the information must be conveyed through the Tag-Length-Value (TLV) optional parameters (specifically TLV 0x001E [receipted_message_id]). Kannel examines the deliver_sm and first looks for the message-id via a TLV and then tries to scan the message body for the old embedded method. Kannel handles the old embedded method by scanning the message body for the ascii keyword id: and assumes the message-id is after that keyword. If you operator is not using TLV and their message body has somethings else with an id: in it, then Kannel will get and incorrect message-id parse. If you can also post to the list the deliver_sm decoding, then we can get a better idea what happened. It appears to me that your provider might be generating non-standard DLRs (hence the message-id of da03662a-731a-4e22-8a18-2d982663eb4f). See ya... d.c.
Re: receiving notifications from Kannel
**From: Matthew Hixson [EMAIL PROTECTED] **Subject: Re: receiving notifications from Kannel **Date: Mon, 24 Jan 2005 23:47:44 -0800 **To: users@kannel.org ** [ ... lines deleted ... ] ** **Thanks for the reply, Davy. Here is what I've tried by telnetting **directly to Kannel: ** **GET **/cgi-bin/sendsms?username=foopassword=barto=phonenumbertext=test **HTTP/1.1 **Host: hostname.com **X-Kannel-DLR-Url: http://my.dev.machine/foo **X-Kannel-DLR-Mask: 31 ** **Kannel replies with: ** **HTTP/1.1 202 Foo **Server: Kannel/1.3.1 **Content-Length: 5 **Content-type: text/html **Pragma: no-cache **Cache-Control: no-cache ** **Sent. ** **And it does not send a request to my machine. Is there something else **I need to be doing? Is there some setting in a Kannel config file that **needs to be tweaked to allow the notifications to be sent? HTTP_GET's and HTTP_POST's use different mechanisms activate the DLR notification system. You are mixing both. If you are issuing an HTTP_GET request, then you need to submit the information in the cgi parameters like this: GET /cgi-bin/sendsms?username=foopassword=barto=phonenumbertest=testdlr-url=http://host:port/notificatio-url%3Foa=%pamp;da=%Pamp;smsc=%iamp;dlr-type=%ddlr-mask=31 The value of the dlr-url passed via an HTTP_GET must be URL-Encoded. If you are issuing an HTTP_POST request, then you need to submit the information as part of the HTTP optional headers: POST /cgi-bin/sendsms HTTP/1.0 X-Kannel-Username: foo X-Kannel-Password: bar X-Kannel-To: phonenumber X-Kannel-DLR-URL: http://host:port/notification?oa=%pda=%Psmsc=%idlr-type=%d X-Kannel-DLR-Mask: 31 Content-Type: text/plain Content-Length: 4 test For and HTTP_POST request, the dlr-url does not need to be URL-Encoded. Don't mixup the HTTP optional headers and cgi parameters. Their usage are not interchangeable. This point is not very clear in the userguide. I'll add that to my TODO list of updates to the docs. See ya... d.c.
Re: Receiving SMS
**From: Simon Yip [EMAIL PROTECTED] **To: users@kannel.org **Subject: Receiving SMS **Date: Tue, 25 Jan 2005 17:02:24 +0800 ** **Does Kannel read the sms received by mobile and store to log or access file? If your group = core section has an access-log = logfile_name then the bearerbox will record the received SMS...that were successfully routed to an smsbox or out another SMSC. Please note the last part of my previous statement. Another caveat is that the message will be represented in the logfile differently based on the Encoding of the SMS. For example, if the message was using GSM7 (default encoding), then the SMS will be rendered as straight ASCII. This means if there's a linefeed character in the SMS (Unicode 0x10), then the linefeed will also appear in the logfile. Therefore, you should not parse the logfile on a line-by-line basis. If the SMS is in UCS-2 (Coding=2 in v1.3.2 and above), then the message will be rendered as the hexadecimal values of the message: 2005-01-25 17:44:53 Receive SMS ... [msg:4:4E2D6587] ... **Is Kannel able to delete sms stored in mobile (sim or memory) ? **I'm using Ericsson T39. If your group = smsc section detailing your smsc = at, you have sim-buffering = true, then the bearerbox will check SIM memory for SMS messages as well as expecting the SMS via an unsolicited notification (i.e., AT+CPMS will be used as well as expecting +CMT for SMS reception notification). See ya... d.c.
Re: Receiving SMS
**From: Simon Yip [EMAIL PROTECTED] **To: users@kannel.org **Subject: Receiving SMS **Date: Wed, 26 Jan 2005 10:58:28 +0800 ** **I'm still testing it but I have got this error on core group log file ** **2005-01-26 10:52:39 [16465] [6] ERROR: AT2[t39]: got +CMT but pdu_extract **failed ** **Is it about the received message ? Yes, the +CMT is the unsolicited notification coming from your mobile device. This is how the GSM modem will tell Kannel's bearerbox that it has received an MT SMS. To find out why the pdu_extract failed, you would need to look at the bearerbox logs with loglevel set to 0. Then, look at the dialog betwen the bearerbox and the GSM modem. Kannel expects the +CMT: stuff to be in a specific format and byte sequence. If it is not then the at2_pdu_extract() function will fail you get you the message you see in the log. Also, timing matters as well, the current version only tolerates a 1 second delay between receiving the +CMT:... message and receiving the hexadecimal encoded PDU. at2_pdu_extract() looks for the following for a +CMT: - +CMT: within the received byte stream - If broken is not true, then expect to see a ,size_of_SMS. BTW, the broken boolean declaration in the modem group does not seem to be documented in the current CVS userguide. I'll add that to my updates of the userguide. - After the size_of_SMS, should be whitespace (that includes the LF) that is skipped over. - If no_smsc is set to false (the default), then the first two characters of the PDU will be the length of the SMSC's phone number. The phone number of the SMSC will follow after the length indication. - The encoded SMS as represented in hexadecimal follows the SMSC information in the PDU. If you notice that the +CMT:... does not provide you with the length of the SMS, then you might want to set the broken = true parameter for your group = modems secton. If you know that your modem does not set the SMSC phone number in the PDU, then you should try no_smsc = true for your group = modems section. If none of it works, then try submitting your bearerbox logs to the mailing list. See ya... d.c.
Re: receiving notifications from Kannel
**To: users@kannel.org **From: Matthew Hixson [EMAIL PROTECTED] **Subject: receiving notifications from Kannel **Date: Mon, 24 Jan 2005 18:35:17 -0800 ** **We are currently using Kannel 1.3.1. Our sysadmins say they are unable **to get Kannel to send a notification to a URL that we supply. Is this **functionality supposed to be working in 1.3.1? I see in the current **documentation for 1.4.0 that I should be able to set an HTTP header on **the request sent to Kannel, X-Kannel-DLR-Url, but this doesn't seem to **cause a notification to be returned to the URL I've specified. Do I **need to upgrade to 1.4.0? You only receive notifications if you set the DLR mask as well as the DLR URL. Therefore, in your case, you will need to also set the the DLR mask via the HTTP Optional Header: X-Kannel-DLR-Mask The DLR mask represents the type of DLR notifications you want: 1: Delivery Successful The SMS was sent from the SMSC to the mobile device and the mobile device has acknowledged receipt of the SMS. 2: Delivery Failed The SMS was not received by the mobile device. Some possible causes are: mobile device refused acceptance because it's SMS memory capacity is full or SMS expired before the SMS could be sent to the mobile device. 4: Message Buffered The SMS has been queued onto the SMSC's buffer and will be delivered as soon as the SMSC can contact the mobile phone. 8: SMSC Submitted The SMS was submitted to the SMSC and was accepted for delivery. The SMSC now takes responsibility for sending the SMS to the proper destination. 16: SMSC Rejected The SMS was rejected by the SMSC for delivery. Possible causes of the rejection might be the queue for the mobile device might be full, the Origination Address (OA) could not be used with the SMSC, etc. If you want multiple report types, you simply add the values together. For example, if you want to get delivery success and/or failure you set the dlr-mask value of 3 (1+2). If you specify dlr-mask on the URL you pass on to Kannel, you also need to specify dlr-url. dlr-url should contain the URL to which Kannel should place an HTTP_GET requests once the delivery report is ready to be delivered back to your system. For more information, try searching the users@kannel.org mailing list with the following search terms: dlr-url dlr-mask davy chan See ya... d.c.
Re: Is it possible to set up the esm_class for Kannel?
The oldest code on my systems v1.3.1. It already had the support for setting esm_class for SMPP if udh/rpi was set in the MT SMS sent to the bearerbox. See ya... d.c. **Subject: RE: Is it possible to set up the esm_class for Kannel? **Date: Fri, 7 Jan 2005 11:29:47 -0800 **From: Olga Rudchenko [EMAIL PROTECTED] **To: devel@kannel.org ** **BTW. Can you tell me please the lower version of Kannel which work in **this way? ** **-Original Message- Subject: RE: Is it possible to set up the esm_class for Kannel? Date: Fri, 7 Jan 2005 07:54:34 -0800 From: Olga Rudchenko [EMAIL PROTECTED] To: devel@kannel.org Hi, Thanks so much for help! I am really stick with this problem. We already use Kannel but would like to expand the list of devices **which **we use. They are going to be the J2ME phones. In this case I **need to **send SMS with UDH and set up the esm_class to 0x40. If you **know any **other tuning which I should to do in this case, let me know **please. ** **Actually, setting a UDH in an SMS (via cgi parameter udh= for **HTTP_GET, or X-Kannel-UDH option header for HTTP_POST, or udh.../udh **for HTTP_POST with xml document) will force the UDHI bit to 1 (i.e. **OR's esm_class with 0x40) on the esm_class of Kannel's SMPP client **implementation. You do not need to set it manually. ** It would be really helpful if we can do this using XML and URL. ** **Message Mode (bits 1-0) are particular to SMPP. They were not **candidates for configurable parameters because they could not be **abstracted for other SMSC implementations. ** **Message Type (bits 5-2) does not appear to be used by Kannel at all. **This means that all submit_sm will have the Message Type of 0x0 which is **Normal Message. Does anyone know if the other two Message Types (0x8: **ESME Delivery Ack and 0x10: ESME User Ack) are actually used in the wild **(maybe for ESME to respond to a DLR request from an MO SMS)? ** **GSM Network Specific Features (bits 7-6) are set based on: ** 1) If a UDH is present in the MT SMS via ** udh=XXYYXXYY, X-Kannel-UDH: XXYYXXYY, or udhXXYYXXYY/udh ** 2) If a Return Path Indicator is present in the MT SMS ** rpi=1, X-Kannel-RPI: 1, or rpi1/rpi **
Re: Is it possible to set up the esm_class for Kannel?
**Subject: RE: Is it possible to set up the esm_class for Kannel? **Date: Fri, 7 Jan 2005 07:54:34 -0800 **From: Olga Rudchenko [EMAIL PROTECTED] **To: devel@kannel.org ** ** **Hi, ** **Thanks so much for help! I am really stick with this problem. ** **We already use Kannel but would like to expand the list of devices which **we use. They are going to be the J2ME phones. In this case I need to **send SMS with UDH and set up the esm_class to 0x40. If you know any **other tuning which I should to do in this case, let me know please. Actually, setting a UDH in an SMS (via cgi parameter udh= for HTTP_GET, or X-Kannel-UDH option header for HTTP_POST, or udh.../udh for HTTP_POST with xml document) will force the UDHI bit to 1 (i.e. OR's esm_class with 0x40) on the esm_class of Kannel's SMPP client implementation. You do not need to set it manually. **It would be really helpful if we can do this using XML and URL. Message Mode (bits 1-0) are particular to SMPP. They were not candidates for configurable parameters because they could not be abstracted for other SMSC implementations. Message Type (bits 5-2) does not appear to be used by Kannel at all. This means that all submit_sm will have the Message Type of 0x0 which is Normal Message. Does anyone know if the other two Message Types (0x8: ESME Delivery Ack and 0x10: ESME User Ack) are actually used in the wild (maybe for ESME to respond to a DLR request from an MO SMS)? GSM Network Specific Features (bits 7-6) are set based on: 1) If a UDH is present in the MT SMS via udh=XXYYXXYY, X-Kannel-UDH: XXYYXXYY, or udhXXYYXXYY/udh 2) If a Return Path Indicator is present in the MT SMS rpi=1, X-Kannel-RPI: 1, or rpi1/rpi Since this thread is edging towards users@kannel.org type questions, let's continue this discussion over there. See ya... d.c.
Re: Does Kannel support PCMCIA ?
**From: Simon Yip [EMAIL PROTECTED] **To: users@kannel.org **Subject: Does Kannel support PCMCIA ? **Date: Fri, 7 Jan 2005 12:33:45 +0800 ** **Dear all, ** **Does anyone has experience on this ? If you mean for sending receiving SMS: So long as the PCMCIA device: 1) Presents itself as a serial device. 2) Understands the AT commands as specified by: 3GPP TS 27.007 (http://www.3gpp.org/ftp/Specs/latest/Rel-5/23_series/23040-581.zip) OR Is an ISDN or X.25 PAD and connects to an EMI/UCP/SEMA SMSC If you mean WAP: The OS must be able to interface with the PCMCIA card as a network device that support TCP/IP. If you mean does Kannel communicate directly with a PCMCIA card, then the answer is no. Kannel is much higher up in the abstraction layer. See ya... d.c.
Re: reply: 500 Server encountered an internal error. with 1.3.2
**From: Willy Mularto [EMAIL PROTECTED] **To: users@kannel.org **Subject: reply: 500 Server encountered an internal error. with 1.3.2 **Date: Tue, 4 Jan 2005 13:31:00 +0700 ** **Guys, **I got this error message from smsbox-access.log **SMS HTTP-request sender:+628559000xx request: Koneksi Error' url: **'http://1.2.3.4/logic/?msisdn=%2B6285590001xxmsg=test' reply: 500 'Server **encountered an internal error.' **But if I hit the URL via browser then the sms delivered, there is no error **500, what's going on? It appears that the application on the other side of your get-url is interpreting the '+' (%2B) in front of he phone number as a space character and does not know how to handle the situation when there is a space between the 'msisdn=' and the phone number. You can do one of the following: - Strip out the '+' in front of the phone numbers before sending it using get-url via: unified-prefix = -,+ in either your 'group = core' or 'group = smsc' section. - Use post-url and modify your application to expect the CGI variables to be sent to it via stdin. Then have your application understand that msisdn= 6285590001xx is really msisdn=+6285590001xx. - Make your logic program understand that the command line argument: msisdn= 6285590001xxmsg=test is really: msisdn=+6285590001xxmsg=test My opinion would be to do the post-url since that would prevent someone from forcing your logic application from executing arbitrary commands. What happens when your logic application is called by the following URLs: (if UNIX system) http://1.2.3.4/logic/?msisdn=%3Becho%2BHello%3E%2Ffile.txt (if Windows system) http://1.2.3.4/logic/?msisdn=%3Becho%2BHello%3E%5Cfile.txt Do you get a file in your toplevel directory with the content of Hello? See ya... d.c.
Re: Kannel as a Virtual SMSC
**Date: Mon, 03 Jan 2005 17:29:20 +0100 **From: Fr?deric Kinnaer [EMAIL PROTECTED] **To: users@kannel.org **Subject: Kannel as a Virtual SMSC ** ** Hi all, ** **I'm now searching for like the whole day, and I really can't find the **problem. **I want to create a real sms center (what are the differences **anyways??), so I can change my phone's sms center setting into this **mobile number. **I'm connected with a gsm modem (wavecom), and it works fine. ** **This is my config: [ ... lines deleted ... ] ** **What am I doing wrong? My mobile phone tells me 'check operator services' **(nki 3510i) when I want to send sms using this number as sms center. ** **I'm running kannel this way: **./bearerbox ~/smskannel.conf **./smsbox ~/smskannel.conf **(in screens) ** **Bearerbox gives me upon initialisation: **2004-12-22 17:20:30 [31629] [6] INFO: AT2[/dev/ttyS0]: AT SMSC successfully **opened. ** **I also don't get any logs that mobile numbers are trying to connect to the **phone to send sms. Your assumptions are wrong. You cannot use Kannel to replace the SMSC your Nokia 3510i uses when sending SMS. Your Nokia communicates with your operator's SMSC over the radio waves leased by your operator. The only way to change the SMSC used over the radio waves would be if your operator had another SMSC attached to the Mobile Switching Center (e.g. an SMSC used for testing services). Then, you could change the SMSC number on your Nokia 3510i to use the other SMSC. The virtual SMSC made possible by attaching a GSM modem to Kannel is accessible only through Kannel (for MT SMS). The GSM modem still uses the SMSC listed on the SIM you placed into the GSM modem. And, the GSM modem still sends the SMS over the radio waves leased by the operator servicing the SIM inside your GSM modem. See ya... d.c.
Re: bearerbox errormessage 1.3.2
**From: Willy Mularto [EMAIL PROTECTED] **To: users@kannel.org **Subject: bearerbox errormessage 1.3.2 **Date: Wed, 5 Jan 2005 11:05:52 +0700 ** **Guys, **I got these error messages in bearerbox.log: **2005-01-05 11:06:25 [20155] [8] WARNING: DLR[internal]: DLR for DST3665 **not found. **2005-01-05 11:06:25 [20155] [8] ERROR: SMPP[3665]: got DLR but could not **find message or was not interestedin it ts2032285895 dst3665, type2 ** **What does it means? And why I almost always get status 2 (delivery **failure), my GSM operator claim it doesn't their fault because the other **partners doesn't have problem with this issue. I get delivery failures (type=2) when the destination mobile phone runs out of space to store SMS. The warning I've had situations where I would issue a submit_sm with DLR requested and the SMPP server would immediately send me the DLR via a deliver_sm before sending me the submit_sm_resp. As a result, Kannel didn't have the DLR lookup table entry setup yet. I would get that message ... got DLR but could not find message or was not interested in it What might be happening is that the SMSC is rejecting the submit_sm because the destination is refusing to accept more SMS and the SMSC no longer has any more space on it's queue to store the SMS. I would suggest you contact your operator and ask them to check if their queue is full for that particular destination address. See ya... d.c.
Re: kannel deivery reports
**Date: Tue, 04 Jan 2005 13:56:36 +0200 **From: Fyodor Makarenko [EMAIL PROTECTED] **To: users@kannel.org **Subject: kannel deivery reports ** **Hi, ** **Could somebody explain me how to write this dlr.php script for a kannel **delivery reports **mentioned in users guide chapter 9 (SMS Delivery Reports)? Especially I **mean a line: ** **dlr-url=http://www.xyz.com/cgi/dlr.php?type=%d ** **What exactly should do this script? and how we can store delivery **reports/status of the sms message in a MySQL database? **As I understand there is no message ID variable. How we can be sure **that some delivery report/status belong to certain SMS message? **Could someone provide me an example how to write this script and section **from your config file how to configure delivery reports in a **proper way? Look in the users mailing list archive. Search for the title dlr-url and dlr-mask. I just wrote a long posting about the DLR handling. **Also there is an additional question: is it possible to configure **delivery reports for a SMS center configured for GSM phone (smsc = at)? It's not problem. But, the operator might not provide you with all the DLRs you requested. I've found that most will return type 1 (success) or type 2 (failure) but will charge you an SMS for the DLR. See ya... d.c.
Re: bearerbox errormessage 1.3.2
Answers are inline ...
**Subject: Re: bearerbox errormessage 1.3.2
**From: shyam kumar [EMAIL PROTECTED]
**Reply-To: [EMAIL PROTECTED]
**To: Davy Chan [EMAIL PROTECTED]
**Cc: users@kannel.org
**In-Reply-To: [EMAIL PROTECTED]
**References: [EMAIL PROTECTED]
** [EMAIL PROTECTED]
**Message-Id: [EMAIL PROTECTED]
**Date: Wed, 05 Jan 2005 10:36:21 +0530
**
**Hi DC
** The type = 2 means i suppose it is the Submit_SM being used by the SMPP
**Server, and if type = 1 means it is the Deliver_SM used by the SMPP
**Server.
No. Type 2 and Type 1 refer to the Delivery report type as represented
by Kannel. The different SMSC protocols might represent the DLR
status types differently.
BTW, an SMPP server cannot generate an submit_sm and send it to one
of it's clients. submit_sm are only for clients to use when sending
an MT SMS to the SMPP server for delivery (Section 4.4 of SMPP Protocol
Specfication v3.4).
The SMPP server uses deliver_sm to send a message to the
client (Section 4.6) or it can use data_sm (Section 4.7).
**Here is the bearer log
**
**2005-01-05 10:21:07 [2218] [7] DEBUG: SMPP PDU dump ends.
**2005-01-05 10:21:07 [2218] [7] DEBUG: SMPP[SMPP]: Got PDU:
**2005-01-05 10:21:07 [2218] [7] DEBUG: SMPP PDU 0x819d698 dump:
**2005-01-05 10:21:07 [2218] [7] DEBUG: type_name: submit_sm_resp
**2005-01-05 10:21:07 [2218] [7] DEBUG: command_id: 2147483652 =
**0x8004
**2005-01-05 10:21:07 [2218] [7] DEBUG: command_status: 0 = 0x
**2005-01-05 10:21:07 [2218] [7] DEBUG: sequence_number: 5 = 0x0005
**2005-01-05 10:21:07 [2218] [7] DEBUG: message_id: 772010500
**2005-01-05 10:21:07 [2218] [7] DEBUG: SMPP PDU dump ends.
**2005-01-05 10:21:07 [2218] [7] DEBUG: DLR[mysql]: Adding DLR smsc=SMPP,
**ts=772010500, src=Tanla, dst=919849339091, mask=7, boxc=
**2005-01-05 10:21:07 [2218] [7] DEBUG: sql: INSERT INTO dlr (smsc, ts,
**source, destination, service, url, mask, boxc, status) VALUES ('SMPP',
**'772010500', 'x', '', 'tester', '', '7', '', '0');
**2005-01-05 10:21:07 [2218] [1] DEBUG: Dumping 0 messages and 0 acks to
**store
**2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP[SMPP]: Got PDU:
**2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP PDU 0x819d698 dump:
**2005-01-05 10:22:24 [2218] [7] DEBUG: type_name: deliver_sm
**2005-01-05 10:22:24 [2218] [7] DEBUG: command_id: 5 = 0x0005
**2005-01-05 10:22:24 [2218] [7] DEBUG: command_status: 0 = 0x
**2005-01-05 10:22:24 [2218] [7] DEBUG: sequence_number: 16777216 =
**0x0100
**2005-01-05 10:22:24 [2218] [7] DEBUG: service_type: NULL
**2005-01-05 10:22:24 [2218] [7] DEBUG: source_addr_ton: 5 = 0x0005
**2005-01-05 10:22:24 [2218] [7] DEBUG: source_addr_npi: 1 = 0x0001
**2005-01-05 10:22:24 [2218] [7] DEBUG: source_addr: x
**2005-01-05 10:22:24 [2218] [7] DEBUG: dest_addr_ton: 1 = 0x0001
**2005-01-05 10:22:24 [2218] [7] DEBUG: dest_addr_npi: 1 = 0x0001
**2005-01-05 10:22:24 [2218] [7] DEBUG: destination_addr: 919849339091
**2005-01-05 10:22:24 [2218] [7] DEBUG: esm_class: 4 = 0x0004
**2005-01-05 10:22:24 [2218] [7] DEBUG: protocol_id: 0 = 0x
**2005-01-05 10:22:24 [2218] [7] DEBUG: priority_flag: 3 = 0x0003
**2005-01-05 10:22:24 [2218] [7] DEBUG: schedule_delivery_time: NULL
**2005-01-05 10:22:24 [2218] [7] DEBUG: validity_period: NULL
**2005-01-05 10:22:24 [2218] [7] DEBUG: registered_delivery: 0 =
**0x
**2005-01-05 10:22:24 [2218] [7] DEBUG: replace_if_present_flag: 0 =
**0x
**2005-01-05 10:22:24 [2218] [7] DEBUG: data_coding: 0 = 0x
**2005-01-05 10:22:24 [2218] [7] DEBUG: sm_default_msg_id: 0 =
**0x
**2005-01-05 10:22:24 [2218] [7] DEBUG: sm_length: 81 = 0x0051
**2005-01-05 10:22:24 [2218] [7] DEBUG: short_message:
**2005-01-05 10:22:24 [2218] [7] DEBUG:Octet string at 0x819d450:
**2005-01-05 10:22:24 [2218] [7] DEBUG: len: 81
**2005-01-05 10:22:24 [2218] [7] DEBUG: size: 82
**2005-01-05 10:22:24 [2218] [7] DEBUG: immutable: 0
**2005-01-05 10:22:24 [2218] [7] DEBUG: data: 69 64 3a 20 73 75 62 3a
**31 20 64 6c 76 72 64 3a id: sub:1 dlvrd:
**2005-01-05 10:22:24 [2218] [7] DEBUG: data: 31 20 73 75 62 6d 69 74
**20 64 61 74 65 3a 30 35 1 submit date:05
**2005-01-05 10:22:24 [2218] [7] DEBUG: data: 30 31 30 35 31 30 30 39
**20 64 6f 6e 65 20 64 61 01051009 done da
**2005-01-05 10:22:24 [2218] [7] DEBUG: data: 74 65 3a 30 35 30 31 30
**35 31 30 31 30 20 73 74 te:0501051010 st
**2005-01-05 10:22:24 [2218] [7] DEBUG: data: 61 74 3a 44 45 4c 49 56
**52 44 20 65 72 72 3a 20 at:DELIVRD err:
**2005-01-05 10:22:24 [2218] [7] DEBUG: data: 20
**2005-01-05 10:22:24 [2218] [7] DEBUG:Octet string dump ends.
**2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP PDU dump ends.
**2005-01-05 10:22:24 [2218] [7] DEBUG: SMPP[SMPP] handle_pdu, got DLR
**2005-01-05 10:22:24 [2218] [7] DEBUG: DLR[mysql]: Looking for DLR
**smsc=SMPP, ts=, dst=919849339091, type=1
**2005-01-05 10
Re: post-url
**Date: Mon, 3 Jan 2005 03:43:46 -0800 (PST) **From: Real World [EMAIL PROTECTED] **Subject: post-url **To: Kannel users@kannel.org ** **hi friends , ** **i'm bit confused about post-url. can any body help or guide me to write a php script to send sms via default service ? **This php script supposed to be a Post- URL . ** ** **Thanx in advance **Mr. Bee Search the kannel user mailing list. Keywords should be: post-url, HTTP_POST, X-Kannel-To, X-Kannel-Coding You will see explicit instructions and examples on how to use the the post-url as well as the exact information passed during the HTTP interaction. See ya... d.c.
Re: post-url
**Date: Mon, 3 Jan 2005 19:56:32 -0800 (PST) **From: Real World [EMAIL PROTECTED] **Subject: Re: post-url **To: Julien Buratto [EMAIL PROTECTED], Kannel users@kannel.org ** **thanx for the reply , let me ask some questions ? **I have defined default service for post url . Normally i can send out sms via web browser. ** **1. I need to specify a service for post url . do i have to write a script/code ? **2. without writing any code cant i try with just a URL ? with help of Parameters (Escape Codes ) ** **Actually still i cant get exact idea of POST URL . plz dont think , i'm bothering u all , plz help me ** **thanx ** ** **Julien Buratto [EMAIL PROTECTED] wrote: **Real World wrote: ** hi friends , ** ** i'm bit confused about post-url. can any body help or guide me to write ** a php script to send sms via default service ? ** This php script supposed to be a Post- URL . ** ** ** **Try to fopen(http://your_kannel_host/page.cgi?variables,r;) and print **the chars you get back. ** **J Answer to Question 1) A post-url is part of the sms-service delcaration. This means that the HTTP_POST will occur when an MO SMS (SMS coming from an enduser sending an SMS to your service) reaches the smsbox. Assume that the user (phone number: +1 333 555 9876) created an SMS with the content: weather nyc He then sends the SMS to the phone number: +1 222 555 1234. When the message is sent to that phone number, it will be routed to your connection (maybe because the you have an agreement between you and the operator to forward the SMS to you OR maybe that number is associate with the SIM you are using inside the GSM modem you setup as a virtual SMSC). The SMS is sent to your bearerbox. The bearbox then forwards it to your smsbox. The smsbox will receive the SMS, notice that you have a default service set like this: group = sms-service name = myservice_via_post keyword = default catch-all = true post-url = http://192.168.16.1/cgi-bin/sms-from-user; The smsbox will make an HTTP_POST to the host 192.168.16.1 and issue the following info to your HTTP server: POST /cgi-bin/sms-from-user HTTP/1.1 Host: 192.168.16.1:80 User-Agent: Kannel/1.4.0 Content-Type: text/plain X-Kannel-From: 1333559876 X-Kannel-Time: 2005-01-04 07:11:31 X-Kannel-Coding: 0 X-Kannel-Service: myservice_via_post Content-Length: 11 weather nyc Your application (sms-from-user) will be started by your HTTP server and receive the weather nyc as input. Your application can then perform the service associated with that request (get the weather condition for NYC) and write out the information back to your HTTP server. Your HTTP server will then send the information back via the established HTTP_POST connection between the HTTP server and the smsbox. The smsbox will take the text you send it, create an SMS out of it and generate an MT SMS (SMS going to a mobile device) targeted back to the +1 333 555 9876 phone number. The smsbox sends it to the bearerbox for delivery. The bearerbox receives the SMS and sends it to the Mobile Network Operator for final delivery to the mobile user. The user gets an SMS with the information he/she requested. Answer to Question 2) Instead of using post-url in your group = sms-service section, you can use the get-url declaration. In that case, you assume that the URL you specify can perform the service on your behave and generate the output that will be sent back to the user. Using the same scenario as before (get weather condition for NYC), you would have the following in your configuration: group = sms-service name = myservice_via_get keyword = default catch-all = true get-url = http://192.168.16.1/cgi-bin/sms-from-user?city=%s; When the user sends the SMS, your smsbox will issue an HTTP_GET to your HTTP server like: GET /cgi-bin/sms-from-user?city=nyc HTTP/1.1 Host: 192.168.16.1:80 User-Agent: Kannel/1.4.0 Your HTTP Server will start the application (sms-from-user) and be given the argument: city=nyc The application will perform the service and hopefully output the results. The HTTP server will return the information back to the smsbox via the HTTP connection established from the HTTP_GET and smsbox will generate an MT SMS with the content and send it to the user. See ya... d.c.
Re: [Kannel-Users] dlr status 1.4.0
**From: Willy Mularto [EMAIL PROTECTED] **To: Peter Beckman [EMAIL PROTECTED] **Subject: Re: [Kannel-Users] dlr status 1.4.0 **Date: Thu, 30 Dec 2004 15:06:44 +0700 ** **And also I got this error message on smsbox.log **2004-12-30 14:54:13 [2484] [9] ERROR: Couldn't send request to **2004-12-30 14:54:16 [2484] [9] ERROR: URL doesn't start with `http://' **nor `https://' **2004-12-30 14:54:16 [2484] [9] ERROR: Couldn't send request to **2004-12-30 14:54:19 [2484] [9] ERROR: URL doesn't start with `http://' **nor `https://' **2004-12-30 14:54:19 [2484] [9] ERROR: Couldn't send request to ** **Ideally when your SMSC gets the message and passes it successfully to the **carrier, you would get a DLR of 4, and once it gets to the handset **successfully, a DLR of 1. I never got any other response except 8 on **bearerbox-access.log ** ** **Regards ** **Willy Are you getting this error for the DLR-URL or are you getting this for a get-url/post-url from the group = sms-service section? Make sure the declaration is all on a single line with no line breaks. Also, if you use a double-quote () at the beginning of the value, make sure you close the double-quote at the end of the value. If you forget the double-quote at the end, then the parse_value() function inside of cfg.c will not know it needs to strip out the double-quotes. See ya... d.c.
Re: Kannel and GSM modems
**From: Baden de Bari [EMAIL PROTECTED] **To: Rafael 'Dido' Sevilla [EMAIL PROTECTED] **Date: Fri, 17 Dec 2004 11:51:47 -0600 **Subject: Kannel and GSM modems ** **There are sites that post the SMS/GSM codes for most world-wide network **carriers. So Kannel uses a GSM modem to link up to these carriers? ** **For example, if we want to send in the US and Canada, we would need some **sort of agreement with the network carriers to send to customers on their **networks? ie. To send a msg to a user in Canada using Rogers Wireless: **we have the number, and want to push the message to them. ** **As I'm not too familiar with the use of GSM modems, I would like some **more in formation about how to use them with Kannel and how to link up **to world-wide carriers? ** Please send text-only mail to the mailing list. Some of us don't use HTML-enabled mail readers due to many reasons. I will reply to all three of your emails in this email. GSM and CDMA are two different technologies to accomplish the same thing: send voice and data to mobile terminal. These mobile terminals can be mobile phones that support voice, SMS, data, a pretty color screen, etc., or they can be modems that support limited functionality (maybe just SMS and data). GSM uses a Subscriber Information Module (SIM) to store information on how to connect to the Mobile Network Operator (MNO) that is his/her home operator. The SIM can be moved from one GSM device to another. This allow you to use different devices with the same SIM (allowing easy upgrades of phones) or use different SIMs with the same device (allowing you to try different MNO to see if they have better coverage or lower pricing tariffs). CDMA uses the International Mobile Equipment Identity (IMEI) number (or equivalent) to determine if the device (phone, modem, etc) is allowed on a particular network. As a result, moving a device from one MNO to another requires you to register your device with them. The way Kannel uses a GSM modem is via the AT commands as defined by the ETSI TS 07.07 specifications. Kannel sends AT commands to the GSM modem (AT+CMGS to send an SMS, AT+CMGR to read an SMS, etc.) and reads the responses. Normal procedure is: 1. Buy a GSM modem that supports the ETSI 07.07 AT commands (some phones have builtin modems that support the AT commands) 2. Attach the GSM modem to the serial port of the host running Kannel 3. Get a SIM from an MNO 4. Get a phone number associated with the SIM (usually pre-assigned by the MNO or you might be able to pick the phone number for a list available from the MNO). 5. Plug in the SIM to the GSM modem. 6. Start sending and receiving SMS. This procedure [minus steps 3 and 5] also works with a CDMA modem so long as the CDMA modem also supports the AT commands in the ETSI documents (my update to the userguide will list the requied AT command set used by Kannel). When you send an SMS, the message will originate from the phone number assigned to the SIM. When someone wants to send you an Mobile Originated (MO) SMS, they would send it to the phone number assigned to your SIM. Most MNO's will have roaming agreements with other MNO's so their home subscribers can roam to the other MNO's network and still have phone service (at higher cost). Ususally, the roaming agreements also states that the subscribers from one MNO can send SMS to subscribers on the other network. This allow for someone in Hong Kong to send SMS to someone in France. Since the MNO's have the agreements to pass SMS to other MNO's, in the GSM world, you do not need to get an agreement specifically to do this. For CDMA, it's a different world. Text messages in the CDMA world, was originally Mobile Terminated (MT) messages (i.e. the carrier can send the message to you but you could not send a message back [no MO SMS].). More recently, CDMA added support for MO SMS. As a result, many CDMA MNOs did not have agreements to pass SMS between each other. This meant you needed to get agreements with each operator before you can send messages to their subscribers. Nowadays, there are SMS aggregators that can provide you with the means to send SMS to just about any subscriber. They have made the agreements with the MNOs and will provide you with a means to send (and sometimes receive) SMS. Some provide connections that use HTTP, SMPP, etc., that Kannel will use to communicate with them. In those, cases, you would not need a GSM modem. But, you would need to get an account from the aggregator and pay for sending/receiving the SMS. See ya... d.c.
Re: GSM Modem + SMPP ........ sms receiving
You might be getting UCS2 (double-byte) characters. Check your bearerbox logs (usually in kannel.log) to see what you are receiving from your SMPP provider. From your other message, it would appear that they are not sending you GSM7 characters. As a result, the keywords listed in your sms-service group would not automatically match. You might want to set the 'mo-recode' option in your smsc configuration group for the SMPP connection. This will indicate to the bearerbox that it should try to recode any non ISO-8859-1 characters (e.g. UCS2) back to ISO-8859-1 which can be matched with your 'keyword'. See ya... d.c. **Date: Wed, 15 Dec 2004 17:03:17 -0800 (PST) **From: Tech mark [EMAIL PROTECTED] **Subject: Re: GSM Modem + SMPP sms receiving **To: Davy Chan [EMAIL PROTECTED], Kannel [EMAIL PROTECTED] **In-Reply-To: [EMAIL PROTECTED] ** **as u said , i have done configurations. when i send **sms via GSM modem to a certain application which has **been hosted in SMSC , by that should reply for the **kannel box . Bearbox showing it receives that reply , **but from smsbox nothing are showing. ** **In my configurations , for the core setup i have **added following lines, ** **sms-incoming-queue-limit = -1 **smsbox-max-pending = 1 ** **Is this wrong ? i dont want to put that replies in a **que, i want to get them to the smsbox as soon as they **received. ** **plz advice me , ** **Thanx in advance, **anaconda **--- Davy Chan [EMAIL PROTECTED] wrote: ** ** **Date: Fri, 10 Dec 2004 18:57:35 -0800 (PST) ** **From: Tech mark [EMAIL PROTECTED] ** **Subject: GSM Modem + SMPP ** **To: Kannel [EMAIL PROTECTED], Navjot ** [EMAIL PROTECTED] ** ** ** **hi Kannel , ** ** ** ** ** **I would like to know , in kannel , is there any ** possibility to run GSM modem + SMPP simultaniously ** in a same configuaration file ? ** **my requrement is , ** **1. start to send sms via GSM modem ** **2. when in some instances i want to send sms via ** smpp as well . ** ** ** **plz guide me . ** ** ** **Thanx in advance ** ** - Create a section for the GSM modem: **group = smsc **smsc = at **smsc-id = smsc_at **allowed-smsc-id = smsc_at ** : ** : ** - Create a section for the SMPP connection: **group = smsc **smsc = smpp **smsc-id = smsc_smpp **allowed-smsc-id = smsc_smpp ** : ** : ** - Create a section for routing that will be read by ** the bearerbox: **group = smsbox-route **smsbox-id = smsbox **smsc-ids = smsc_at;smsc_smpp ** - When sending MT SMS, specify the smsc-id of the ** GSM modem when **you want to send through the GSM modem: ** GET ** **/cgi-bin/sendsms?smsc=smsc_atto=1234text=msg%20to%20GSM%20Modem ** - When sending through the SMPP connection, use the ** smsc-id of the **SMPP connection: ** GET ** **/cgi-bin/sendsms?smsc=smsc_smppto=1234text=msg%20to%20SMPP ** ** See ya... ** ** d.c.
Re: Chinese SMS
**From: Simon [EMAIL PROTECTED] **To: Davy Chan [EMAIL PROTECTED], Guillaume Cottenceau [EMAIL PROTECTED] **Cc: [EMAIL PROTECTED] **Subject: Re: Chinese SMS **Date: Thu, 2 Dec 2004 21:13:39 +0800 ** **This is an artifact of the GREAT MIGRATION FROM 0 MEANING UNDEFINED **awhile back. Kannel up to v1.3.2 did not have a clear definintion **of what to put into parameters (like Coding, MWI, RPI, MClass, etc). **Some used zero to represent undefined values but zero could be **a value for some parameters (like MWI, RPI). ** **Also, there wasn't a clear standard on whether to start the parameters **with a count from 0..1..2 or 1..2..3. ** **As a result, the value of -1 is now declared as meaning UNDEFINED **and all parameters start from zero. ** **My example was for v1.3.1 (sorry for not including that in my **reply...was typing to fast...). ** **If you are using versions prior to v1.3.2, then the coding for **UCS-2 (double-byte) characters is 3; 8-bit binary (like STK **provisioning) is is 2; 7-bit GSM7 character set is 1 or 0. ** **If you are using versions after v1.3.1 (v1.3.2, v1.4.0 stable, and **CVS head) then UCS-2 is 2; 8-bit binary is 1; GSM7 character **set is 0; and undefined coding is -1. ** **Hope that clears things for everyone. ** **See ya... ** **d.c. ** ** ** **Thank you, Davy Chan. **I submited something like the following. **http://localhost:12345/cgi-bin/sendsms?username=upassword=pto=91239123text=%a4%a4%a4%e5coding=2 **But I still experience the unreadable Chinese words. **Is there something I missed? The code %A4%A4%A4%E5 (Chinese) is in Big5. You need to send the UCS-2 [UTF-16BE] encoding: %4E%2D%65%87. See ya... d.c.
Re: Can i get the Mobile number when a wap request is made.
**From: santosh [EMAIL PROTECTED] **To: [EMAIL PROTECTED] **Subject: Can i get the Mobile number when a wap request is made. **Date: Wed, 1 Dec 2004 13:37:24 -0800 ** **Hi All, ** **I am using kannel as the wap gateway. Everything is working fine.. but i am not able to get the mobile number. ** **Can any one guide me as how to get the mobile number of the person who has made the wap request. ** **As of now i am only getting the IP address of the mobile but not the mobile number.. ** **Can anyone please guide me on how to get this.. Normally, that information is not released to content providers/WAP gateway operators unless you have an agreement with the Mobile Network Operator. Some operators (after consenting to pass the information to you) will include that information in the Headers sent to your WAP gateway (X-MSISDN: +8529000). Others will always send you an obfuscated MSISDN number and charge you to dip into their database to obtain the real MSISDN. See ya... d.c.
Re: Chinese SMS
**To: Davy Chan [EMAIL PROTECTED] **Cc: Yip Kwok Fai [EMAIL PROTECTED], [EMAIL PROTECTED] **Subject: Re: Chinese SMS **From: Guillaume Cottenceau [EMAIL PROTECTED] **Date: 01 Dec 2004 12:03:18 +0100 **In-Reply-To: [EMAIL PROTECTED] **User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 ** **Davy Chan chandave 'at' cs.ust.hk writes: ** ** If you are using versions after v1.3.1 (v1.3.2, v1.4.0 stable, and ** CVS head) then UCS-2 is 2; 8-bit binary is 1; GSM7 character ** set is 0; and undefined coding is -1. ** ** Hope that clears things for everyone. ** **Ok, thanks. Then the userguide from CVS is broken. Want to fix **it? Would not mind. Will generate a patch and submit it later this week. See ya... d.c.
Re: Chinese SMS
**From: Yip Kwok Fai [EMAIL PROTECTED] **To: [EMAIL PROTECTED] **Subject: Chinese SMS **Date: Wed, 1 Dec 2004 13:18:13 +0800 ** **How can I send Chinese SMS through web interface ? Is there any encoding **required ? **Thank you very much. Chinese characters requires double-byte support. You will need to submit the SMS with an encoding of 3 either through an HTTP_POST header (X-Kannel-Coding: 3) or as a parameter in an HTTP_GET (GET /cgi-bin/sendsms?coding=3text=...) See ya... d.c.
Re: SMPP test
**Date: Mon, 29 Nov 2004 23:03:01 + **Subject: SMPP test **From: Jo?o Correia [EMAIL PROTECTED] **To: Kannel [EMAIL PROTECTED] ** **Where can I find a provider in wich I can test an SMPP connection for free ? Why not just use an SMPP simulator? You can find some at: http://www.smpp.org/smpp_tools.html See ya... d.c.
Re: Question about shortcode
**Date: Wed, 24 Nov 2004 16:21:05 -0500 **From: Eric Monchanin [EMAIL PROTECTED] **User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) **To: [EMAIL PROTECTED] **Subject: Re: Question about shortcode **In-Reply-To: [EMAIL PROTECTED] ** **some details: ** **we want all our messages to be sent with the shortcode set as reply address **would it be enough to set **in sms-box **global-sender = our short code ** **and would it override all from if we set any ? ** **Eric Monchanin a ?crit : ** **Hi, ** **Sorry if this looks silly, but we have a working kannel config, and it **was not my job to take care of it. **Now, we just received the shortcode for our business. **If think it's an identifier to set for each transaction with our **aggregator but not quite sure. **Can anyone give me some details about that, and/or tell me if I can **configure it in kannel.conf file. I would suggest you use the default-sender parameter found in the group sendsms-user instead of the global-sender parameter in the group smsbox. The default-sender will only be used if you transfer and SMS to the smsbox without an Origination Address (ie connect to kannel's /cgi-bin/sendsms and send an SMS without a from=... or X-Kannel-From). If you do set the Origination Address then Kannel will use your specified address. On another note ... Does anyone else but me think that a 20 digit Short Code is an oxymoron? See ya... d.c.
Re: A# method
**From: Willy Mularto [EMAIL PROTECTED] **To: [EMAIL PROTECTED] **Subject: A# method **Date: Mon, 22 Nov 2004 16:47:50 +0700 ** **Guys, **Any of you have successfully configured kannel to deal with A# charging? A# charging is a method where we only need to connect from one user account to SMSC then when we submit MT we add n digit behind our shortcode/shornumber, for example I have 1234 as my shortcode, when a subscriber request content which will be charged $2, then I will add 123402 (the 02 is the A#) then send it back to the SMSC. I hope this explanation clear enough, what configuration needed here? Please help me. Any reply is highly appreciated. ** Scenario: User with MSISDN of +8529000 creates an SMS with the following content: add 2 3 5 and then sends it to shortcode 1234. You receive the SMS and perform the addition, 2 + 3 + 5, and send back Answer: 10 using the origination address of 123402 which results in a charge of $2 on the user's SMS charges ($2 charge requires Mobile Network Operator to support your request for MT billing services). 1) In the kannel.conf, have a section that accepts all MO SMS and HTTP_POST them to your application for processing: group = sms-service name = smsc2myappl keyword = default omit-empty = true max-messages = 0 send-sender = true catch-all = true post-url = http://host.domain/addition.cgi; 2) In your application, expect Kannel to do an HTTP_POST with the entire content of the SMS. You can retrieve the MSISDN number of the mobile subscriber by looking at the X-Kannel-From HTTP header. The addition.cgi program will get something like this from Kannel: POST /addition.cg HTTP/1.0 Host: host.domain:80 X-Kannel-From: 8529000 X-Kannel-To: 1234 Content-Type: text/plain Content-Length: 9 add 2 3 5 3) Parse the SMS to see what keyword/service the mobile subscriber was requesting from you. 4) Perform the service on behave of the mobile subscriber. In this case, you add 2 + 3 + 5. 5) Send the results to the mobile subscriber via an MT SMS that is HTTP_POST'ed to Kannel's smsbox with the origination address to be your short code + charge: POST /cgi-bin/sendsms HTTP/1.0 X-Kannel-From: 123402 X-Kannel-To: +8529000 X-Kannel-Username: foo X-Kannel-Password: bar Content-Type: text/plain Content-Length: 10 Answer: 10 You are done. See ya... d.c.
Re: not getting the parameters value(help me plz)
compensate for all the different SPACE characters in your character set (Nokia phones that support Chinese characters can generate 3 differnet SPACE characters depending on which input method you use [stroke, pinyin, bopomofo]). For examples of what an HTTP_POST from kannel (v1.3.1) will look like when sent to your application, search the user mailing list for articles with the following keywords: davy chan x-kannel-mwi davy chan zohar sending UDH davy chan gemplus ota See ya... d.c.
Re: Special Character Problem
**Date: Thu, 9 Sep 2004 12:20:59 +0500 **From: Omer Bin Fateh [EMAIL PROTECTED] **To: [EMAIL PROTECTED] **Subject: Special Character Problem ** **Dear All ** **Please look into this matter. ** ** I am not receiving $ and @ sign on my mobile . i am receiving **the junk value .x .Following command i am giving ** **curl 'http://127.0.0.1:13013/cgi-bin/sendsms?user=xxpassword=xxxto=text=testing%20message%20$%20and%20@' ** **curl 'http://127.0.0.1:13013/cgi-bin/sendsms?user=***tpassword=*to=text=testing%20message%20%24%20and%20%40%20value' ** ** **in both case i received junk value ** **following is the access.log entries ** **[EMAIL PROTECTED] sms]# tail -f access.log **2004-09-04 20:06:55 Sent SMS [SMSC:] [SVC:test] [ACT:] [from:101] **[to:73111048] [flags:0:1:0:0:0] [msg:44:MOB#:73111048 Issue Date: **2004-04-16 Lst $] [udh:0:] **2004-09-04 20:11:32 Sent SMS [SMSC:] [SVC:test] [ACT:] [from:101] [ ... lines deleted ... ] If you are NOT using the virtual SMSC option (i.e. if you are not using a GSM modem or phone for your SMSC), then this might apply to your situation... Make sure that your Mobile Network Operator's SMSC is using the GSM7 character set. The GSM7 character set has different mappings for characters not in the range of [a-zA-z0-9]. In particular, the GSM7 character set maps an '@' character to a 0x00 (zero byte). Some opertors set their SMSC to use Latin-1 or ASCII instead of the GSM7 character set. You can see if that is the case by sending a 0x00 (zero-byte) character to the SMSC. If an '@' appears on your phone then they are NOT using GSM7. Most likely they are using ASCII as their character set. If your operator is using the ASCII or Latin-1 character set then you will need to modify the character set listing in Kannel's source code to match your MNO's character representation. Or, you can try to convince your MNO to conform to standard pratices that everyone else in the world conforms to by using the GSM7 character set. See ya... d.c.
Please stop sending HTML in your email
Can we all please set our Mail User Agents back to TEXT-ONLY mode and stop sending HTML? Not only does the HTML format add nothing to the content, it makes it difficult to read when viewed on a real-estate challenged device (like a phone). See ya... d.c.
Re: got +CMT but pdu_extract failed
**From: [EMAIL PROTECTED] **To: [EMAIL PROTECTED] **Subject: got +CMT but pdu_extract failed **Date: Thu, 21 Aug 2003 16:45:18 +0600 ** ** **Dear Sir , ** **i'm tring to use Ericsson R520m , when i try to receive a sms it says **got +CMT but pdu_extract failed error mesaage. **where can be the error ? Are you sure the R520m supports PDU mode or has no switched back to TEXT mode? When I get that message, it usually means that the SMS received by the phone was transfer to Kannel as a text message instead of as a PDU. Some gsm modem implementations have a tendency switch back to text mode. I fixed this by forcing PDU mode after every command (AT+CMGF=0 after every AT+ command). Verify that the R520m is return something that Kannel can understand. Try the following: 1) connect to the R520m with a serial terminal program (minicom). 2) Issue your init string to the modem: AT+CNMI=3,3,2,0,0 3) Set the R520m to PDU mode: AT+CMGF=0 4) Send a SMS to the R520m and see if you get: +CMT: ,29 070302903904E... or +CMT: 123456,03/08/21, 21:30:00+00,129,4,32,240,15379,129,5 or +CMTI: SM,1 If 4) returns the first example, then Kannel will be able to extract the PDU from the message. If you received example 2, then the modem is in TEXT mode. If you receive example 3 then, the message was pushed into your SIM memory. If you got a good PDU the first time, then try sending another SMS to the R520m to confirm that the modem will stay in PDU mode. Regards, Davy Chan
Re: OTA info
**From: Oscar Flores [EMAIL PROTECTED] **To: [EMAIL PROTECTED] **Subject: RE: OTA info **In-Reply-To: [EMAIL PROTECTED] **Date: Fri, 15 Aug 2003 09:55:08 -0400 ** **Hi ** **Thaks for your answers, we've set the parameters as you indicated bellow **but, we've been reviewing the GSM 3.40 and also som Gemplus manuals and **we have to set these parameters. ** **TP-TPDU (MTI, MMS, SRI, UDHI, Reply Path) **TP-OA (Originator Address, TON, NPI) **TP-PID **TP-DCS **TP-SCTS **TP-UDL **TP-UD ** **From the configuration that you give to us we got the TP-PID and TP-DCS **and we also build the TP-UD (User Data Header + User Data Binary), but **we still have missed the TP-TPDU, TP-OA, TP-SCTS, TP-UDL Do you know how **to get this parameters from Kannel? I mean how to get this parameteres **using kannel settings? ** **And also, does anyone of you know the SIM Toolkit commands that have to **go in the TP-UD? ** **Many Thanks Are you trying to construct your own OTA from the GEMPlus specs or are you using the OTA generated by the ADE Parser? If you send the binary version of the hex dump generated by the ADE Parser to kannel as an application/octet-stream, then you do not have to deal with the MTI, MMS, and UDHI. Kannel will take care of the OA [TON/NPI]. Kannel will also set UDHI and RP if you tell Kannel to set it. MTI (Message Type Indicator) is set by Kannel as SMS-DELIVER since you are using Kannel to generate an MT SMS to a mobile entity. MMS (More Message to Send) is set by Kannel if, due to size of SM, Kannel had to split up the original SM into multiple 140 octet SM. SRI (Status Report Indicator) is set when you use Kannel's DeLivery Report (DLR) feature. Of course, the operator must be willing to provide you with delivery reports in order for this to work. UDHI (User Data Header Indicator) is set by Kannel if you use the X-Kannel-UDH Header to an HTTP_POST, the udh= of an HTTP_GET, or the udh/udh of an XML_POST. RP (Reply Path Indicator) can be set by Kannel if you use the X-Kannel-RPI Header to an HTTP_POST, rpi= of an HTTP_GET, or the rpi/rpi of an XML_POST. TP-OA (Originating Address), its Type Of Number (TON), and Number Plan Identifier (NPI) is set by Kannel. The method varies a little from each SMSC handler. Normally, if the OA or Destination Address (DA) is prefixed by an '+' when sent to Kannel's sendsms-user interface, then the TON will be set to xx001 (0x10)--International. If no '+' prefix then the TON is set to xx000 (0x00)-Unknown. The NPI is usually set to x0001 (0x01)-ISDN/E.164/E.163. Some SMSC handlers can accept a hard-coded TON/NPI (eg SMPP). Consult the Kannel manual for more info on how to force the TON/NPI on the OA and DA. I have no idea how you can set the Service Center Time Stamp (SCTS) since that's not set by the SMS Messaging Entity (SME). If you are using the hex dump from the ADE Parser, then the first octet indicates the User Data Length (UDL) and can be relayed to Kannel via the Content-Length Header of an HTTP_POST. The User Data (UD) is the binary representation of the the hex dump after the UDL. You can relay this to Kannel by: 1) converting the hex dump to binary octets 2) establishing an HTTP_POST to Kannel's sendsms-user service 3) setting all the headers as indicated by my previous email 4) setting the Content-Type Header to be application/octet-stream 5) sending the binary octets to Kannel via the HTTP_POST connection [ ... ] Jeesshnow I finally read your last enquiry. I can better understand the reason why you though you needed to generate all this. You DON'T have or DON'T want to use the ADE Parser to generate the OTA. You are trying to roll your own OTA through the GEMPlus specs. I can't answer you about the contents of the UD. I'm not sure if the current OTA generated by the ADE Parser is 3GPP 23.140 compliant or not (I don't have the time to compare bytecodes). Check out the technical specs for the SIM Toolkit available in the 3GPP tech specs repository. Regards, Davy Chan
Re: System error 104 : Error reading from fd23 - Please help
19:55:51 [5] DEBUG: AT2[com4]: detecting **modem type **2003-08-15 19:55:51 [5] INFO: AT2[com4]: opening **device **2003-08-15 19:55:51 [6] DEBUG: sms_router: time to **sleep **2003-08-15 19:55:51 [0] DEBUG: Started thread 6 **(gw/bb_smscconn.c:sms_router) **2003-08-15 19:55:51 [0] INFO: ** **2003-08-15 19:55:51 [0] INFO: Kannel bearerbox II **version 1.3.0 starting **2003-08-15 19:55:51 [5] DEBUG: AT2[com4]: device **opened **2003-08-15 19:55:51 [0] INFO: MAIN: Start-up done, **entering mainloop **2003-08-15 19:55:51 [0] DEBUG: AT2[com4]: start called **2003-08-15 19:55:51 [6] DEBUG: sms_router: list_len = **0 **2003-08-15 19:55:51 [5] INFO: AT2[com4]: speed set to **115200 **2003-08-15 19:55:51 [5] DEBUG: AT2[com4]: -- ^M **2003-08-15 19:55:53 [5] DEBUG: AT2[com4]: -- AT^M **2003-08-15 19:55:53 [5] DEBUG: AT2[com4]: -- OK **2003-08-15 19:55:53 [5] DEBUG: AT2[com4]: -- ATF^M **2003-08-15 19:55:53 [5] DEBUG: AT2[com4]: -- OK **2003-08-15 19:55:53 [5] DEBUG: AT2[com4]: -- ATE0^M **2003-08-15 19:55:53 [5] DEBUG: AT2[com4]: -- ATE0 **2003-08-15 19:55:53 [5] DEBUG: AT2[com4]: -- OK **2003-08-15 19:55:53 [5] DEBUG: AT2[com4]: -- ATI^M **2003-08-15 19:55:53 [5] DEBUG: AT2[com4]: -- ERROR **2003-08-15 19:55:53 [5] DEBUG: Thread 5 **(gw/smsc/smsc_at2.c:at2_device_thread) t **erminates. **2003-08-15 19:56:30 [4] DEBUG: Started thread 7 **(gw/bb_boxc.c:function) **2003-08-15 19:56:30 [7] INFO: Client connected from **127.0.0.1 **2003-08-15 19:56:30 [7] DEBUG: Started thread 8 **(gw/bb_boxc.c:boxc_sender) **2003-08-15 19:57:23 [7] DEBUG: boxc_receiver: sms **received **2003-08-15 19:57:23 [6] DEBUG: sms_router: time to **sleep **2003-08-15 19:58:46 [7] DEBUG: boxc_receiver: sms **received **2003-08-15 20:02:38 [2] DEBUG: HTTP: Creating **HTTPClient for `169.254.101.152'. **2003-08-15 20:02:38 [3] DEBUG: HTTP: Resetting **HTTPClient for `169.254.101.152'. ** **/snip The 'ATI' is a query to the modem to identify itself. Kannel issues the 'ATI' and listens for the response from the modem...hoping to be able to map the response to a known modem configuration found in the modems.conf. At this point your modem is failing to give Kannel what it wants. If you still want to use your LG phone, then you will need to modify gw/smsc/smsc_at2.c to bypass the identification query and hardcode the identification to your LG. BTW, if your LG does not understand ETSI 07.05 AT commands for sending/receiving SMS via a modem, then you cannot use your LG as a virtual SMSC. In other words, if the modem does not understand 'AT+CMGS' (Communication:MessaGeSend), and 'AT+CMGR' (Communication:MessaGeRead) then don't go any further. Kannel will not know how to talk to your modem. Kannel requires the following additional things to be supported by the modem before it can be used as a virtual SMSC: 1) Support for unsolicited indication that an SMS has been received by the modem. Kannel looks for a '+CMT' (Communication:MT) or '+CDS' (Communication:DELIVER_SM) unsolicited response from the modem to know when to query the modem for an incoming SMS. 2) Ability to send PDU encoded SMS instead of Text. This means that the modem must be able to accept an 'AT+CMGF=0'. To do a quick test: 1) connect to the modem 2) issue the following AT commands: AT+CMGF=1 ---Changes message format to textual AT+CMGS=+MSISDN ---Replace MSISDN with the destination address of a phone which will (hopefully) receive this SMS you are about to send This is a test message ctrl-Z -Type in a message to send and terminate the message with a Ctrl-Z character. Also, after issuing the AT+CMGS=..., you should get a '' prompt 3) If after the Ctrl-Z, you get and 'OK' prompt and you receive the SMS on your destination phone, then your modem supports sending SMS in text modem. 4) If your modem passed the first test, then try and see if it can understand sending SMS using PDU mode. Issue the following AT commands: AT+CMGF=0 5) If you get an 'OK' from the modem, then your modem supports requirement 2). You are half way there. If your modem passes the sending SMS and the mode switch to PDU mode, then chances are that it will work as a virtual SMSC. But, that does not mean it will work WELL as an virtual SMSC. Even well tested GSM modems (WAVECOM) have limitations and will not replace a true connection to a real SMSC. Regards, Davy Chan
Re: sending UDH
**From: Zohar [EMAIL PROTECTED] **To: [EMAIL PROTECTED] **Subject: sending UDH **Date: Mon, 9 Jun 2003 09:55:08 +0200 ** **Just tried (for the first time) to send a message with UDH and couldn't. I set a header in the HTTP POST message as follows: **X-Kannel-UDH: %06%05%04%15%82%00%00 ** **As a result of my request, Kannel sent an SMS message to another Kannel, which produced an HTTP message to an application I wrote that checks the headers. The X-Kannel-UDH header was missing. Why? ** From what I can remember, when sending an Operator Logo via HTTP POST, you will need the following headers: X-Kannel-Username: foo X-Kannel-Password: bar X-Kannel-To: +85212345678 X-Kannel-UDH: 0605041582 X-Kannel-Alt-DCS: 1 Content-Type: application/octet-stream Content-Length: 12 000102030405060708090A0B The above is a rough example. I don't think my octets will be a valid Operator Logo. Regards, Davy Chan
Re: Foo
**From: Zohar [EMAIL PROTECTED] **To: [EMAIL PROTECTED] **Subject: Foo **Date: Mon, 9 Jun 2003 11:51:28 +0200 ** **Why is there Foo in HTTP responses? Because that is the default HTTP comment from Kannel. Look at gwlib/http.c. See ya... d.c.
Re: post headers
**From: Zohar [EMAIL PROTECTED] **To: [EMAIL PROTECTED] **Subject: post headers **Date: Sun, 8 Jun 2003 07:18:10 +0200 ** **Hi, **When using the post-url method in the sms-service group, how do I specify which headers are sent (e.g., X-Kannel-From, X-Kannel-UDH, etc.) , or are all (available?) headers being sent always? The smsbox will look at the SMS and internal Kannel state information to determine what headers to put into the HTTP POST. The mandatory headers are: Content-Type: [ DC_7BIT | DC_8BIT | DC_UCS2 ] [DC_7BIT] = Content-Type: text/plain [DC_8BIT] = Content-Type: application/octet-stream [DC_UCS2] = Content-Type: text/plain; charset=UTF-16BE Content-Length: [ decimal_number ] X-Kannel-To: [ MSISDN ] X-Kannel-Time: [ -MM-DD HH:MM:SS ] X-Kannel-Time: 2003-02-27 13:48:03 X-Kannel-Service: [ sms-service_name ] X-Kannel-Service: OTP_responder If your sms-service includes the configuration: send-sender = true you will also receive the Sender's MSISDN via the X-Kannel-From header. If the SMS has a UDH then that will appear as a series or 2 digit HEX (%02X) numbers of the X-Kannel-UDH header. X-Kannel-UDH: [ TWO_DIGIT_HEX_NUMBERS ] RING TONE = X-Kannel-UDH: 06050415811581 LOGO = X-Kannel-UDH: 06050415821582 PICTURE MSG = X-Kannel-UDH: 060504158A158A GROUP GRAPHIC = X-Kannel-UDH: 06050415831583 (* Thanks to Shanavaz E A [EMAIL PROTECTED]. I hope there wasn't an NDA violation for releasing this info. ) If the Message Class is set: X-Kannel-MClass: [ decimal_number_0-4 ] MC_UNDEF = X-Kannel-MClass: 0 MC_CLASS0 = Non-Specific = X-Kannel-MClass: 1 MC_Class1 = ME-Specific = X-Kannel-MClass: 2 MC_Class2 = SIM-Specific = X-Kannel-MClass: 3 MC_Class3 = TE-Specific = X-Kannel-MClass: 4 If the Protocol ID is set: X-Kannel-PID: [ decimal_number_0-255 ] X-Kannel-PID: 0 If the Return Path Indicator is set: X-Kannel-RPI: [ decimal_number_0-1 ] X-Kannel-RPI: 1 If the Message Waiting Indicator is set: X-Kannel-MWI: [ decimal_number_0-8 ] MWI_UNDEF = X-Kannel-MWI: 0 MWI_VOICE_ON = X-Kannel-MWI: 1 MWI_FAX_ON= X-Kannel-MWI: 2 MWI_EMAIL_ON = X-Kannel-MWI: 3 MWI_OTHER_ON = X-Kannel-MWI: 4 MWI_VOICE_OFF = X-Kannel-MWI: 5 MWI_FAX_OFF = X-Kannel-MWI: 6 MWI_EMAIL_OFF = X-Kannel-MWI: 7 MWI_OTHER_OFF = X-Kannel-MWI: 8 If the message is compressed: X-Kannel-Compress: [ decimal_number_0-1 ] X-Kannel-Compress: 1 If the Validity period is set: X-Kannel-Validity: [ decimal_number_0-255 ] X-Kannel-Validity = 0 to 143: (VP + 1) x 5 minutes (up to 12 hrs) X-Kannel-Validity = 144 to 167: 12 hrs ((VP-143) x 30 minutes) X-Kannel-Validity = 168 to 196: (VP - 166) x 1 day X-Kannel-Validity = 197 to 255: (VP - 192) x 1 week If the SMS is deferred: X-Kannel-Deferred: [ decimal_number_0-1 ] X-Kannel-Deferred: 1 These headers work also when submitting an SMS if accept-x-kannel-headers is set to true. Hopefully, I'll have enough time to finish my revisions for Kannel's userguide before a new official release is minted. Regards, Davy Chan
Re: Chinese Characters
**Subject: Chinese Characters **From: Chew Choon Keat [EMAIL PROTECTED] **To: [EMAIL PROTECTED] **Date: 03 Jun 2003 13:33:20 +0800 ** **Hi all, ** **I'll apologise first as I know this question must've popped up and **answered somewhere, however all the links I found were broken (e.g. **http://www.mail-archive.com/[EMAIL PROTECTED]/msg01599.html) ** **I've Kannel setup with CIMD2, it is receiving chinese input from mobiles **(I observe coding=2charset=binaryudh=). ** **However, I tried to retrieved the binary message and send it back to the **mobile via Kannel, **http://... coding=2charset=binaryudh=msg=Y%7DN%BAf%2Fb%11 ** **The phone won't display. Anyone knows the correct parameters to send **chinese SMS? ** **Help is much appreciated! Try setting the coding to 3 (DC_UCS2), eliminating the charset specification, and changing msg to text: http://...coding=3text=Y%7DN%BAf%2Fb%11 Also, make sure this is a HTTP GET and not a HTTP POST. Kannel doesn't seem to parse the URL arguments when it receives a POST. See ya... d.c.
