Search code examples
gsmat-commandpdu

Reading Multipart SMS with AT+CMGL using Wavecom modem

I try to read multipart sms in PDU mode. The message was in 3 parts

Below are PDUs I got by using command AT+CMGF=0 and AT+CMGL=4

Part1:07914150740250F7440B917130263521F600005140723295528AA005C01B5B0301B2E53C194D46A3C96834196D169BD16833DA8C368BCD62B3D82C368BCD62B3586C169BC566B1596C169BC562B3D82C368BCD62B3D82C368BCD62B3DBEC769BDD66B7D90D328B41663768DC0699DD66B7D96D769BDD66B7D96D76BBCD6EB3DBEC36BBCD6EB3DBEC36BBCD6EF7D96D769BDD67F7D96D769FDD67B7FBEC3EBBCFEEB3DB7D769FDD

Part2:07912160130320F8440B917130263521F600005140723295528AA005C01B5B0302CE6EB3DBEC56AB41D9729E8C26A3D164349A8C368BCD68B4196D469BC566B1596C169BC566B1592C368BCD62B3D82C368BCD62B1596C169BC566B1596C169BC566B1D96D76BBCD6EB3DBEC0699C520B31B346E83CC6EB3DBEC36BBCD6EB3DBEC36BBDD66B7D96D769BDD66B7D96D769BDD66B7FBEC36BBCDEEB3FBEC36BBCFEEB3DB7D769FDD

Part3:07914140540500F9440B917130263521F600005140723295528A1805C01B5B0303CEEEB3DB7D769FDD67B7D96D76ABD5

*According to my understanding, in order to identify if it's a multipart message I have to check if TP-UDHI is set where it's the sixth bit in first octet. In this case it's not set.

*The bold part of the PDU was the Data Header

*I thought in order to indicate this is a concatenate message it has to be 00 instead of C0?

Please correct me if I get it wrong..

Question 1: Why is the TP-UDHI not set in this case first octet was 07?

Question 2: Why the first octet in UDH is not 00 instead of C0?

Solution

  • Ok answering question 1) You missed spotting that right at the start of the PDU there is the SMSC address. So in fact your PDU header octet is 44. This indicates that there is a UDH present in the PDU.

    This is the SMSC address:

    07914150740250F7

    Directly thereafter is the PDU header 44.

    Regarding question 2) things get a little more complicated. Right now I am not spotting that the UDH contains any indication of a concatenated SMS. Don't forget that the UDH is not just for concatenated messages. It can contain lots of other information based on the 3GPP ETSI spec 03.40.

    After a closer look it looks like either the SMS was strangely encoded on the sending side or the mobile operator messed around with the UDH. You were correct isolating the UDH as:

    C01B5B0302

    Based upon the byte prior then the UDH length should be 5 bytes. But the first IEI (Information Element) is misleading. C0 defines the IEI as a SC specific IEI and not a concatenated IEI. Then the next by 1B says the IEI data should be 27 bytes long which contradicts the UDH length of 5.

    So from my perspective something mangled the UDH (which can happen with mobile operators, sms aggregators, or even bad encoders).

    If you would play around with what you have removing C01B and replacing with 0003 to ensure the 8-bit concat reference:

    00035b0301
00035B0302
00035B0303

    Then you would end up with a UDH telling you that the MR is 91 and the parts a correctly specified.