Problem processing OTA with UDH header missing

[Mladen Cvetkovic]

We are attempting to send an OTA to a terminal and return the POR. We use Restcomm 7.0.49 SMSC.

We see that the SMS is successfully delivered to the terminal (USIM) however the terminal is unable to process the OTA as the UDH header is missing.

When looking @ the MT-FORWARDSM message sent from the SMSC we see that the UDHI indicates the TP-UD contains only the short message and thus the UDH is never sent.

Following is the SUBMIT_SM

esmClass has bit 6 set to 1 and data_coding is set to 246

The UDH header is set to OTA '02 70 00'

2016-09-29 09:45:27 [942] [6] DEBUG: SMPP[cubic-smsc]: Sending PDU:

2016-09-29 09:45:27 [942] [6] DEBUG: SMPP PDU 0x7f03d8003630 dump:

2016-09-29 09:45:27 [942] [6] DEBUG:   type_name: submit_sm

2016-09-29 09:45:27 [942] [6] DEBUG:   command_id: 4 = 0x00000004

2016-09-29 09:45:27 [942] [6] DEBUG:   command_status: 0 = 0x00000000

2016-09-29 09:45:27 [942] [6] DEBUG:   sequence_number: 2748 = 0x00000abc

2016-09-29 09:45:27 [942] [6] DEBUG:   service_type: NULL

2016-09-29 09:45:27 [942] [6] DEBUG:   source_addr_ton: 1 = 0x00000001

2016-09-29 09:45:27 [942] [6] DEBUG:   source_addr_npi: 1 = 0x00000001

2016-09-29 09:45:27 [942] [6] DEBUG:   source_addr: "xxxxxxxxxx"

2016-09-29 09:45:27 [942] [6] DEBUG:   dest_addr_ton: 1 = 0x00000001

2016-09-29 09:45:27 [942] [6] DEBUG:   dest_addr_npi: 1 = 0x00000001

2016-09-29 09:45:27 [942] [6] DEBUG:   destination_addr: "xxxxxxxxxx"

2016-09-29 09:45:27 [942] [6] DEBUG:   esm_class: 67 = 0x00000043

2016-09-29 09:45:27 [942] [6] DEBUG:   protocol_id: 127 = 0x0000007f

2016-09-29 09:45:27 [942] [6] DEBUG:   priority_flag: 0 = 0x00000000

2016-09-29 09:45:27 [942] [6] DEBUG:   schedule_delivery_time: NULL

2016-09-29 09:45:27 [942] [6] DEBUG:   validity_period: "160929094527000+"

2016-09-29 09:45:27 [942] [6] DEBUG:   registered_delivery: 1 = 0x00000001

2016-09-29 09:45:27 [942] [6] DEBUG:   replace_if_present_flag: 0 = 0x00000000

2016-09-29 09:45:27 [942] [6] DEBUG:   data_coding: 246 = 0x000000f6

2016-09-29 09:45:27 [942] [6] DEBUG:   sm_default_msg_id: 0 = 0x00000000

2016-09-29 09:45:27 [942] [6] DEBUG:   sm_length: 77 = 0x0000004d

2016-09-29 09:45:27 [942] [6] DEBUG:   short_message:

2016-09-29 09:45:27 [942] [6] DEBUG:    Octet string at 0x7f03d8003820:

2016-09-29 09:45:27 [942] [6] DEBUG:      len:  77

2016-09-29 09:45:27 [942] [6] DEBUG:      size: 1024

2016-09-29 09:45:27 [942] [6] DEBUG:      immutable: 0

2016-09-29 09:45:27 [942] [6] DEBUG:      data: 02 70 00 00 48 15 16 21 15 15 b0 00 10 6e 0f c3   .p..H..!.....n..

2016-09-29 09:45:27 [942] [6] DEBUG:      data: 03 7b 2d d3 b2 12 96 86 74 cd 86 cf a1 6c 61 25   .{-.....t....la%

2016-09-29 09:45:27 [942] [6] DEBUG:      data: bf 40 8d 75 c6 ce 6b 46 8f 9a c7 ad be e4 f2 06   .@.u..kF........

2016-09-29 09:45:27 [942] [6] DEBUG:      data: 9f 0e 97 b8 1b 97 c4 ac b5 d6 ff 1d 42 67 7f ed   ............Bg..

2016-09-29 09:45:27 [942] [6] DEBUG:      data: 06 39 6f 18 4c a6 0f 3e 64 b8 9e 2f 9f            .9o.L..>d../.

2016-09-29 09:45:27 [942] [6] DEBUG:    Octet string dump ends.

2016-09-29 09:45:27 [942] [6] DEBUG: SMPP PDU dump ends.

Looking @ the MT-FORWARDSM message sent from the SMSC we see that the UDHI filed is set to 0 and the SMSC has not sent the header (this was verified also in wireshark but it is clear from the below it is not present).

2016-09-29 09:45:09,851 DEBUG [org.mobicents.protocols.sctp.AssociationImpl] (Thread-35) Tx : Ass=Association_103_11 PayloadData [dataLength=240, complete=true, unordered=false, payloadProtocolId=3, streamNumber=1, data=

Start: 0 (0x00)  End: 239 (0xEF)  Length: 240 (0xF0)

00: 01 00 01 01 00 00 00 F0  02 00 00 08 00 00 00 00 | ........ ........ 

10: 00 06 00 08 00 00 04 C1  02 10 00 D5 00 00 04 C1 | ........ ........ 

20: 00 00 04 BB 03 02 00 CA  09 01 03 0E 19 0B 12 08 | ........ ........ 

30: 00 12 04 53 83 75 00 10  07 0B 12 08 00 12 04 24 | ...S.u.. .......$ 

40: 63 15 00 10 08 A7 62 81  A4 48 04 00 00 00 D0 6B | c.....b. .H.....k 

50: 1E 28 1C 06 07 00 11 86  05 01 01 01 A0 11 60 0F | .(...... ......`. 

60: 80 02 07 80 A1 09 06 07  04 00 00 01 00 19 03 6C | ........ .......l 

70: 7C A1 7A 02 01 00 02 01  2C 30 72 80 08 92 05 06 | |.z..... ,0r..... 

80: 01 22 07 19 F2 84 07 91  24 63 15 00 10 08 04 5D | ."...... $c.....] 

90: 04 0C 91 24 63 15 00 10  08 7F F6 61 90 92 90 54 | ...$c... ...a...T 

A0: 90 48 4A 00 48 15 16 21  15 15 B0 00 10 6E 0F C3 | .HJ.H..! .....n.. 

B0: 03 7B 2D D3 B2 12 96 86  74 CD 86 CF A1 6C 61 25 | .{-..... t....la% 

C0: BF 40 8D 75 C6 CE 6B 46  8F 9A C7 AD BE E4 F2 06 | .@.u..kF ........ 

D0: 9F 0E 97 B8 1B 97 C4 AC  B5 D6 FF 1D 42 67 7F ED | ........ ....Bg.. 

E0: 06 39 6F 18 4C A6 0F 3E  64 B8 9E 2F 9F 00 00 00 | .9o.L..> d../.... 

]

Since bit 6 in the esmClass is set we are assuming that the SMSC will include the UDH and set the corresponding UDHI to indicate this.

Does anyone know what we are misconfiguring here or any solution to the problem.

NOTE: Full logs from SMSC available on request.

[Sergey Vetyutnev]

Hello Mladen,

my I ask you how do you upload your OTA message to SMSC GW. I suppose it is via SMPP protocol. Do you fill esm_class field - "UDHI Indicator set" bit ?
It will be the best if you provide encoded data (for example pcap trace) for message uploading part (for checking what happens in your concrete case).

[Mladen Cvetkovic]

Hi Sergey,

Thank you very much for the quick reply. We are using an OTA server which interfaces with Kannel SMPP server 1.4.4 and then with Restcomm SMSC via SMPP.

 

We see that when the UDHI bit is set the UDHI is not sent and vice versa, so the workaround we have employed at present is to set the esmClass to 0, which appears to be in direct violation of the standard.

From the SMSC perspective this is what we receive:

 

2016-09-28 13:14:10,090 DEBUG [org.mobicents.slee.container.activity.ActivityContext] (Test) Firing EventContext[event type id = EventTypeID[name=org.mobicents.resources.smpp.server.SUBMIT_SM,vendor=org.mobicents,version=1.0] , event = (submit_sm: 0x0000009E 0x00000004 0x00000000 0x0000011D) (body: (serviceType [] sourceAddr [0x01 0x01 [xxxxxxxxxxx]] destAddr [0x01 0x01 [xxxxxxxxxxxx]] esmCls [0x43] regDlvry [0x01] dcs [0xF6] message [02700000501516211515B0001087786566F3ED7C7334FB6724F1248389AE5F7BF43A7B13E2256008CD1281414B268F489200578F4FF7C5E2519BA8FAD5E7A15B5E8FB1FDB910F485568F4EFE611B6917B58F7013B6])) (opts: ) , local ac = RA:SmppServerRA:SmppTransactionHandle [smppSessionConfigurationName=Test, smppTransactionType=INCOMING, seqNumnber=285] , address = IP: localhost , serviceID = null]

 

Then we send the MT ForwardSM we see the UDHI header not present – UDH header = ’02 70 00’

 

2016-09-28 13:14:10,157 DEBUG [org.mobicents.protocols.sctp.AssociationImpl] (Thread-35) Tx : Ass=Association_103_11 PayloadData [dataLength=248, complete=true, unordered=false, payloadProtocolId=3, streamNumber=1, data=

Start: 0 (0x00)  End: 247 (0xF7)  Length: 248 (0xF8)

00: 01 00 01 01 00 00 00 F8  02 00 00 08 00 00 00 00 | ........ ........

10: 00 06 00 08 00 00 04 C1  02 10 00 DF 00 00 04 C1 | ........ ........

20: 00 00 04 BB 03 02 00 94  09 01 03 0E 19 0B 12 08 | ........ ........

30: 00 12 04 53 83 75 00 10  06 0B 12 08 00 12 04 24 | ...S.u.. .......$

40: 63 15 00 10 08 B1 62 81  AE 48 04 00 00 00 99 6B | c.....b. .H.....k

50: 1E 28 1C 06 07 00 11 86  05 01 01 01 A0 11 60 0F | .(...... ......`.

60: 80 02 07 80 A1 09 06 07  04 00 00 01 00 19 03 6C | ........ .......l

70: 81 85 A1 81 82 02 01 00  02 01 2C 30 7A 80 08 92 | ........ ..,0z...

80: 05 06 01 22 07 19 F2 84  07 91 24 63 15 00 10 08 | ...".... ..$c....

90: 04 65 04 0C 91 24 63 15  00 10 08 7F F6 61 90 82 | .e...$c. .....a..

A0: 31 41 01 48 52 00 50 15  16 21 15 15 B0 00 10 87 | 1A.HR.P. .!...... // START OF MESSAGE BODY

B0: 78 65 66 F3 ED 7C 73 34  FB 67 24 F1 24 83 89 AE | xef..|s4 .g$.$...

C0: 5F 7B F4 3A 7B 13 E2 25  60 08 CD 12 81 41 4B 26 | _{.:{..% `....AK&

D0: 8F 48 92 00 57 8F 4F F7  C5 E2 51 9B A8 FA D5 E7 | .H..W.O. ..Q.....

E0: A1 5B 5E 8F B1 FD B9 10  F4 85 56 8F 4E FE 61 1B | .[^..... ..V.N.a.

F0: 69 17 B5 8F 70 13 B6 00  -- -- -- -- -- -- -- -- | i...p...

]

 

When we force the esmClass to 0 we see that the UDHI header is set correctly and the UDH is included in the message body.

 

Starting routing for EventContext[event type id = EventTypeID[name=org.mobicents.resources.smpp.server.SUBMIT_SM,vendor=org.mobicents,version=1.0] , event = (submit_sm: 0x00000086 0x00000004 0x00000000 0x000000D0) (body: (serviceType [] sourceAddr [0x02 0x01 [423651000180]] destAddr [0x02 0x01 [423651438723]] esmCls [0x00] regDlvry [0x00] dcs [0xF6] message [02700000481516211515B000101EE61D86EE0F7E9C02E71BED88DB54FDDFD8433A63E710B0B99B2C8DFAD5443A1D75C36AC6BD326414FCA6F98FFBBFA1365A03074FC4C0225CBEDEED44CEAA14])) (opts: ) , local ac = RA:SmppServerRA:SmppTransactionHandle [smppSessionConfigurationName=Kannel, smppTransactionType=INCOMING, seqNumnber=208] , address = IP: localhost , serviceID = null]

 

Here we see the header successfully set and the UDH included in the message body also verified from Wireshark.

 

2016-09-29 16:27:46,096 DEBUG [org.mobicents.protocols.sctp.AssociationImpl] (Thread-35) Tx : Ass=Association_103_11 PayloadData [dataLength=252, complete=true, unordered=false, payloadProtocolId=3, streamNumber=1, data=

Start: 0 (0x00)  End: 251 (0xFB)  Length: 252 (0xFC)

00: 01 00 01 01 00 00 00 FC  02 00 00 08 00 00 00 00 | ........ ........

10: 00 06 00 08 00 00 04 C1  02 10 00 E1 00 00 04 C1 | ........ ........

20: 00 00 04 BB 03 02 00 1C  09 01 03 0E 19 0B 12 08 | ........ ........

30: 00 12 04 53 83 75 00 10  06 0B 12 08 00 12 04 24 | ...S.u.. .......$

40: 63 15 00 10 08 B3 62 81  B0 48 04 00 00 01 27 6B | c.....b. .H....'k

50: 1E 28 1C 06 07 00 11 86  05 01 01 01 A0 11 60 0F | .(...... ......`.

60: 80 02 07 80 A1 09 06 07  04 00 00 01 00 19 03 6C | ........ .......l

70: 81 87 A1 81 84 02 01 00  02 01 2C 30 7C 80 08 92 | ........ ..,0|...

80: 05 06 01 22 07 19 F2 84  07 91 24 63 15 00 10 08 | ...".... ..$c....

90: 04 67 44 0C A1 24 63 15  00 10 08 7F F6 61 90 92 | .gD..$c. .....a..

A0: 61 72 62 48 54 06 24 01  00 25 01 00 02 70 00 00 | arbHT.$. .%...p..

B0: 48 15 16 21 15 15 B0 00  10 1E E6 1D 86 EE 0F 7 | H..!.... .......~

C0: 9C 02 E7 1B ED 88 DB 54  FD DF D8 43 3A 63 E7 10 | .......T ...C:c..

D0: B0 B9 9B 2C 8D FA D5 44  3A 1D 75 C3 6A C6 BD 32 | ...,...D :.u.j..2

E0: 64 14 FC A6 F9 8F FB BF  A1 36 5A 03 07 4F C4 C0 | d....... .6Z..O..

F0: 22 5C BE DE ED 44 CE AA  14 00 00 00 -- -- -- -- | "\...D.. ....    

]

The question is why we need to NOT set the UDHI bit in SMPP in order to have the UDHI bit set in the MT Forward SM message? Your help is very much appreciated.

Thanks and Regards,

Mladen

[Sergey Vetyutnev]

Hello Mladen,

I have managed to reproduce the issue locally. This is because of a bug in MAP stack:
https://github.com/RestComm/jss7/issues/168

We need to solve it and then you need to use an updated version of JSS7 stack in your SMSC GW.

Thank you for your bug report !!!

> The question is why we need to NOT set the UDHI bit in SMPP in order to have the UDHI bit set in the MT Forward SM message? Your help is very much appreciated.

Let's do not try wrong ways to solve a problem. I have not reproduced the case when no UDH but UDHI bit is set. I mean in my case there is still no UDHI.

[Mladen Cvetkovic]

Hi Sergey,

Many Thanks in troubleshooting this issues with us and for locating the problem in the code. Would it be possible that you build a fix for us based on Restcomm 7.0.49 (and Jss7 version included into it, I think it was 7.0.1383)? Or provide instructions how to build a fix by us using 7.0.49 as baseline.

Thanks and Regards,

Mladen

[Sergey Vetyutnev]

Hello Mladen,

fixing of a problem may take some time.

Do you want to contribute the case? We need to update JSS7 code, release JSS7 binaries and switch smsc gw to them. If you can we can discuss details in the issue.

[Sergey Vetyutnev]

Hello Mladen,

please check this binaries: https://mobicents.ci.cloudbees.com/view/SS7/job/Restcomm-SMSC/84/artifact/release/
Does it work with your case ?