RE: Concatenation Problem in SMPP
"Oded Arbel" <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
If you've changed the behaviour of smsbox to solve a driver specific issue, in a non portable way - they heck yes : you broke something. your smsbox will probably not work with any other driver. nor with any other SMPP server except the comverse one, as IIRC the SMPP standard clearly states that short_message may not be longer then 160 characters. You're using a non compliant SMPP server, even if non-compliant in a good way, meaning - handles non-compliant clients. your "messages are received binary" is probably related to improer DCS setting. -- Oded Arbel m-Wise mobile solutions [email protected] +972-9-9581711 (116) +972-67-340014 ::.. In /dev/null no one can hear you scream -----Original Message----- From: Dedy Sutanto [mailto:[email protected]] Sent: Tuesday, September 17, 2002 11:04 AM To: [email protected] Cc: Oded Arbel Subject: RE: Concatenation Problem in SMPP The problem is, when I send plain SMS (7-bit) with length more than 160 (240) and smsbox split it and add UDHI, SMSC send me 2 binary messages. I thought, it because the UDH. Then I did a dirty hack in smsbox.c. I change value MAX_SMS_OCTETS from 140 to 1600. And try sending other plain SMS more than 160. It's work! I test for logo and ringtones which more than 160 characters. And it's work too. I don't know if my dirty hack will broke something or not. I don't know either if MMS implementation in my SMSC differs. (I use Comverse SMSC) It seem, SMSC done the concatenation. Regards -dedy- I attach kannel debug for plain SM 2002-09-17 13:27:00 [5] DEBUG: SMPP[smsc]: Sending PDU: 2002-09-17 13:27:00 [5] DEBUG: SMPP PDU 0x8103dd0 dump: 2002-09-17 13:27:00 [5] DEBUG: type_name: submit_sm 2002-09-17 13:27:00 [5] DEBUG: command_id: 4 = 0x00000004 2002-09-17 13:27:00 [5] DEBUG: command_status: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: sequence_number: 87 = 0x00000057 2002-09-17 13:27:00 [5] DEBUG: service_type: NULL 2002-09-17 13:27:00 [5] DEBUG: source_addr_ton: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: source_addr_npi: 1 = 0x00000001 2002-09-17 13:27:00 [5] DEBUG: source_addr: "778" 2002-09-17 13:27:00 [5] DEBUG: dest_addr_ton: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: dest_addr_npi: 1 = 0x00000001 2002-09-17 13:27:00 [5] DEBUG: destination_addr: "62818155112" 2002-09-17 13:27:00 [5] DEBUG: esm_class: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: protocol_id: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: priority_flag: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: schedule_delivery_time: NULL 2002-09-17 13:27:00 [5] DEBUG: validity_period: "0209171328000028" 2002-09-17 13:27:00 [5] DEBUG: registered_delivery: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: replace_if_present_flag: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: data_coding: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: sm_default_msg_id: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: sm_length: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: short_message: 2002-09-17 13:27:00 [5] DEBUG: Octet string at 0x8103e80: 2002-09-17 13:27:00 [5] DEBUG: len: 185 2002-09-17 13:27:00 [5] DEBUG: size: 186 2002-09-17 13:27:00 [5] DEBUG: immutable: 0 2002-09-17 13:27:00 [5] DEBUG: data: 41 41 41 41 31 32 33 34 AAAA1234 2002-09-17 13:27:00 [5] DEBUG: data: 35 36 37 38 39 30 31 32 56789012 2002-09-17 13:27:00 [5] DEBUG: data: 33 34 35 36 37 38 39 30 34567890 2002-09-17 13:27:00 [5] DEBUG: data: 31 32 33 34 35 36 37 38 12345678 2002-09-17 13:27:00 [5] DEBUG: data: 39 30 31 32 33 34 35 36 90123456 2002-09-17 13:27:00 [5] DEBUG: data: 37 38 39 30 31 32 33 34 78901234 2002-09-17 13:27:00 [5] DEBUG: data: 35 36 37 38 39 30 31 32 56789012 2002-09-17 13:27:00 [5] DEBUG: data: 33 34 35 36 37 38 39 30 34567890 2002-09-17 13:27:00 [5] DEBUG: data: 31 32 33 34 35 36 37 38 12345678 2002-09-17 13:27:00 [5] DEBUG: data: 39 30 31 32 33 34 35 36 90123456 2002-09-17 13:27:00 [5] DEBUG: data: 37 38 39 30 31 32 33 34 78901234 2002-09-17 13:27:00 [5] DEBUG: data: 35 36 37 38 39 30 31 32 56789012 2002-09-17 13:27:00 [5] DEBUG: data: 33 34 35 36 37 38 39 30 34567890 2002-09-17 13:27:00 [5] DEBUG: data: 31 32 33 34 35 36 37 38 12345678 2002-09-17 13:27:00 [5] DEBUG: data: 39 30 31 32 33 34 35 36 90123456 2002-09-17 13:27:00 [5] DEBUG: data: 37 38 39 30 31 61 73 64 78901asd 2002-09-17 13:27:00 [5] DEBUG: data: 6c 6a 6b 61 68 73 6c 6b ljkahslk 2002-09-17 13:27:00 [5] DEBUG: data: 64 68 6c 6c 6c 6c 6c 6c dhllllll 2002-09-17 13:27:00 [5] DEBUG: data: 6c 6c 6c 6c 6c 6c 6c 6c llllllll 2002-09-17 13:27:00 [5] DEBUG: data: 6c 6c 6c 6c 6c 6c 6c 6c llllllll 2002-09-17 13:27:00 [5] DEBUG: data: 6c 6c 6c 6c 6c 6c 32 33 llllll23 2002-09-17 13:27:00 [5] DEBUG: data: 34 35 36 37 38 39 30 31 45678901 2002-09-17 13:27:00 [5] DEBUG: data: 32 33 34 35 36 37 38 39 23456789 2002-09-17 13:27:00 [5] DEBUG: data: 30 0 2002-09-17 13:27:00 [5] DEBUG: Octet string dump ends. 2002-09-17 13:27:00 [5] DEBUG: SMPP PDU dump ends. 2002-09-17 13:27:00 [5] DEBUG: SMPP[smsc]: Sent PDU: 2002-09-17 13:27:00 [5] DEBUG: SMPP PDU 0x8103dd0 dump: 2002-09-17 13:27:00 [5] DEBUG: type_name: submit_sm 2002-09-17 13:27:00 [5] DEBUG: command_id: 4 = 0x00000004 2002-09-17 13:27:00 [5] DEBUG: command_status: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: sequence_number: 87 = 0x00000057 2002-09-17 13:27:00 [5] DEBUG: service_type: NULL 2002-09-17 13:27:00 [5] DEBUG: source_addr_ton: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: source_addr_npi: 1 = 0x00000001 2002-09-17 13:27:00 [5] DEBUG: source_addr: "778" 2002-09-17 13:27:00 [5] DEBUG: dest_addr_ton: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: dest_addr_npi: 1 = 0x00000001 2002-09-17 13:27:00 [5] DEBUG: destination_addr: "62818155112" 2002-09-17 13:27:00 [5] DEBUG: esm_class: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: protocol_id: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: priority_flag: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: schedule_delivery_time: NULL 2002-09-17 13:27:00 [5] DEBUG: validity_period: "0209171328000028" 2002-09-17 13:27:00 [5] DEBUG: registered_delivery: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: replace_if_present_flag: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: data_coding: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: sm_default_msg_id: 0 = 0x00000000 2002-09-17 13:27:00 [5] DEBUG: sm_length: 185 = 0x000000b9 2002-09-17 13:27:00 [5] DEBUG: short_message: 2002-09-17 13:27:00 [5] DEBUG: Octet string at 0x8103e80: 2002-09-17 13:27:00 [5] DEBUG: len: 185 2002-09-17 13:27:00 [5] DEBUG: size: 186 2002-09-17 13:27:00 [5] DEBUG: immutable: 0 2002-09-17 13:27:00 [5] DEBUG: data: 41 41 41 41 31 32 33 34 AAAA1234 2002-09-17 13:27:00 [5] DEBUG: data: 35 36 37 38 39 30 31 32 56789012 2002-09-17 13:27:00 [5] DEBUG: data: 33 34 35 36 37 38 39 30 34567890 2002-09-17 13:27:00 [5] DEBUG: data: 31 32 33 34 35 36 37 38 12345678 2002-09-17 13:27:00 [5] DEBUG: data: 39 30 31 32 33 34 35 36 90123456 2002-09-17 13:27:00 [5] DEBUG: data: 37 38 39 30 31 32 33 34 78901234 2002-09-17 13:27:00 [5] DEBUG: data: 35 36 37 38 39 30 31 32 56789012 2002-09-17 13:27:00 [5] DEBUG: data: 33 34 35 36 37 38 39 30 34567890 2002-09-17 13:27:00 [5] DEBUG: data: 31 32 33 34 35 36 37 38 12345678 2002-09-17 13:27:00 [5] DEBUG: data: 39 30 31 32 33 34 35 36 90123456 2002-09-17 13:27:00 [5] DEBUG: data: 37 38 39 30 31 32 33 34 78901234 2002-09-17 13:27:00 [5] DEBUG: data: 35 36 37 38 39 30 31 32 56789012 2002-09-17 13:27:00 [5] DEBUG: data: 33 34 35 36 37 38 39 30 34567890 2002-09-17 13:27:00 [5] DEBUG: data: 31 32 33 34 35 36 37 38 12345678 2002-09-17 13:27:00 [5] DEBUG: data: 39 30 31 32 33 34 35 36 90123456 2002-09-17 13:27:00 [5] DEBUG: data: 37 38 39 30 31 61 73 64 78901asd 2002-09-17 13:27:00 [5] DEBUG: data: 6c 6a 6b 61 68 73 6c 6b ljkahslk 2002-09-17 13:27:00 [5] DEBUG: data: 64 68 6c 6c 6c 6c 6c 6c dhllllll 2002-09-17 13:27:00 [5] DEBUG: data: 6c 6c 6c 6c 6c 6c 6c 6c llllllll 2002-09-17 13:27:00 [5] DEBUG: data: 6c 6c 6c 6c 6c 6c 6c 6c llllllll 2002-09-17 13:27:00 [5] DEBUG: data: 6c 6c 6c 6c 6c 6c 32 33 llllll23 2002-09-17 13:27:00 [5] DEBUG: data: 34 35 36 37 38 39 30 31 45678901 2002-09-17 13:27:00 [5] DEBUG: data: 32 33 34 35 36 37 38 39 23456789 2002-09-17 13:27:00 [5] DEBUG: data: 30 0 2002-09-17 13:27:00 [5] DEBUG: Octet string dump ends. 2002-09-17 13:27:00 [5] DEBUG: SMPP PDU dump ends. -----Original Message----- From: Oded Arbel [mailto:[email protected]] Sent: Tuesday, September 17, 2002 3:39 PM To: Dedy Sutanto; [email protected] Subject: RE: Concatenation Problem in SMPP the ESM setting is correct to enable UDHI (user data header indicator). AFAIK, the SMPP driver does not send MMS (this logic is actually out of scope for the driver as the smsbox is doing the splitting) but instead relies on the fact that splitted messages contain the correct UDH for concatenation as in the SMS standard [3GPP TS 23.040], which it does as you've noticed - the "additional field" you quote is indeed the UDH concatenation header. According to the SMS standard, the SMSC should not have any knowledge of concatenated messages, as splitting is done on the sending entity and composing is done on the receiving entity- the delivering entity should only route the message parts, not even necessary in the same order as they were sent. -- Oded Arbel m-Wise mobile solutions [email protected] +972-9-9581711 (116) +972-67-340014 ::.. capsule on reentry flickering match doused -----Original Message----- From: Dedy Sutanto [mailto:[email protected]] Sent: Tuesday, September 17, 2002 5:15 AM To: [email protected] Subject: Concatenation Problem in SMPP Dear all, I have done test for concatenation messages via SMPP. Here the scenario: 1.Turn on debug in smsc_smpp.c 2.Put Parameter in cfg file group sendsms-user: concatenation = true 3.Send SM via http interface with text more than 160 characters. Result - I found when kannel send concatenation messages, the ESM change to 67 - 0x00000043 (it should be 0). The result I received the SM with characters I cannot read. - From SMPP 3.4 Specification, the tag for more message to send (MMS) is optional parameter which must be put after the SM. But what I found here, the SM which send by kannel have additional field in beginning of message those are 05 00 03 07 02 01. The result, SMSC is not treating those messages as concatenation messages. I just wonder, do SMPP-MMS implementation in kannel followed the standard specification? I hope this information useful Regards -dedy- Result from debug kannel. 2002-09-17 08:55:25 [5] DEBUG: SMPP[smsc]: Sent PDU: 2002-09-17 08:55:25 [5] DEBUG: SMPP PDU 0x8103a90 dump: 2002-09-17 08:55:25 [5] DEBUG: type_name: submit_sm 2002-09-17 08:55:25 [5] DEBUG: command_id: 4 = 0x00000004 2002-09-17 08:55:25 [5] DEBUG: command_status: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: sequence_number: 78 = 0x0000004e 2002-09-17 08:55:25 [5] DEBUG: service_type: NULL 2002-09-17 08:55:25 [5] DEBUG: source_addr_ton: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: source_addr_npi: 1 = 0x00000001 2002-09-17 08:55:25 [5] DEBUG: source_addr: "779" 2002-09-17 08:55:25 [5] DEBUG: dest_addr_ton: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: dest_addr_npi: 1 = 0x00000001 2002-09-17 08:55:25 [5] DEBUG: destination_addr: "62818155112" 2002-09-17 08:55:25 [5] DEBUG: esm_class: 67 = 0x00000043 2002-09-17 08:55:25 [5] DEBUG: protocol_id: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: priority_flag: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: schedule_delivery_time: NULL 2002-09-17 08:55:25 [5] DEBUG: validity_period: NULL 2002-09-17 08:55:25 [5] DEBUG: registered_delivery: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: replace_if_present_flag: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: data_coding: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: sm_default_msg_id: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: sm_length: 159 = 0x0000009f 2002-09-17 08:55:25 [5] DEBUG: short_message: 2002-09-17 08:55:25 [5] DEBUG: Octet string at 0x8104118: 2002-09-17 08:55:25 [5] DEBUG: len: 159 2002-09-17 08:55:25 [5] DEBUG: size: 160 2002-09-17 08:55:25 [5] DEBUG: immutable: 0 2002-09-17 08:55:25 [5] DEBUG: data: 05 00 03 07 02 01 41 41 ......AA 2002-09-17 08:55:25 [5] DEBUG: data: 41 41 31 32 33 34 35 36 AA123456 2002-09-17 08:55:25 [5] DEBUG: data: 37 38 39 30 31 32 33 34 78901234 2002-09-17 08:55:25 [5] DEBUG: data: 35 36 37 38 39 30 31 32 56789012 2002-09-17 08:55:25 [5] DEBUG: data: 33 34 35 36 37 38 39 30 34567890 2002-09-17 08:55:25 [5] DEBUG: data: 31 32 33 34 35 36 37 38 12345678 2002-09-17 08:55:25 [5] DEBUG: data: 39 30 31 32 33 34 35 36 90123456 2002-09-17 08:55:25 [5] DEBUG: data: 37 38 39 30 31 32 33 34 78901234 2002-09-17 08:55:25 [5] DEBUG: data: 35 36 37 38 39 30 31 32 56789012 2002-09-17 08:55:25 [5] DEBUG: data: 33 34 35 36 37 38 39 30 34567890 2002-09-17 08:55:25 [5] DEBUG: data: 31 32 33 34 35 36 37 38 12345678 2002-09-17 08:55:25 [5] DEBUG: data: 39 30 31 32 33 34 35 36 90123456 2002-09-17 08:55:25 [5] DEBUG: data: 37 38 39 30 31 32 33 34 78901234 2002-09-17 08:55:25 [5] DEBUG: data: 35 36 37 38 39 30 31 32 56789012 2002-09-17 08:55:25 [5] DEBUG: data: 33 34 35 36 37 38 39 30 34567890 2002-09-17 08:55:25 [5] DEBUG: data: 31 32 33 34 35 36 37 38 12345678 2002-09-17 08:55:25 [5] DEBUG: data: 39 30 31 32 33 34 35 36 90123456 2002-09-17 08:55:25 [5] DEBUG: data: 37 38 39 30 31 32 33 34 78901234 2002-09-17 08:55:25 [5] DEBUG: data: 35 36 37 38 39 30 31 32 56789012 2002-09-17 08:55:25 [5] DEBUG: data: 33 34 35 36 37 38 39 3456789 2002-09-17 08:55:25 [5] DEBUG: Octet string dump ends. 2002-09-17 08:55:25 [5] DEBUG: SMPP PDU dump ends. 2002-09-17 08:55:25 [5] DEBUG: SMPP[smsc]: Manually forced source addr ton = 0, source add npi = 1 2002-09-17 08:55:25 [5] DEBUG: SMPP[smsc]: Manually forced dest addr ton = 0, source add npi = 1 2002-09-17 08:55:25 [5] DEBUG: SMPP[smsc]: Sending PDU: 2002-09-17 08:55:25 [5] DEBUG: SMPP PDU 0x8103a90 dump: 2002-09-17 08:55:25 [5] DEBUG: type_name: submit_sm 2002-09-17 08:55:25 [5] DEBUG: command_id: 4 = 0x00000004 2002-09-17 08:55:25 [5] DEBUG: command_status: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: sequence_number: 79 = 0x0000004f 2002-09-17 08:55:25 [5] DEBUG: service_type: NULL 2002-09-17 08:55:25 [5] DEBUG: source_addr_ton: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: source_addr_npi: 1 = 0x00000001 2002-09-17 08:55:25 [5] DEBUG: source_addr: "779" 2002-09-17 08:55:25 [5] DEBUG: dest_addr_ton: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: dest_addr_npi: 1 = 0x00000001 2002-09-17 08:55:25 [5] DEBUG: destination_addr: "62818155112" 2002-09-17 08:55:25 [5] DEBUG: esm_class: 67 = 0x00000043 2002-09-17 08:55:25 [5] DEBUG: protocol_id: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: priority_flag: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: schedule_delivery_time: NULL 2002-09-17 08:55:25 [5] DEBUG: validity_period: NULL 2002-09-17 08:55:25 [5] DEBUG: registered_delivery: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: replace_if_present_flag: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: data_coding: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: sm_default_msg_id: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: sm_length: 0 = 0x00000000 2002-09-17 08:55:25 [5] DEBUG: short_message: 2002-09-17 08:55:25 [5] DEBUG: Octet string at 0x8104168: 2002-09-17 08:55:25 [5] DEBUG: len: 17 2002-09-17 08:55:25 [5] DEBUG: size: 18 2002-09-17 08:55:25 [5] DEBUG: immutable: 0 2002-09-17 08:55:25 [5] DEBUG: data: 05 00 03 07 02 02 30 31 ......01 2002-09-17 08:55:25 [5] DEBUG: data: 32 33 34 35 36 37 38 39 23456789 2002-09-17 08:55:25 [5] DEBUG: data: 30 0 2002-09-17 08:55:25 [5] DEBUG: Octet string dump ends. 2002-09-17 08:55:25 [5] DEBUG: SMPP PDU dump ends.