Hi All, Got the problem, just posting here so that it could be of help to others. Since the mgs-id returned by the SMSC is neither decimal nor hexadecimal, it requires the msg-id-type field to be undefined making the bearerbox then fall back to the C string option which works well. Regards,Sudeep.
From: [email protected] To: [email protected] Subject: Incorrect DLR mapping Date: Sun, 1 Apr 2012 16:49:16 +0530 Hi, I searched the list for incorrect Dlr mapping and found some of the threads discussing what was close to our issue, but that was with CIMD and other smsc types not with SMPP. Hence I ask the following: Bearerbox puts 13 as the 'ts' field value which is also found in the Sent Sms entry in access_server.log. Mentioned below is an example trace: Subtmit_sm: 2012-03-22 11:28:01 [5391] [32] DEBUG: SMPP[R05]: Sending PDU: 2012-03-22 11:28:01 [5391] [32] DEBUG: SMPP PDU 0xff37170 dump: 2012-03-22 11:28:01 [5391] [32] DEBUG: type_name: submit_sm 2012-03-22 11:28:01 [5391] [32] DEBUG: command_id: 4 = 0x00000004 2012-03-22 11:28:01 [5391] [32] DEBUG: command_status: 0 = 0x00000000 2012-03-22 11:28:01 [5391] [32] DEBUG: sequence_number: 1147800 = 0x00118398 2012-03-22 11:28:01 [5391] [32] DEBUG: service_type: NULL 2012-03-22 11:28:01 [5391] [32] DEBUG: source_addr_ton: 0 = 0x00000000 2012-03-22 11:28:01 [5391] [32] DEBUG: source_addr_npi: 1 = 0x00000001 2012-03-22 11:28:01 [5391] [32] DEBUG: source_addr: "Demo" 2012-03-22 11:28:01 [5391] [32] DEBUG: dest_addr_ton: 0 = 0x00000000 2012-03-22 11:28:01 [5391] [32] DEBUG: dest_addr_npi: 1 = 0x00000001 2012-03-22 11:28:01 [5391] [32] DEBUG: destination_addr: "xxx9209xxxxx" 2012-03-22 11:28:01 [5391] [32] DEBUG: esm_class: 3 = 0x00000003 2012-03-22 11:28:01 [5391] [32] DEBUG: protocol_id: 0 = 0x00000000 2012-03-22 11:28:01 [5391] [32] DEBUG: priority_flag: 0 = 0x00000000 2012-03-22 11:28:01 [5391] [32] DEBUG: schedule_delivery_time: NULL 2012-03-22 11:28:01 [5391] [32] DEBUG: validity_period: NULL 2012-03-22 11:28:01 [5391] [32] DEBUG: registered_delivery: 1 = 0x00000001 2012-03-22 11:28:01 [5391] [32] DEBUG: replace_if_present_flag: 0 = 0x00000000 2012-03-22 11:28:01 [5391] [32] DEBUG: data_coding: 0 = 0x00000000 2012-03-22 11:28:01 [5391] [32] DEBUG: sm_default_msg_id: 0 = 0x00000000 2012-03-22 11:28:01 [5391] [32] DEBUG: sm_length: 159 = 0x0000009f 2012-03-22 11:28:01 [5391] [32] DEBUG: short_message: 2012-03-22 11:28:01 [5391] [32] DEBUG: Octet string at 0xbd3fa20: 2012-03-22 11:28:01 [5391] [32] DEBUG: len: 159 2012-03-22 11:28:01 [5391] [32] DEBUG: size: 160 2012-03-22 11:28:01 [5391] [32] DEBUG: immutable: 0 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 53 70 65 63 69 61 6c 20 50 72 69 63 65 20 46 6f Special Price Fo 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 72 20 33 20 44 61 79 73 20 46 6f 72 20 50 72 65 r 3 Days For Pre 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 2d 4c 61 75 6e 63 68 20 50 72 6f 6a 65 63 74 20 -Launch Project 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 49 6e 20 54 68 61 6e 65 20 28 77 29 2e 20 31 2c In Thane (w). 1, 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 20 31 2e 35 2c 20 32 20 26 20 33 20 42 48 4b 73 1.5, 2 & 3 BHKs 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 20 34 35 20 6c 61 63 73 20 4f 6e 77 61 72 64 73 45 lacs Onwards 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 2e 20 52 69 76 65 72 20 26 20 4d 6f 75 6e 74 61 . River & Mounta 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 69 6e 20 56 69 65 77 2e 20 41 6c 6c 20 4d 6f 64 in View. All Mod 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 65 72 6e 20 41 6d 65 6e 69 74 69 65 73 2e 20 43 ern Amenities. C 2012-03-22 11:28:01 [5391] [32] DEBUG: data: 61 6c 6c 20 39 39 33 30 32 35 34 38 38 33 2e all xxxxxxxxxxx. 2012-03-22 11:28:01 [5391] [32] DEBUG: Octet string dump ends. 2012-03-22 11:28:01 [5391] [32] DEBUG: SMPP PDU dump ends. submit_sm_resp: =============== 2012-03-22 11:28:02 [5391] [32] DEBUG: SMPP[R05]: Got PDU: 2012-03-22 11:28:02 [5391] [32] DEBUG: SMPP PDU 0xff37170 dump: 2012-03-22 11:28:02 [5391] [32] DEBUG: type_name: submit_sm_resp 2012-03-22 11:28:02 [5391] [32] DEBUG: command_id: 2147483652 = 0x80000004 2012-03-22 11:28:02 [5391] [32] DEBUG: command_status: 0 = 0x00000000 2012-03-22 11:28:02 [5391] [32] DEBUG: sequence_number: 1147800 = 0x00118398 2012-03-22 11:28:02 [5391] [32] DEBUG: message_id: 2012-03-22 11:28:02 [5391] [32] DEBUG: Octet string at 0xa9f2ba0: 2012-03-22 11:28:02 [5391] [32] DEBUG: len: 29 2012-03-22 11:28:02 [5391] [32] DEBUG: size: 30 2012-03-22 11:28:02 [5391] [32] DEBUG: immutable: 0 2012-03-22 11:28:02 [5391] [32] DEBUG: data: 64 74 65 63 68 70 6c 2d 31 33 33 32 33 39 35 37 dtechpl-13323957 2012-03-22 11:28:02 [5391] [32] DEBUG: data: 31 33 33 35 37 2d 34 30 2d 30 32 30 32 13357-40-0202 2012-03-22 11:28:02 [5391] [32] DEBUG: Octet string dump ends. 2012-03-22 11:28:02 [5391] [32] DEBUG: SMPP PDU dump ends. 2012-03-22 11:28:02 [5391] [32] DEBUG: DLR[mysql]: Adding DLR smsc=R05, ts=13, src=Demo, dst=xxx9209xxxxx, mask=3, boxc=SMSZING 2012-03-22 11:28:02 [5391] [32] DEBUG: adding DLR entry into database 2012-03-22 11:28:02 [5391] [32] DEBUG: sql: INSERT INTO `Dlr` (`smsc`, `ts`, `source`, `destination`, `service`, `url`, `mask`, `boxc`, `status`) VALUES (?, ?, ?, ?, ?, ?, ?, ?, 0) Here's what I am talking about. Even though the submit_sm_resp contains the msg-id bearerbox puts ts=13 as the value. As this happens for all sms when the dlr arrives the first entry (since bbox uses limit 1) with ts=13 and smsc=R05 is mapped, thus causing a mismatch of the DLRs. PS : From the sequence number you can make sure here that the submit_sm_resp PDU is indeed for the submit_sm PDU mentioned above. Thanks & Regards, Sudeep.
