Re: Incorrect DLR mapping in kannel 1.5.0
Am 24.11.2014 11:11, schrieb Tanja Kipreska:
First 3 DLRs were with status=1(DELIVERED) and the 4th DLR was with
status=2 (EXPIRED). Here are access.log details for the MSISDN I've
tested with:
2014-11-20 11:21:11 Sent SMS [SMSC:smsc4.7] [SVC:bulk] [ACT:] [BINF:]
[FID:9223372036854775807] [META:] [from:ONE] [to:076514006]
[flags:1:0:-1:-1:3] [msg:15:Test za DLR ONE] [udh:0:]
2014-11-20 11:23:17 Receive DLR [SMSC:smsc4.7] [SVC:bulk] [ACT:vasgw]
[BINF:] [FID:9223372036854775807] [META:?smpp?dlr_err=%03%00%00]
[from:ONE] [to:076514006] [flags:-1:-1: -1:-1:1]
[msg:126:id:ff02553314cb sub:001 dlvrd:001 submit date:1411201123
done date:1411201123 stat:DELIVRD err:0 text:message Pocituvani t] [udh:0:]
your 'msg-id-type' in the 'group = smsc' is messed up. As we see the
foreign ID we got back from the submit_sm is 9223372036854775807, which
is exactly the upper max value of the int64_t type, hence the long
value we use to store if submit_sm_resp.message_id is interpreted as
integer.
Please review what msg ID type you get back in
submit_sm_resp.mesage_status. If it is the SAME as in the deliver_sm
(DLR) PDUs, then you have obviously set some 'msg-id-type' that messes
things up.
Stipe
--
---
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
---
Incorrect DLR mapping in kannel 1.5.0
Dear Kannel users, We have a problem with incorrect delivery reports mapping in kannel 1.5.0. Problem is not constant and it usually occurs when there is increased number of AO-MT SMSes sent from various senders (originating addresses) that are requesting DLRs. I have managed to reproduce the problem with following test. In the busy hour (period when there is increased number of SMSes requesting DLR from kannel) I have sent 4 SMSes (requesting DLR) to detached mobile subscriber. Surprisingly (within several minutes) dlr-url that I have set in messages towards detached subscriber was called 4 times, although SMSes were still waiting to be delivered on the SMSC. I have analyzed SMPP communication between SMS gateway (kannel) and SMSC for the period when test was conducted and SMSC does everything correctly. We are using kannel 1.5.0 svn version from 25.07.2012 and mysql 5.0.95 for external dlr storage. Please advise what might be causing this irregular behavior. Looking forward to your answer, Tanja
Re: Incorrect DLR mapping in kannel 1.5.0
First 3 DLRs were with status=1(DELIVERED) and the 4th DLR was with status=2 (EXPIRED). Here are access.log details for the MSISDN I've tested with: 2014-11-20 11:21:11 Sent SMS [SMSC:smsc4.7] [SVC:bulk] [ACT:] [BINF:] [FID:9223372036854775807] [META:] [from:ONE] [to:076514006] [flags:1:0:-1:-1:3] [msg:15:Test za DLR ONE] [udh:0:] 2014-11-20 11:23:17 Receive DLR [SMSC:smsc4.7] [SVC:bulk] [ACT:vasgw] [BINF:] [FID:9223372036854775807] [META:?smpp?dlr_err=%03%00%00] [from:ONE] [to:076514006] [flags:-1:-1: -1:-1:1] [msg:126:id:ff02553314cb sub:001 dlvrd:001 submit date:1411201123 done date:1411201123 stat:DELIVRD err:0 text:message Pocituvani t] [udh:0:] 2014-11-20 11:36:46 Sent SMS [SMSC:smsc4.7] [SVC:bulk] [ACT:] [BINF:] [FID:9223372036854775807] [META:] [from:ONE] [to:076514006] [flags:1:0:-1:-1:3] [msg:15:Test za DLR ONE] [udh:0:] 2014-11-20 11:37:16 Receive DLR [SMSC:smsc4.7] [SVC:bulk] [ACT:vasgw] [BINF:] [FID:9223372036854775807] [META:?smpp?dlr_err=%03%00%00] [from:ONE] [to:076514006] [flags:-1:-1: -1:-1:1] [msg:126:id:ff0455332830 sub:001 dlvrd:001 submit date:1411201137 done date:1411201137 stat:DELIVRD err:0 text:message Pocituvani t] [udh:0:] 2014-11-20 11:39:53 Sent SMS [SMSC:smsc4.7] [SVC:bulk] [ACT:] [BINF:] [FID:9223372036854775807] [META:] [from:ONE] [to:076514006] [flags:1:0:-1:-1:3] [msg:15:Test za DLR ONE] [udh:0:] 2014-11-20 11:40:13 Receive DLR [SMSC:smsc4.7] [SVC:bulk] [ACT:vasgw] [BINF:] [FID:9223372036854775807] [META:?smpp?dlr_err=%03%06%00] [from:ONE] [to:076514006] [flags:-1:-1: -1:-1:1] [msg:126:id:ff082e0a7867 sub:001 dlvrd:001 submit date:1411200908 done date:1411201140 stat:DELIVRD err:0 text:message Pocituvani t] [udh:0:] 2014-11-20 11:40:54 Sent SMS [SMSC:smsc4.7] [SVC:bulk] [ACT:] [BINF:] [FID:9223372036854775807] [META:] [from:ONE] [to:076514006] [flags:1:0:-1:-1:3] [msg:15:Test za DLR ONE] [udh:0:] 2014-11-20 11:48:08 Receive DLR [SMSC:smsc4.7] [SVC:bulk] [ACT:vasgw] [BINF:] [FID:9223372036854775807] [META:?smpp?dlr_err=%03%06%00] [from:ONE] [to:076514006] [flags:-1:-1: -1:-1:2] [msg:127:id:ff05551a6099 sub:001 dlvrd:001 submit date:1411151148 done date:1411201148 stat:EXPIRED err:58 text:message Pocituvani t] [udh:0:] I am forwarding you details, SMPP deliver_sm PDUs received from the SMSC, that kannel mapped into last 3 DLRs shown above. As you can see from the attached traces, DLRs are intended for completely different initiated SMSes (they have different originating and destination addresses). Please note that traces(tcdumps) are taken from the production environment (having commercial MSISDNs)thus i had to obfuscate them in the provided traces. At your disposal for further clarifications, Tanja On Mon, Nov 24, 2014 at 9:19 AM, Christopher Burke christopher.bu...@simulity.com wrote: When the DLR-URL was called 4 times, what was the status of the DLR (ACCEPTED/DELIVRD/ERROR etc). I suspect you’ll need to provide logs configuration for additional assistance. Cheers, *Christopher Burke*http://simulity.com Office: +44 (0) 1248 679 281 Fax: +44 (0) 1248 660 323 Skype:krslynx *UK*Unit 8, Ash Court, Parc Menai, Bangor, Gwynedd, LL57 4DF, Wales, UK *Malaysia*Level 30, The Gardens North Tower, Mid Valley City, Lingkaran Syed Putra, 59200, Kuala Lumpur, Malaysia NOTICE: This message contains privileged confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error, please notify Simulity Labs immediately. Any views expressed in this message are those of the individual sender except where the sender specifically states them to be the view of Simulity Labs On 24 November 2014 at 08:03:22, Tanja Kipreska (tanja.kipre...@gmail.com) wrote: Dear Kannel users, We have a problem with incorrect delivery reports mapping in kannel 1.5.0. Problem is not constant and it usually occurs when there is increased number of AO-MT SMSes sent from various senders (originating addresses) that are requesting DLRs. I have managed to reproduce the problem with following test. In the busy hour (period when there is increased number of SMSes requesting DLR from kannel) I have sent 4 SMSes (requesting DLR) to detached mobile subscriber. Surprisingly (within several minutes) dlr-url that I have set in messages towards detached subscriber was called 4 times, although SMSes were still waiting to be delivered on the SMSC. I have analyzed SMPP communication between SMS gateway (kannel) and SMSC for the period when test was conducted and SMSC does everything correctly. We are using kannel 1.5.0 svn version from 25.07.2012 and mysql 5.0.95 for external dlr storage. Please advise what
Re: Incorrect DLR mapping in kannel 1.5.0
Dear Tanja Please dont post to multiple mailing lists at the same time. I looked at your traceilfe 20.11.2014_11_48_08: There’s a few things which are abnormal. originator is empty (0x00) destination is alphanumeric “38970ZZ” in a DLR the originator and destination should match the original SMS send but be swapped in direction Above would mean that the originator alphanumeric sender “38970ZZ send a message to a non existing number 0x00. That doesn’t make sense. The SMSC identifier is FF05551a6099 which hints a 32bit/64bit integer conversion with negative numbers could be lurking around the corner. This is a valid identifier but maybe not the one you originally got when sending the message. You should check the submit_sm_ack which matches that specific message to see what’s returned there. if its the same then its ok. the status says the messasge is EXPIRED. the network error code is 0x600 as GSM error type. However GSM-MAP doesn’t have such an error code. If the bits are considered as little endian instead of big endian, then the error code would be 06 which is absent subscriber which would at least make some sense. the message indicated is not in the DLR text below. Kannel can not find this message as it uses message-id (also known as “timestamp”) + destination number to match it in the DLR database but there is no such entry (unless you send to a empty number). I would question the implementation of the SMSC you are connecting to. On 24 Nov 2014, at 11:11, Tanja Kipreska tanja.kipre...@gmail.com wrote: First 3 DLRs were with status=1(DELIVERED) and the 4th DLR was with status=2 (EXPIRED). Here are access.log details for the MSISDN I've tested with: 2014-11-20 11:21:11 Sent SMS [SMSC:smsc4.7] [SVC:bulk] [ACT:] [BINF:] [FID:9223372036854775807] [META:] [from:ONE] [to:076514006] [flags:1:0:-1:-1:3] [msg:15:Test za DLR ONE] [udh:0:] 2014-11-20 11:23:17 Receive DLR [SMSC:smsc4.7] [SVC:bulk] [ACT:vasgw] [BINF:] [FID:9223372036854775807] [META:?smpp?dlr_err=%03%00%00] [from:ONE] [to:076514006] [flags:-1:-1: -1:-1:1] [msg:126:id:ff02553314cb sub:001 dlvrd:001 submit date:1411201123 done date:1411201123 stat:DELIVRD err:0 text:message Pocituvani t] [udh:0:] 2014-11-20 11:36:46 Sent SMS [SMSC:smsc4.7] [SVC:bulk] [ACT:] [BINF:] [FID:9223372036854775807] [META:] [from:ONE] [to:076514006] [flags:1:0:-1:-1:3] [msg:15:Test za DLR ONE] [udh:0:] 2014-11-20 11:37:16 Receive DLR [SMSC:smsc4.7] [SVC:bulk] [ACT:vasgw] [BINF:] [FID:9223372036854775807] [META:?smpp?dlr_err=%03%00%00] [from:ONE] [to:076514006] [flags:-1:-1: -1:-1:1] [msg:126:id:ff0455332830 sub:001 dlvrd:001 submit date:1411201137 done date:1411201137 stat:DELIVRD err:0 text:message Pocituvani t] [udh:0:] 2014-11-20 11:39:53 Sent SMS [SMSC:smsc4.7] [SVC:bulk] [ACT:] [BINF:] [FID:9223372036854775807] [META:] [from:ONE] [to:076514006] [flags:1:0:-1:-1:3] [msg:15:Test za DLR ONE] [udh:0:] 2014-11-20 11:40:13 Receive DLR [SMSC:smsc4.7] [SVC:bulk] [ACT:vasgw] [BINF:] [FID:9223372036854775807] [META:?smpp?dlr_err=%03%06%00] [from:ONE] [to:076514006] [flags:-1:-1: -1:-1:1] [msg:126:id:ff082e0a7867 sub:001 dlvrd:001 submit date:1411200908 done date:1411201140 stat:DELIVRD err:0 text:message Pocituvani t] [udh:0:] 2014-11-20 11:40:54 Sent SMS [SMSC:smsc4.7] [SVC:bulk] [ACT:] [BINF:] [FID:9223372036854775807] [META:] [from:ONE] [to:076514006] [flags:1:0:-1:-1:3] [msg:15:Test za DLR ONE] [udh:0:] 2014-11-20 11:48:08 Receive DLR [SMSC:smsc4.7] [SVC:bulk] [ACT:vasgw] [BINF:] [FID:9223372036854775807] [META:?smpp?dlr_err=%03%06%00] [from:ONE] [to:076514006] [flags:-1:-1: -1:-1:2] [msg:127:id:ff05551a6099 sub:001 dlvrd:001 submit date:1411151148 done date:1411201148 stat:EXPIRED err:58 text:message Pocituvani t] [udh:0:] I am forwarding you details, SMPP deliver_sm PDUs received from the SMSC, that kannel mapped into last 3 DLRs shown above. As you can see from the attached traces, DLRs are intended for completely different initiated SMSes (they have different originating and destination addresses). Please note that traces(tcdumps) are taken from the production environment (having commercial MSISDNs)thus i had to obfuscate them in the provided traces. At your disposal for further clarifications, Tanja On Mon, Nov 24, 2014 at 9:19 AM, Christopher Burke christopher.bu...@simulity.com mailto:christopher.bu...@simulity.com wrote: When the DLR-URL was called 4 times, what was the status of the DLR (ACCEPTED/DELIVRD/ERROR etc). I suspect you’ll need to provide logs configuration for additional assistance. Cheers, Christopher Burke http://simulity.com http://simulity.com/ Office: +44 (0) 1248 679 281 tel:%2B44%20%280%29%201248%20679%20281 Fax: +44 (0) 1248 660 323 tel:%2B44%20%280%29%201248%20660%20323
