Home » Support

PDU Decoder bug with 7bit multi part pdu

Posted August 13th, 2008 by alionline759

hi
i have a 3part ems that has pdu like :
0791893905004200C40C91893946759373000080802101802149A005000300030190E9311AB40ECF41E1397A9D0689C3F270BE0C6A8741EEB03CBD46D341E8B01CB42E83C461503B0C12D7C9A0B01ED40E83DAE9F35B9E5EA3E9A0213AEC2683E4757D7A4E07ADCB2074981D6E83C86972D89D9ED341C830BB0C6A87DDA0B01E9476BF41613708FE96CFD3E4B03B3DA7838E6134481C9683E4F57C19A40FB7D36E90FECD06B5D3
0791893905004200C00C91893946759373000080802101805149A0050003000302F46177B80D3A87D12071580E4287CD653D881E36874F6F36A89DD687DDE13608193697F56510396D0FBBCB2073981D6E83E461D0B92C2F9BE9A06C790D3AA3C3FA301B146E87C9A07519840EB3C36D903C0C3A97E56533DD053ABECD74503B0CD29741F9B03CEC068DD1E539BA5D06E5C3F234881C9EA3E9E93668897E93416774981DA683C4
0791893905004200E40C918939467593730000808021018071491C050003000303EA6450D83D469741ED34BCEC2687E7687ABA0D
i pass these pdus separately but pdu decoder decode it incorrect .
please correct this bug
i use first pdu string in pduspy and it's result was correct like this:
PDU LENGTH IS 167 BYTES
ADDRESS OF DELIVERING SMSC
NUMBER IS : +989350002400
TYPE OF NR. : (0x10) International
NPI : (0x01) ISDN/Telephone (E.164/163)

MESSAGE HEADER FLAGS (0xC4)
MESSAGE TYPE : SMS DELIVER
MSGS WAITING IN SC : NO
REQ. STATUS REPORT : NO
USER DATA HEADER : PRESENT
REPLY PATH : REQUESTED

ORIGINATING ADDRESS
NUMBER IS : +989364573937
TYPE OF NR. : (0x10) International
NPI : (0x01) ISDN/Telephone (E.164/163)

PROTOCOL IDENTIFIER (0x00)
MESSAGE ENTITIES : SME-to-SME
PROTOCOL USED : Implicit / SC-specific

DATA CODING SCHEME (0x00)
COMPRESSION : OFF
MESSAGE CLASS : NONE
ALPHABET USED : 7bit default

SMSC TIMESTAMP : 12/08/08 10:08:12 GMT-3.50

USER DATA PART OF SM
USER DATA LENGTH : 160 septets
UDH LENGTH : 5
UDH : 00 03 00 03 01
UDH ELEMENTS : 00 SM CONCATENATION 8BIT REF.
03 Bytes Information Element
000 SM reference number
003 number of messages
001 this SM sequence number
USER DATA (TEXT) : Hich kas ashki baraye ma narikht har ke
ba ma bud az ma migorikht Chand ruzist
ke halam didanist Hale man az ino an
porsidanist Gah bar ruye zamin zol mi

‹ EMS - cant decode properly Need open source for JCellBrowser in J2ME ›

bug on EMS_RECEIVED class @ GetOriginalData in TP_UDHL

On October 6th, 2008 lamy says:

after decoding a long pdu code i found out the problem which was causing this and its the EMS_RECEIVED class, however, my fix is only temporary and doing this will result to a missing first letter character which is not desirable for those who uses keywords as first word of the message

anyway, this is what i tried

Class: EMS_RECEIVED
Method: GetOriginalData
Affected line: TP_UDHL = GetByte(PduCode)


Temporary fix: adding TP_UDHL += 1 after the affected line (which will result to 6 and not 5)

Sample PDU code:
0791361908006041440C91362938266993000080016091717523A0050003770201A8E832285E4F8FD720B1FC7D7783CC6F3C485D6FC3E7A0B7BD2C07D1D165103BACCF83C8EFB30B042DD3CB72103C0D2FCB41F0F4785D2683C2207879BC06BDCD20787ABC6697C92078190E2FCB5DA020E85C76D3D965D0FD2D2783DEF0B27B0E0ABB4169F9DB0D3A87E96517E85A0685E565101D5D068DD1E1363CFD76CF5DA0E71B0DCA97C3

SMSC ADDRESS: +639180000614
ADDRESS TYPE: 0x91
TYPE OF NUMBER: 0x01 (International)
NUMBERING PLAN: 0x01 (ISDN/telephone)

MESSAGE FLAGS: 0x44 (68)
MESSAGE TYPE: SmsDeliver
MORE MESSAGES: YES
STATUS REPORT: NO
USER DATA HEADER: YES
REPLY PATH: NO

ORIGINATING ADDRESS: +639283629639
ADDRESS TYPE: 0x91
TYPE OF NUMBER: 0x01 (International)
NUMBERING PLAN: 0x01 (ISDN/telephone)

PROTOCOL ID: 0x00 (SME-to-SME protocol)

DATA CODING SCHEME: 0x00
CODING GROUP: 0x00 (General Coding)
COMPRESSED: NO
CLASS SPECIFIED: NO
ALPHABET: 0x00 (Default alphabet)
RESERVED: 0x00

SMSC TIMESTAMP: 10/6/2008 7:17:57 PM +0800

USER DATA LENGTH: 160
UDH LENGTH: 6
UDH: 050003770201

again, this is a temporary fix (use at your own risk), from what i read UDH length can vary depending on the device and application used, in J2ME its sometimes 6 or 7, with my test it is always 6 but retrieved as 5