Re: Two (possible) bugs with 1.4.0

Davy Chan <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
Answers are inline...

**>From: "Johann du Preez" <[email protected]>
**>To: <[email protected]>
**>Subject: Two (possible) bugs with 1.4.0
**>Date: Thu, 3 Feb 2005 08:57:03 +0200
**>
**>Hi,
**>
**>I installed Kannel 1.4.0 on a Fedora core 2 box and it is working fine. 
**>Thanks for all your efforts.
**>
**>However, I discovered the following two things which I think may be bugs:
**>
**>1.  I use postgresql (v 7.4.6) for dlr-storage, as can be seen from my 
**>config file below.  However, I get the following error when it seems that 
**>Kannel wants to delete the entries from the database:
**>
**>2005-02-01 07:41:08 [1628] [6] ERROR: PGSQL: DELETE FROM dlr WHERE 
**>smsc='vodacom' AND ts='01/00/213d14b8/1127828553923' LIMIT 1;
**>2005-02-01 07:41:08 [1628] [6] ERROR: PGSQL: ERROR:  syntax error at or 
**>near "LIMIT" at character 76
**>2005-02-01 07:41:08 [1628] [6] ERROR: PGSQL: DB update failed!

Yup!  Definitely a bug.  PostgreSQL only supports the 'LIMIT'
parameter for 'SELECT'. Neither 'DELETE' nor 'UPDATE' supports
the 'LIMIT' parameter.

Post a bug report to the Mantis system:
  http://bugs.kannel.org

The quick remedy would be to remove the 'LIMIT 1' from the sql command
in gateway/gw/dlr_pgsql.c:dlr_pgsql_remove() and
gateway/gw/dlr_pgsql.c:dlr_pgsql_update().  But, this would have
possible ramifications to people using 'cimd2', 'emi', and 'oisd' SMSCs.
The 'ts' variable (TimeStamp) is really a timestamp for them. That
means if their bearerbox sends more than 1 SMS per second to
the same destination address, they will not have unique 'ts'
values.  As a result, all the dlr_entry that match the same
smsc, ts, and destination address will be updated/removed!

Hopefully, we can fix this by adding the sms.id UUID which was
added to Kannel in v1.3.2.

If you are using an 'at' or 'smpp' (which, in your instance, you are),
then you can safely remove the 'LIMIT 1' from the two functions since
the SMPP server will return unique message-ids that the bearerbox
will use for the 'ts' variable.

**>
**>2.  I cannot, for the life of me, get aliases to work for sms-services. 
**>None of the aliases for any of the services specified below works.
**>
**>Thanks again for a great piece of software.
**>
**>Johann
**>
**>kannel.conf
**>========

  [ ... lines delete ... ]

**>group = sms-service
**>name = sdt
**>keyword = sdt
**>aliases = shinfo;sharedata
**>url = "http://22.22.22.22/jse/scripts/sd.asp?ticker=%s"
**>catch-all = true
**>omit-empty = true
**>
**>
**>group = sms-service
**>name = slots
**>keyword = slots
**>aliases = spin;play
**>url = "http://localhost:8080/play?cell=%p"
**>catch-all = true
**>omit-empty = true
**>
**>
**>#A simple test service
**>group = sms-service
**>name = nop
**>keyword = nop
**>text = "You asked nothing and I did it!"
**>
**># SMS SERVICE Default
**># there should be default always
**>group = sms-service
**>keyword = default
**>text = "No service specified.  Please try again."

  [ ... lines delete ... ]

Are you getting UCS2 encoded SMS? UCS2 encoding uses 2 bytes
to encode the characters.  "slots" as you defined in your
configuration file looks like this to the smsbox:
  734C6F7473
If you received a UCS2 encoded SMS of "slots", it would come out
looking like this to the smsbox:
  0073004C006F00740073

That would not match your keywords nor your aliases since the smsbox
does a byte-by-byte comparison.

If it is a UCS2 problem, then you can easily resolve the issue by
adding "mo-recode = true" to your "group = smsbox". This will tell the
bearerbox to attempt to convert the UCS2 input to UTF-8 iso-8859-1
before passing the SMS to the smsbox.

See ya...

d.c.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.