Multipart SMS DELIVERY problem

prog019 · Post by **prog019** » Fri Nov 06, 2009 4:48 pm

Hello,

I am sending sms to short number and my smpp client get 2 DELIVER_SM

8:36:03 PM: Received Data: 0000014c00000005000000000216808f00010133373439333630303431350002013230323600c00000000000000100000424011830353030303330303032303138454144373339393045414143333431434644363142354537363833463245464241314335344345393745374130363745423544413738334445363635304645354439373833433436353332383844383232383746333230373437383045393241374537363537374233443532454342453537393130334236443245383339454144333739423043323243424342453146363143333441454237343137343739424430433932423645344539373931393234303043444431363937373139453436434239434237373930353945453236434634314339353639413543304538334445363631303342364432453833443436373137423137443837394635443431333539444443304542423845
8:36:03 PM: DeliverSm received :  Sequence : 35029135 SourceAddr : 37493600415 Sequence Number: 35029135 Total Segments : 0 Coding : 1 MessageText : 0500030002018EAD73990EAAC341CFD61B5E7683F2EFBA1C54CE97E7A067EB5DA783DE6650FE5D9783C4653288D82287F32074780E92A7E76577B3D52ECBE579103B6D2E839EAD379B0C22CBCBE1F61C34AEB7417479BD0C92B6E4E979192400CDD1697719E46CB9CB779059EE26CF41C9569A5C0E83DE66103B6D2E83D46717B17D879F5D41359DDC0EBB8E
8:36:03 PM: Sending Data: 0000001180000005000000000216808f00
8:36:05 PM: DeliverSm received :  Sequence : 48201871 SourceAddr : 37493600415 Sequence Number: 48201871 Total Segments : 0 Coding : 1 MessageText : 050003000202E0747598DCBED3E1675790DCBED3E1675710
8:36:05 PM: Received Data: 00000060000000050000000002df808f00010133373439333630303431350002013230323600c0000000000000010030303530303033303030323032453037343735393844434245443345313637353739304443424544334531363735373130
8:36:05 PM: Sending Data: 00000011800000050000000002df808f00

I have get from SMSC multi-part SMS, where "esm_class"
field has the UDHI indicator set, and the message contains a header and the user data.

To rebuild the split SMS the client have to check that if the UDHI indicator is set in the esm_class, then the source_addr of the SMPP deliver_sm is the common part of each SMPP message and the header indications of the message gives the part informations.

Dear Alt, how can do folowing with your LIB.

Can you help?

Thanks a lot
[/code]

Post by **alt** » Sun Nov 08, 2009 9:01 pm

It looks like your text in the message_payload field was encoded twice

f.i.
bytes array:
30353030303330303032303138454144373339393045414143333431434644363142354537363833463245464241314335344345393745374130363745423544413738334445363635304645354439373833433436353332383844383232383746333230373437383045393241374537363537374233443532454342453537393130334236443245383339454144333739423043323243424342453146363143333441454237343137343739424430433932423645344539373931393234303043444431363937373139453436434239434237373930353945453236434634314339353639413543304538334445363631303342364432453833443436373137423137443837394635443431333539444443304542423845

is encoded ANSII string "0500030002018EAD73990EAAC341CFD61B5E7683F2EFBA1C54CE97E7A067EB5DA783DE6650FE5D9783C4653288D82287F32074780E92A7E76577B3D52ECBE579103B6D2E839EAD379B0C22CBCBE1F61C34AEB7417479BD0C92B6E4E979192400CDD1697719E46CB9CB779059EE26CF41C9569A5C0E83DE66103B6D2E83D46717B17D879F5D41359DDC0EBB8E"

Can you explain how you get such messages?

Post by **alt** » Sun Nov 08, 2009 9:16 pm

What SMSC vendor type is sending such messages?

prog019 · Post by **prog019** » Mon Nov 09, 2009 5:01 am

Our SMSC vendor is HALYS.

I have short number, and I am get this response when tring sent SMS to this short number.

Thanks.

Post by **alt** » Mon Nov 09, 2009 9:29 am

I wonder, why they send such strange messages?

I remember you had problem with russian text as well.

Is it their vendor specific behaviour?

prog019 · Post by **prog019** » Mon Nov 09, 2009 11:32 am

I am not test this for RUSSIAN language.

I am have document from our vendor side, where

Code: Select all

9.2.3.23 

TP-User-Data-Header-Indicator (TP-UDHI)
The TP-User-Data-Header-Indicator is a 1 bit field within bit 6 of the first octet of the following six PDUs:
- SMS-SUBMIT,
- SMS-SUBMIT-REPORT
- SMS-DELIVER,
- SMS-DELIVER-REPORT
- SMS-STATUS-REPORT
- SMS-COMMAND.
TP-UDHI has the following values.
Bit no. 6 0 The TP-UD field contains only the short message
1 The beginning of the TP-UD field contains a Header in addition to the short message

9.2.3.24 

TP-User Data (TP-UD)
The length of the TP-User-Data field is defined in the PDU's of the SM-TL ( see subclause 9.2.2 ).
The TP-User-Data field may comprise just the short message itself or a Header in addition to the short message
depending upon the setting of TP-UDHI.
Where the TP-UDHI value is set to 0 the TP-User-Data field comprises the short message only, where the user data can
be 7 bit (default alphabet) data, 8 bit data, or 16 bit (UCS2) data.
Where the TP-UDHI value is set to 1 the first octets of the TP-User-Data field contains a Header in the following order
starting at the first octet of the TP-User-Data field.
Irrespective of whether any part of the User Data Header is ignored or discarded, the MS shall always store the entire
TPDU exactly as received.
FIELD LENGTH
Length of User Data Header 1 octet
Information-Element-Identifier "A" 1 octet
Length of Information-Element "A" 1 octet
Information-Element "A" Data 0 to "n" octets
Information-Element-Identifier "B" 1 octet
Length of Information-Element "B" 1 octet
Information-Element "B" Data 0 to "n" octets
Information-Element-Identifier "X" 1 octet
Length of Information-Element "X" 1 octet
Information-Element "X" Data 0 to "n" octets

The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed GSM 7 bit
default alphabet data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.

Please help, how implement this with ALT.SMS.SmppClient?

[/img]

prog019 · Post by **prog019** » Mon Nov 09, 2009 11:55 am

Previous information part is from
http://tim.kehres.com/docs/ts_100901v070500p.pdf

page 60-61

Post by **alt** » Mon Nov 09, 2009 11:58 am

It is standard which already implemented in the library, but you deliver_sm messages are not standart.

How do you send SMS to this short number?

Post by **alt** » Mon Nov 09, 2009 12:04 pm

Are you writing long text on mobile phone and send to short number?
Or are you building short messages in your application and send via GSM modem?

prog019 · Post by **prog019** » Mon Nov 09, 2009 12:28 pm

I am writing long text on mobile phone and send to short number

How can I in DELIVER_SM check if UDH is set, then get sms attributes from header , else check segmentation(current version in demo) ?

Post by **alt** » Mon Nov 09, 2009 12:41 pm

you can use properties

deliverSm.MessageReferenceNumber;
deliverSm.TotalSegments;
deliverSm.SegmentNumber;

they have values when parts information can be retrieved from UDH or from SAR option fields.

But in you case User Data is placed in message_payload and original byte array was prepresented as hex string and encoded like
byte[] message_payload_bytes = Encoding.ASCII.GetBytes(orig_hex_string);

i.e. properties value in your case are zero.

prog019 · Post by **prog019** » Mon Nov 09, 2009 12:48 pm

In other words, the problem is in SMSC?

Post by **alt** » Mon Nov 09, 2009 12:54 pm

yes, I think so

prog019 · Post by **prog019** » Wed Nov 11, 2009 11:59 am

Hello,

I am get an answer from vendor side:

smpp submit_sm put in the encoded data is not 7bit ascii gsm encoded, but 8 bit ascii

Dear Alt, are you sure?

Post by **alt** » Wed Nov 11, 2009 12:39 pm

Sorry,
but we talk about deliver_sm and problem with message_payload field content.

send you log from first post to vendor and ask why they encoded converted original bytes to hex string and then encoded it to 8 bit ASCII bytes array.