Kannel backend does not send messages with Kannel

Kannel backend (http://docs.rapidsms.org/en/develop/topics/backends/kannel.html) does not work with Kannel version 1.4.3 in its current form.

Mobile-originated (MO) messages are received properly, but mobile-terminated (MT) messages will not be sent.

MT messages are sent by the backend to kannel with the ‘fully qualified’ MSISDN (e.g., E.164 format with leading + and country code), but kannel misinterprets this number when a MT message. (Note: kannel is the one who sent rapidsms the E.164 formatted MSISDN to begin with!)

Kannel interprets the + as a url-encoded space character – which is a kannel default separator for passing multiple MSISDNs in the to field. Kannel returns a 403 Client Error: Forbidden and discards the message.

See http://www.kannel.org/download/1.4.3/userguide-1.4.3/userguide.html for more information:

Table 6-16. SMS Push (send-sms) CGI Variables
to      phone number list        Phone number of the receiver. To send to multiple receivers, separate each entry with space (' ', '+' url-encoded) - but note that this can be deactivated via sendsms-chars in the 'smsbox' group.

Here are some examples of this behavior:

# url-encoded MSISDN like rapidsms' kannel backend (via requests library)
$ curl 'http://127.0.0.1:13013/cgi-bin/sendsms?username=kannel&to=%2B256783370954&password=kannel&from=6400&text=foo+bar&smsc=yo&charset=ascii&coding=0'
Not routable. Do not try 

# non-url-encoded MSISDN
$ curl 'http://127.0.0.1:13013/cgi-bin/sendsms?username=kannel&to=[phone]&password=kannel&from=6400&text=foo+bar&smsc=yo&charset=ascii&coding=0'
0: Accepted for delivery

# url-encoded MSISDN without `+` 
$ curl 'http://127.0.0.1:13013/cgi-bin/sendsms?username=kannel&to=256783370954&password=kannel&from=6400&text=foo+bar&smsc=yo&charset=ascii&coding=0'
0: Accepted for delivery

I can’t find any way to configure kannel to use only, say, commas for separating multiple MSISDNs in the to field, so I believe rapidsms’ kannel backend must either:

1. remove the + before calling kannel’s sendsms url
2. rapidsms’ router should accept a configuration option such that internally only MSISDNs that are only digits (perhaps substituting any leading + with 00 to indicate that this is an internationally-dialable number with country code).

I lean toward option 1, as E.164-formatted numbers are really the best way to store MSISDNs as there is no ambiguity (a number in locally-dialable format may be a valid number in more than one country – and even a number in internationally-dialable format without the + may be a valid locally-dialable number in another country). Option 2 isn’t bad, though, as prefixing with 00 is pretty unambiguous as well – and I believe kannel can be configured to send numbers to rapidsms with a 00 prefix instead of +.

[ewheeler]

aha! this is an issue with our vendor’s smsc, which requires only digits. after additional experimentation and rereading the (incredibly cryptic) kannel docs, i’ve gotten the encoded + to be stripped by kannel before giving it to the smsc. the trick is to set unified-prefix = "-,+,00;" which replaces the + with 00 note that this also strips the + for all MSISDNs received by kannel too.

[ewheeler]

so, i noticed that i had also set an allowed-prefix-regex in the smsc group which did not have the \+? at the beginning.

after adding the \+? to the regex the following is consistently accepted for delivery… but the core kannel access log shows failure each time and the message is not delivered:

$ curl 'http://127.0.0.1:13013/cgi-bin/sendsms?username=kannel&to=%2B256783370954&password=kannel&from=6400&text=foo+bar+encoded&smsc=yo&charset=ascii&coding=0'
0: Accepted for delivery

FAILED Send SMS [SMSC:yo] [SVC:kannel] [ACT:] [BINF:] [FID:] [from:6400] [to:[phone]] [flags:-1:0:-1:-1:-1] [msg:15:foo bar encoded] [udh:0:]

Sending the non-encoded + is still successful, and the + is stripped when it is displayed in the access log–which seems to imply that only the digits are being sent to the smsc (same with sending just the digits without a +):

curl 'http://127.0.0.1:13013/cgi-bin/sendsms?username=kannel&to=[phone]&password=kannel&from=6400&text=foo+bar+not+encoded&smsc=yo&charset=ascii&coding=0'
0: Accepted for delivery

Sent SMS [SMSC:yo] [SVC:kannel] [ACT:] [BINF:] [FID:] [from:6400] [to:256783370954] [flags:-1:0:-1:-1:-1] [msg:19:foo bar not encoded] [udh:0:]

@jthurner @takinbo thanks for the help getting my kannel conf sorted out!

This is very strange. Perhaps this is an issue with our vendor’s smsc, as I’m now able to get the encoded + (as sent from rapidsms’ kannel backend) accepted for delivery by kannel. However, unless I come across some kannel settings that will avoid sending the + to the smsc, I’m not sure how to resolve this issue without modifying rapidsms’ kannel backend to remove the + before handing off to kannel