Re: Linking UDH to text
Yes. Next time please read User's guide *before* addressing this list.
BR,
Nikos
- Original Message -
From: Kidi Kidi
To: users@kannel.org
Sent: Tuesday, March 16, 2010 2:07 AM
Subject: Linking UDH to text
Hi,
is there any way of sending udh={udh-headers}text={payload} just like
send={udh-headers}{payload} so i dont have to break up the messages.
SMPP delivery report issue
Hi, We are using Kannel more than two years and we are very satisfied. Now, we are using version 1.4.1. The configuration of the SMSC is following: group = smsc smsc = smpp smsc-id = xxx host = xxx.xxx.xxx.xxx port = 6400 transceiver-mode = true smsc-username = xx smsc-password = xx system-type = interface-version = 34 enquire-link-interval = 60 source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 msg-id-type = 0x00 throughput = 5 We are faceing a strange problem with delivery report. This is the log: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP[xxx]: Sending PDU: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU 0x13820e90 dump: 2010-03-15 14:43:21 [18509] [9] DEBUG: type_name: submit_sm 2010-03-15 14:43:21 [18509] [9] DEBUG: command_id: 4 = 0x0004 2010-03-15 14:43:21 [18509] [9] DEBUG: command_status: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sequence_number: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: service_type: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_ton: 5 = 0x0005 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr: 4120 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_ton: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: destination_addr: 38x 2010-03-15 14:43:21 [18509] [9] DEBUG: esm_class: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: protocol_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: priority_flag: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: schedule_delivery_time: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: validity_period: 100315134421000+ 2010-03-15 14:43:21 [18509] [9] DEBUG: registered_delivery: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: replace_if_present_flag: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: data_coding: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_default_msg_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_length: 144 = 0x0090 2010-03-15 14:43:21 [18509] [9] DEBUG: short_message: 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string at 0x13824de0: 2010-03-15 14:43:21 [18509] [9] DEBUG: len: 144 2010-03-15 14:43:21 [18509] [9] DEBUG: size: 145 2010-03-15 14:43:21 [18509] [9] DEBUG: immutable: 0 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 4b 75 70 69 6c 69 20 73 74 65 20 6b 61 72 74 75 Kupili ste kartu 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 62 72 6f 6a 20 20 37 30 34 37 39 32 20 7a 61broj 704792 za 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 76 6f 7a 69 6c 6f 20 42 47 39 20 6b 6f 6a 61vozilo BG9 koja 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 76 61 7a 69 20 64 6f 20 20 31 35 2e 30 33 2evazi do 15.03. 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 32 30 31 30 20 20 31 35 3a 34 33 20 2d 20 67 72 2010 15:43 - gr 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 61 64 20 50 6f 64 67 6f 72 69 63 61 2c 20 5a 6f ad Podgorica, Zo 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 6e 61 20 32 20 70 6f 20 63 65 6e 69 20 6f 64 20 na 2 po ceni od 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 30 2c 35 30 20 45 55 52 2e 20 53 61 63 75 760,50 EUR. Sacuv 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 61 6a 74 65 20 6f 76 75 20 70 6f 72 75 6b 75 2e ajte ovu poruku. 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP[xxx]: Got PDU: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU 0x13820e90 dump: 2010-03-15 14:43:21 [18509] [9] DEBUG: type_name: submit_sm_resp 2010-03-15 14:43:21 [18509] [9] DEBUG: command_id: 2147483652 = 0x8004 2010-03-15 14:43:21 [18509] [9] DEBUG: command_status: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sequence_number: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: message_id: 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string at 0x13824f70: 2010-03-15 14:43:21 [18509] [9] DEBUG: len: 20 2010-03-15 14:43:21 [18509] [9] DEBUG: size: 21 2010-03-15 14:43:21 [18509] [9] DEBUG: immutable: 0 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 36 2d 31 32 36 38 36 36 30 35 39 39 34 35 37 34 6-12686605994574 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 35 35 32 37 5527 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: DLR[internal]: Adding DLR smsc=xxx, ts=6, src=4120, dst=+38x, mask=31, boxc= 2010-03-15 14:43:21 [18509] [9] DEBUG: SMSC[xxx]: creating DLR message 2010-03-15 14:43:21 [18509] [9] DEBUG: SMSC[xxx]: DLR =
Re: SMPP delivery report issue
Yes, you're out of luck, you need to patch the source code to be able to parse it. Regards, Alex On Tue, Mar 16, 2010 at 10:18 AM, Drazen Kozic drazen.ko...@asw.eu wrote: Hi, We are using Kannel more than two years and we are very satisfied. Now, we are using version 1.4.1. The configuration of the SMSC is following: group = smsc smsc = smpp smsc-id = xxx host = xxx.xxx.xxx.xxx port = 6400 transceiver-mode = true smsc-username = xx smsc-password = xx system-type = interface-version = 34 enquire-link-interval = 60 source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 msg-id-type = 0x00 throughput = 5 We are faceing a strange problem with delivery report. This is the log: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP[xxx]: Sending PDU: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU 0x13820e90 dump: 2010-03-15 14:43:21 [18509] [9] DEBUG: type_name: submit_sm 2010-03-15 14:43:21 [18509] [9] DEBUG: command_id: 4 = 0x0004 2010-03-15 14:43:21 [18509] [9] DEBUG: command_status: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sequence_number: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: service_type: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_ton: 5 = 0x0005 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr: 4120 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_ton: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: destination_addr: 38x 2010-03-15 14:43:21 [18509] [9] DEBUG: esm_class: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: protocol_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: priority_flag: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: schedule_delivery_time: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: validity_period: 100315134421000+ 2010-03-15 14:43:21 [18509] [9] DEBUG: registered_delivery: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: replace_if_present_flag: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: data_coding: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_default_msg_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_length: 144 = 0x0090 2010-03-15 14:43:21 [18509] [9] DEBUG: short_message: 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string at 0x13824de0: 2010-03-15 14:43:21 [18509] [9] DEBUG: len: 144 2010-03-15 14:43:21 [18509] [9] DEBUG: size: 145 2010-03-15 14:43:21 [18509] [9] DEBUG: immutable: 0 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 4b 75 70 69 6c 69 20 73 74 65 20 6b 61 72 74 75 Kupili ste kartu 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 62 72 6f 6a 20 20 37 30 34 37 39 32 20 7a 61broj 704792 za 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 76 6f 7a 69 6c 6f 20 42 47 39 20 6b 6f 6a 61vozilo BG9 koja 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 76 61 7a 69 20 64 6f 20 20 31 35 2e 30 33 2evazi do 15.03. 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 32 30 31 30 20 20 31 35 3a 34 33 20 2d 20 67 72 2010 15:43 - gr 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 61 64 20 50 6f 64 67 6f 72 69 63 61 2c 20 5a 6f ad Podgorica, Zo 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 6e 61 20 32 20 70 6f 20 63 65 6e 69 20 6f 64 20 na 2 po ceni od 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 30 2c 35 30 20 45 55 52 2e 20 53 61 63 75 760,50 EUR. Sacuv 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 61 6a 74 65 20 6f 76 75 20 70 6f 72 75 6b 75 2e ajte ovu poruku. 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP[xxx]: Got PDU: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU 0x13820e90 dump: 2010-03-15 14:43:21 [18509] [9] DEBUG: type_name: submit_sm_resp 2010-03-15 14:43:21 [18509] [9] DEBUG: command_id: 2147483652 = 0x8004 2010-03-15 14:43:21 [18509] [9] DEBUG: command_status: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sequence_number: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: message_id: 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string at 0x13824f70: 2010-03-15 14:43:21 [18509] [9] DEBUG: len: 20 2010-03-15 14:43:21 [18509] [9] DEBUG: size: 21 2010-03-15 14:43:21 [18509] [9] DEBUG: immutable: 0 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 36 2d 31 32 36 38 36 36 30 35 39 39 34 35 37 34 6-12686605994574 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 35 35 32 37 5527 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: DLR[internal]: Adding DLR smsc=xxx, ts=6,
Re: SMPP delivery report issue
Is this problem solved in version 1.4.2? Alejandro Guerrieri wrote: Yes, you're out of luck, you need to patch the source code to be able to parse it. Regards, Alex On Tue, Mar 16, 2010 at 10:18 AM, Drazen Kozic drazen.ko...@asw.eu mailto:drazen.ko...@asw.eu wrote: Hi, We are using Kannel more than two years and we are very satisfied. Now, we are using version 1.4.1. The configuration of the SMSC is following: group = smsc smsc = smpp smsc-id = xxx host = xxx.xxx.xxx.xxx port = 6400 transceiver-mode = true smsc-username = xx smsc-password = xx system-type = interface-version = 34 enquire-link-interval = 60 source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 msg-id-type = 0x00 throughput = 5 We are faceing a strange problem with delivery report. This is the log: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP[xxx]: Sending PDU: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU 0x13820e90 dump: 2010-03-15 14:43:21 [18509] [9] DEBUG: type_name: submit_sm 2010-03-15 14:43:21 [18509] [9] DEBUG: command_id: 4 = 0x0004 2010-03-15 14:43:21 [18509] [9] DEBUG: command_status: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sequence_number: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: service_type: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_ton: 5 = 0x0005 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr: 4120 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_ton: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: destination_addr: 38x 2010-03-15 14:43:21 [18509] [9] DEBUG: esm_class: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: protocol_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: priority_flag: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: schedule_delivery_time: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: validity_period: 100315134421000+ 2010-03-15 14:43:21 [18509] [9] DEBUG: registered_delivery: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: replace_if_present_flag: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: data_coding: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_default_msg_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_length: 144 = 0x0090 2010-03-15 14:43:21 [18509] [9] DEBUG: short_message: 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string at 0x13824de0: 2010-03-15 14:43:21 [18509] [9] DEBUG: len: 144 2010-03-15 14:43:21 [18509] [9] DEBUG: size: 145 2010-03-15 14:43:21 [18509] [9] DEBUG: immutable: 0 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 4b 75 70 69 6c 69 20 73 74 65 20 6b 61 72 74 75 Kupili ste kartu 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 62 72 6f 6a 20 20 37 30 34 37 39 32 20 7a 61broj 704792 za 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 76 6f 7a 69 6c 6f 20 42 47 39 20 6b 6f 6a 61vozilo BG9 koja 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 76 61 7a 69 20 64 6f 20 20 31 35 2e 30 33 2evazi do 15.03. 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 32 30 31 30 20 20 31 35 3a 34 33 20 2d 20 67 72 2010 15:43 - gr 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 61 64 20 50 6f 64 67 6f 72 69 63 61 2c 20 5a 6f ad Podgorica, Zo 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 6e 61 20 32 20 70 6f 20 63 65 6e 69 20 6f 64 20 na 2 po ceni od 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 30 2c 35 30 20 45 55 52 2e 20 53 61 63 75 760,50 EUR. Sacuv 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 61 6a 74 65 20 6f 76 75 20 70 6f 72 75 6b 75 2e ajte ovu poruku. 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP[xxx]: Got PDU: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU 0x13820e90 dump: 2010-03-15 14:43:21 [18509] [9] DEBUG: type_name: submit_sm_resp 2010-03-15 14:43:21 [18509] [9] DEBUG: command_id: 2147483652 = 0x8004 2010-03-15 14:43:21 [18509] [9] DEBUG: command_status: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sequence_number: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: message_id: 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string at 0x13824f70: 2010-03-15 14:43:21 [18509] [9] DEBUG: len: 20 2010-03-15 14:43:21 [18509] [9] DEBUG: size: 21 2010-03-15 14:43:21 [18509] [9] DEBUG: immutable: 0 2010-03-15 14:43:21 [18509] [9]
Re: SMPP delivery report issue
No, the problem is the SMSC sends a completely non-standard DLR format. Either the SMSC fixes, or you do. Assuming the SMSC people won't, then you'd have to change kannel code to adapt for that format. Regards, Alex On Tue, Mar 16, 2010 at 11:59 AM, Drazen Kozic drazen.ko...@asw.eu wrote: Is this problem solved in version 1.4.2? Alejandro Guerrieri wrote: Yes, you're out of luck, you need to patch the source code to be able to parse it. Regards, Alex On Tue, Mar 16, 2010 at 10:18 AM, Drazen Kozic drazen.ko...@asw.eumailto: drazen.ko...@asw.eu wrote: Hi, We are using Kannel more than two years and we are very satisfied. Now, we are using version 1.4.1. The configuration of the SMSC is following: group = smsc smsc = smpp smsc-id = xxx host = xxx.xxx.xxx.xxx port = 6400 transceiver-mode = true smsc-username = xx smsc-password = xx system-type = interface-version = 34 enquire-link-interval = 60 source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 msg-id-type = 0x00 throughput = 5 We are faceing a strange problem with delivery report. This is the log: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP[xxx]: Sending PDU: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU 0x13820e90 dump: 2010-03-15 14:43:21 [18509] [9] DEBUG: type_name: submit_sm 2010-03-15 14:43:21 [18509] [9] DEBUG: command_id: 4 = 0x0004 2010-03-15 14:43:21 [18509] [9] DEBUG: command_status: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sequence_number: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: service_type: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_ton: 5 = 0x0005 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr: 4120 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_ton: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: destination_addr: 38x 2010-03-15 14:43:21 [18509] [9] DEBUG: esm_class: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: protocol_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: priority_flag: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: schedule_delivery_time: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: validity_period: 100315134421000+ 2010-03-15 14:43:21 [18509] [9] DEBUG: registered_delivery: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: replace_if_present_flag: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: data_coding: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_default_msg_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_length: 144 = 0x0090 2010-03-15 14:43:21 [18509] [9] DEBUG: short_message: 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string at 0x13824de0: 2010-03-15 14:43:21 [18509] [9] DEBUG: len: 144 2010-03-15 14:43:21 [18509] [9] DEBUG: size: 145 2010-03-15 14:43:21 [18509] [9] DEBUG: immutable: 0 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 4b 75 70 69 6c 69 20 73 74 65 20 6b 61 72 74 75 Kupili ste kartu 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 62 72 6f 6a 20 20 37 30 34 37 39 32 20 7a 61broj 704792 za 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 76 6f 7a 69 6c 6f 20 42 47 39 20 6b 6f 6a 61vozilo BG9 koja 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 76 61 7a 69 20 64 6f 20 20 31 35 2e 30 33 2evazi do 15.03. 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 32 30 31 30 20 20 31 35 3a 34 33 20 2d 20 67 72 2010 15:43 - gr 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 61 64 20 50 6f 64 67 6f 72 69 63 61 2c 20 5a 6f ad Podgorica, Zo 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 6e 61 20 32 20 70 6f 20 63 65 6e 69 20 6f 64 20 na 2 po ceni od 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 30 2c 35 30 20 45 55 52 2e 20 53 61 63 75 760,50 EUR. Sacuv 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 61 6a 74 65 20 6f 76 75 20 70 6f 72 75 6b 75 2e ajte ovu poruku. 2010-03-15 14:43:21 [18509] [9] DEBUG:Octet string dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP[xxx]: Got PDU: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU 0x13820e90 dump: 2010-03-15 14:43:21 [18509] [9] DEBUG: type_name: submit_sm_resp 2010-03-15 14:43:21 [18509] [9] DEBUG: command_id: 2147483652 = 0x8004 2010-03-15 14:43:21 [18509] [9] DEBUG: command_status: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sequence_number: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG:
Re: SMPP delivery report issue
Thanks. This is something that should be configurable in Kannel. Alejandro Guerrieri wrote: No, the problem is the SMSC sends a completely non-standard DLR format. Either the SMSC fixes, or you do. Assuming the SMSC people won't, then you'd have to change kannel code to adapt for that format. Regards, Alex On Tue, Mar 16, 2010 at 11:59 AM, Drazen Kozic drazen.ko...@asw.eu mailto:drazen.ko...@asw.eu wrote: Is this problem solved in version 1.4.2? Alejandro Guerrieri wrote: Yes, you're out of luck, you need to patch the source code to be able to parse it. Regards, Alex On Tue, Mar 16, 2010 at 10:18 AM, Drazen Kozic drazen.ko...@asw.eu mailto:drazen.ko...@asw.eu mailto:drazen.ko...@asw.eu mailto:drazen.ko...@asw.eu wrote: Hi, We are using Kannel more than two years and we are very satisfied. Now, we are using version 1.4.1. The configuration of the SMSC is following: group = smsc smsc = smpp smsc-id = xxx host = xxx.xxx.xxx.xxx port = 6400 transceiver-mode = true smsc-username = xx smsc-password = xx system-type = interface-version = 34 enquire-link-interval = 60 source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 msg-id-type = 0x00 throughput = 5 We are faceing a strange problem with delivery report. This is the log: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP[xxx]: Sending PDU: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU 0x13820e90 dump: 2010-03-15 14:43:21 [18509] [9] DEBUG: type_name: submit_sm 2010-03-15 14:43:21 [18509] [9] DEBUG: command_id: 4 = 0x0004 2010-03-15 14:43:21 [18509] [9] DEBUG: command_status: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sequence_number: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: service_type: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_ton: 5 = 0x0005 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr: 4120 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_ton: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: destination_addr: 38x 2010-03-15 14:43:21 [18509] [9] DEBUG: esm_class: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: protocol_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: priority_flag: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: schedule_delivery_time: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: validity_period: 100315134421000+ 2010-03-15 14:43:21 [18509] [9] DEBUG: registered_delivery: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: replace_if_present_flag: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: data_coding: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_default_msg_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_length: 144 = 0x0090 2010-03-15 14:43:21 [18509] [9] DEBUG: short_message: 2010-03-15 14:43:21 [18509] [9] DEBUG: Octet string at 0x13824de0: 2010-03-15 14:43:21 [18509] [9] DEBUG: len: 144 2010-03-15 14:43:21 [18509] [9] DEBUG: size: 145 2010-03-15 14:43:21 [18509] [9] DEBUG: immutable: 0 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 4b 75 70 69 6c 69 20 73 74 65 20 6b 61 72 74 75 Kupili ste kartu 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 62 72 6f 6a 20 20 37 30 34 37 39 32 20 7a 61 broj 704792 za 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 76 6f 7a 69 6c 6f 20 42 47 39 20 6b 6f 6a 61 vozilo BG9 koja 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 76 61 7a 69 20 64 6f 20 20 31 35 2e 30 33 2e vazi do 15.03. 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 32 30 31 30 20 20 31 35 3a 34 33 20 2d 20 67 72 2010 15:43 - gr 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 61 64 20 50 6f 64 67 6f 72 69 63 61 2c 20 5a 6f ad Podgorica, Zo 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 6e 61 20 32 20 70 6f 20 63 65 6e 69 20 6f 64 20 na 2 po ceni od 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 30 2c 35 30 20 45 55 52 2e 20 53 61 63 75 76 0,50 EUR. Sacuv 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 61 6a 74 65 20 6f 76 75 20 70 6f 72 75 6b 75 2e ajte ovu poruku. 2010-03-15 14:43:21 [18509] [9] DEBUG: Octet string dump ends. 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU dump ends. 2010-03-15 14:43:21 [18509] [9]
Redirecting HTTP response as SMS to a port
Hello, I am posting a data to the server in the sms-service,post-url and I get the response as bytes, I have to convert that as SMS and I have to send it to the sender is it possible through Kannel? And also the SMS has to be sent through a particular port. I have gone through the userguide and I am not able to find any thing useful. So kindly helpme regarding this. Thanks, PradeepChandar bearerboxkannel.conf Description: Binary data smskannel.conf Description: Binary data
how set up the esm_class to 0
hi all, How can I set up esm_class=0 in Kannel 1.43 Thanks, Hafez
Re: SMPP delivery report issue
Hi, Actually it seems there is another more important problem before that: submit_sm_resp: 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 36 2d 31 32 36 38 36 36 30 35 39 39 34 35 37 34 6-12686605994574 2010-03-15 14:43:21 [18509] [9] DEBUG: DLR[internal]: Adding DLR smsc=xxx, ts=6, src=4120, dst=+38x, mask=31, boxc= 2010-03-15 14:43:28 [18509] [9] ERROR: SMPP[xxx]: got DLR but could not find message or was not interested in it id392294905 dst38x, type2 I believe that according to SMPP spec, FIDs are alphanumeric, i.e. cannot contain '-'. This mixes kannel up and records wrong ts. No hope to match it after that. For that I would talk to my SMSc provider. Lastly best upgrade to latest CVS. There have been many improvements since 1.4.1 (~10 yrs old!) BR, Nikos - Original Message - From: Drazen Kozic drazen.ko...@asw.eu To: Alejandro Guerrieri alejandro.guerri...@gmail.com Cc: users@kannel.org Sent: Tuesday, March 16, 2010 1:21 PM Subject: Re: SMPP delivery report issue Thanks. This is something that should be configurable in Kannel. Alejandro Guerrieri wrote: No, the problem is the SMSC sends a completely non-standard DLR format. Either the SMSC fixes, or you do. Assuming the SMSC people won't, then you'd have to change kannel code to adapt for that format. Regards, Alex On Tue, Mar 16, 2010 at 11:59 AM, Drazen Kozic drazen.ko...@asw.eu mailto:drazen.ko...@asw.eu wrote: Is this problem solved in version 1.4.2? Alejandro Guerrieri wrote: Yes, you're out of luck, you need to patch the source code to be able to parse it. Regards, Alex On Tue, Mar 16, 2010 at 10:18 AM, Drazen Kozic drazen.ko...@asw.eu mailto:drazen.ko...@asw.eu mailto:drazen.ko...@asw.eu mailto:drazen.ko...@asw.eu wrote: Hi, We are using Kannel more than two years and we are very satisfied. Now, we are using version 1.4.1. The configuration of the SMSC is following: group = smsc smsc = smpp smsc-id = xxx host = xxx.xxx.xxx.xxx port = 6400 transceiver-mode = true smsc-username = xx smsc-password = xx system-type = interface-version = 34 enquire-link-interval = 60 source-addr-ton = 5 source-addr-npi = 1 dest-addr-ton = 1 dest-addr-npi = 1 msg-id-type = 0x00 throughput = 5 We are faceing a strange problem with delivery report. This is the log: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP[xxx]: Sending PDU: 2010-03-15 14:43:21 [18509] [9] DEBUG: SMPP PDU 0x13820e90 dump: 2010-03-15 14:43:21 [18509] [9] DEBUG: type_name: submit_sm 2010-03-15 14:43:21 [18509] [9] DEBUG: command_id: 4 = 0x0004 2010-03-15 14:43:21 [18509] [9] DEBUG: command_status: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sequence_number: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: service_type: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_ton: 5 = 0x0005 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: source_addr: 4120 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_ton: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: dest_addr_npi: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: destination_addr: 38x 2010-03-15 14:43:21 [18509] [9] DEBUG: esm_class: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: protocol_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: priority_flag: 3 = 0x0003 2010-03-15 14:43:21 [18509] [9] DEBUG: schedule_delivery_time: NULL 2010-03-15 14:43:21 [18509] [9] DEBUG: validity_period: 100315134421000+ 2010-03-15 14:43:21 [18509] [9] DEBUG: registered_delivery: 1 = 0x0001 2010-03-15 14:43:21 [18509] [9] DEBUG: replace_if_present_flag: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: data_coding: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_default_msg_id: 0 = 0x 2010-03-15 14:43:21 [18509] [9] DEBUG: sm_length: 144 = 0x0090 2010-03-15 14:43:21 [18509] [9] DEBUG: short_message: 2010-03-15 14:43:21 [18509] [9] DEBUG: Octet string at 0x13824de0: 2010-03-15 14:43:21 [18509] [9] DEBUG: len: 144 2010-03-15 14:43:21 [18509] [9] DEBUG: size: 145 2010-03-15 14:43:21 [18509] [9] DEBUG: immutable: 0 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 4b 75 70 69 6c 69 20 73 74 65 20 6b 61 72 74 75 Kupili ste kartu 2010-03-15 14:43:21 [18509] [9] DEBUG: data: 20 62 72 6f 6a 20 20 37 30 34 37 39 32 20 7a 61 broj 704792 za
Re: How to consulting status of sms via query_sm asynchronous
i believe you, but better I'll explain the context to understand my need , my carrier is migrating of platform , now are implementing sms premium, where the process is : i send him some sms , he recive and send at user the message ,but I need to know if the message was recovered and remitted to conciliation, and the only way to know is via Query_sm, so then I need to do a query message sent Query_sm. i have the kannel 1.4.3 Thks. 2010/3/12 Nikos Balkanas nbalka...@gmail.com Hi, Please use latest CVS, 1.4.3+. It is production quality with many enhancements. SMS by its nature is asynchronous. There are a lot of delays and different line speeds along the way that necessitate lots of buffers. It would need rewriting from scratch and be very inefficient if it was converted to synchronous. You are wellcome to try it if you don't believe me. BR, Nikos - Original Message - *From:* Sergio Gabriel Gallegos isc.sergi...@gmail.com *To:* users@kannel.org *Sent:* Saturday, March 13, 2010 12:20 AM *Subject:* How to consulting status of sms via query_sm asynchronous I have a 1.4 Connection Kannel smpp, sending sms via submit_sm, but in an asynchronous manner via I query_sm view their status and do not like this action, I'm new to this. I hope you can help me Thks
Re: How to consulting status of sms via query_sm asynchronous
Not necessarily. Please read user guide about DLRs (Delivery Reports). BR, Nikos - Original Message - From: Sergio Gabriel Gallegos To: users@kannel.org Cc: Nikos Balkanas Sent: Wednesday, March 17, 2010 12:34 AM Subject: Re: How to consulting status of sms via query_sm asynchronous i believe you, but better I'll explain the context to understand my need , my carrier is migrating of platform , now are implementing sms premium, where the process is : i send him some sms , he recive and send at user the message ,but I need to know if the message was recovered and remitted to conciliation, and the only way to know is via Query_sm, so then I need to do a query message sent Query_sm. i have the kannel 1.4.3 Thks. 2010/3/12 Nikos Balkanas nbalka...@gmail.com Hi, Please use latest CVS, 1.4.3+. It is production quality with many enhancements. SMS by its nature is asynchronous. There are a lot of delays and different line speeds along the way that necessitate lots of buffers. It would need rewriting from scratch and be very inefficient if it was converted to synchronous. You are wellcome to try it if you don't believe me. BR, Nikos - Original Message - From: Sergio Gabriel Gallegos To: users@kannel.org Sent: Saturday, March 13, 2010 12:20 AM Subject: How to consulting status of sms via query_sm asynchronous I have a 1.4 Connection Kannel smpp, sending sms via submit_sm, but in an asynchronous manner via I query_sm view their status and do not like this action, I'm new to this. I hope you can help me Thks
