Re: Incorrect DLR mapping in kannel 1.5.0

Andreas Fink <[email protected]> Mon, 24 Nov 2014 11:36:57 +0100
Newsgroups	gmane.comp.mobile.kannel.devel
Message-ID	<[email protected]>
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 “38970ZZZZZZ”

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 “38970ZZZZZZ" send a message to a non existing number 0x00. That doesn’t make sense.


The SMSC identifier is FFFFFF05551a6099 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 <[email protected]> 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:ffffff02553314cb 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:ffffff0455332830 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:ffffff082e0a7867 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:ffffff05551a6099 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 <[email protected] <mailto:[email protected]>> 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>
> 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 ([email protected] <mailto:[email protected]>) 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 might be causing this irregular behavior.
>> 
>> Looking forward to your answer,
>> Tanja
>> 
> 
> <DLR_20.11.2014_11_48_08.cap><DLR_20.11.2014_11_40_13.cap><DLR_20.11.2014_11_37_16.cap>
signature.asc (application/pgp-signature, 841 B)