hello sir, The number is a combined set of bit 1 and bit 2 that indicate as follows: bit 1: type for submit_sm_resp, bit 2: type for deliver_sm. If the bit is set then the value is in hex otherwise in decimal number base. Which means the following combinations are possible and valid: * 0x00 deliver_sm decimal, submit_sm_resp decimal; 0x01 deliver_sm decimal, submit_sm_resp hex; 0x02 deliver_sm hex, submit_sm_resp decimal; 0x03 deliver_sm hex, submit_sm_resp hex. *
I can see this , but there is no explanation about Octet Message IDs, My SMSC is using SMPP v3.3 & reply octet Message ID for submit_sm_resp and deliver_sm. Please advice. Regards Anshu Sah 2010/11/25 Nikos Balkanas <nbalka...@gmail.com>: > The UG does a pretty good job of explaining... > > BR, > Nikos > ----- Original Message ----- From: "Anshu Sah" <sah.an...@ymail.com> > To: "Nikos Balkanas" <nbalka...@gmail.com> > Cc: "users" <users@kannel.org> > Sent: Wednesday, November 24, 2010 7:36 PM > Subject: Re: Message DLR coming as MO > > > Hi Nikos > > I am putting msg-id-type = 0x00, If something else should be there, > please suggest. > > Regards > Anshu Sah > > > > > 2010/11/24 Nikos Balkanas <nbalka...@gmail.com>: >> >> Hi, >> >> Please read about message-id-type in UG. >> >> BR, >> Nikos >> ----- Original Message ----- From: Anshu Sah >> To: users >> Sent: Wednesday, November 24, 2010 4:29 PM >> Subject: Message DLR coming as MO >> >> >> >> >> Hi, >> >> A strange Scenario while i submit the sms to my SMSC i get dlr_url same as >> sent for Acknowledgment SMS, But while It creates new MO entry for the >> incoming DLR >> My SMSC provider is using SMPP v3.3 >> >> I investigated the issue, and come to know the message_id returned from >> SMSC >> is in octect string containing Zero , & 00 is removed while string this >> data >> in kannel_dlr. >> >> But when DLR comes to kannel, it contains again octect string and that >> time >> message id is not being parsed by kannel. >> >> The problem is, i am not able to match directly the DLR for specific >> Message >> On the basis of dlr_url, I needed to match it through kannel_dlr. >> >> While for another provider who uses Hexadecimal MessageId & SMPP3.4, for >> that its working perfectly. >> >> Please guide. >> >> Please find Logs below. >> >> 2010-11-24 02:06:30 [20697] [9] DEBUG: SMPP[SMStata2]: Got PDU: >> 2010-11-24 02:06:30 [20697] [9] DEBUG: SMPP PDU 0x12780b0 dump: >> 2010-11-24 02:06:30 [20697] [9] DEBUG: type_name: submit_sm_resp >> 2010-11-24 02:06:30 [20697] [9] DEBUG: command_id: 2147483652 = 0x80000004 >> 2010-11-24 02:06:30 [20697] [9] DEBUG: command_status: 0 = 0x00000000 >> 2010-11-24 02:06:30 [20697] [9] DEBUG: sequence_number: 41 = 0x00000029 >> 2010-11-24 02:06:30 [20697] [9] DEBUG: message_id: "0018707152" >> 2010-11-24 02:06:30 [20697] [9] DEBUG: SMPP PDU dump ends. >> 2010-11-24 02:06:30 [20697] [9] DEBUG: DLR[mysql]: Adding DLR >> smsc=SMStata2, >> ts=18707152, src=e2emum, dst=+919971372333, mask=31, boxc=sqlbox >> 2010-11-24 02:06:30 [20697] [9] DEBUG: adding DLR entry into database >> 2010-11-24 02:06:30 [20697] [9] DEBUG: sql: INSERT INTO `kannel_dlr` >> (`smsc`, `timestamp`, `source`, `destination`, `service`, `url`, `mask`, >> `boxc_id`, `status`) VALUES (?, ?, ?, ?, ?, ?, ?, ?, 0) >> 2010-11-24 02:06:30 [20697] [9] DEBUG: SMSC[SMStata2]: creating DLR >> message >> 2010-11-24 02:06:30 [20697] [9] DEBUG: SMSC[SMStata2]: DLR = >> 132b804-5095-4cec25cd-391411d1_1 >> >> >> When I get DLR >> >> 2010-11-24 02:21:56 [20697] [9] DEBUG: SMPP[SMStata2]: throughput >> (0.00,0.00) >> 2010-11-24 02:21:56 [20697] [9] DEBUG: SMPP[SMStata2]: Got PDU: >> 2010-11-24 02:21:56 [20697] [9] DEBUG: SMPP PDU 0x1277ce0 dump: >> 2010-11-24 02:21:56 [20697] [9] DEBUG: type_name: deliver_sm >> 2010-11-24 02:21:56 [20697] [9] DEBUG: command_id: 5 = 0x00000005 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: command_status: 0 = 0x00000000 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: sequence_number: 8 = 0x00000008 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: service_type: NULL >> 2010-11-24 02:21:56 [20697] [9] DEBUG: source_addr_ton: 1 = 0x00000001 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: source_addr_npi: 1 = 0x00000001 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: source_addr: "e2emum" >> 2010-11-24 02:21:56 [20697] [9] DEBUG: dest_addr_ton: 1 = 0x00000001 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: dest_addr_npi: 1 = 0x00000001 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: destination_addr: "919971372333" >> 2010-11-24 02:21:56 [20697] [9] DEBUG: esm_class: 0 = 0x00000000 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: protocol_id: 1 = 0x00000001 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: priority_flag: 3 = 0x00000003 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: schedule_delivery_time: NULL >> 2010-11-24 02:21:56 [20697] [9] DEBUG: validity_period: NULL >> 2010-11-24 02:21:56 [20697] [9] DEBUG: registered_delivery: 1 = 0x00000001 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: replace_if_present_flag: 0 = >> 0x00000000 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: data_coding: 0 = 0x00000000 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: sm_default_msg_id: 0 = 0x00000000 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: sm_length: 107 = 0x0000006b >> 2010-11-24 02:21:56 [20697] [9] DEBUG: short_message: >> 2010-11-24 02:21:56 [20697] [9] DEBUG: Octet string at 0x1277730: >> 2010-11-24 02:21:56 [20697] [9] DEBUG: len: 107 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: size: 108 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: immutable: 0 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: data: 69 64 3a 30 30 31 38 37 30 >> 37 32 31 34 20 73 75 id:0018707214 su >> 2010-11-24 02:21:56 [20697] [9] DEBUG: data: 62 3a 30 30 31 20 64 6c 76 >> 72 64 3a 30 30 31 20 b:001 dlvrd:001 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: data: 73 75 62 6d 69 74 20 64 61 >> 74 65 3a 31 30 31 31 submit date:1011 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: data: 32 34 30 32 32 31 20 64 6f >> 6e 65 20 64 61 74 65 240221 done date >> 2010-11-24 02:21:56 [20697] [9] DEBUG: data: 3a 31 30 31 31 32 34 30 32 >> 32 31 20 73 74 61 74 :1011240221 stat >> 2010-11-24 02:21:56 [20697] [9] DEBUG: data: 3a 44 45 4c 49 56 52 44 20 >> 65 72 72 3a 30 30 30 :DELIVRD err:000 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: data: 20 74 65 78 74 3a 45 32 45 >> 20 50 text:E2E P >> 2010-11-24 02:21:56 [20697] [9] DEBUG: Octet string dump ends. >> 2010-11-24 02:21:56 [20697] [9] DEBUG: SMPP PDU dump ends. >> 2010-11-24 02:21:56 [20697] [9] DEBUG: SMPP[SMStata2]: Sending PDU: >> 2010-11-24 02:21:56 [20697] [9] DEBUG: SMPP PDU 0x1275b20 dump: >> 2010-11-24 02:21:56 [20697] [9] DEBUG: type_name: deliver_sm_resp >> 2010-11-24 02:21:56 [20697] [9] DEBUG: command_id: 2147483653 = 0x80000005 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: command_status: 0 = 0x00000000 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: sequence_number: 8 = 0x00000008 >> 2010-11-24 02:21:56 [20697] [9] DEBUG: message_id: NULL >> 2010-11-24 02:21:56 [20697] [9] DEBUG: SMPP PDU dump ends. >> >> >> Entry in SQLBox >> momt = MO >> msgdata = >> >> id%3A0018709816+sub%3A001+dlvrd%3A001+submit+date%3A1011240807+done+date%3A1011240807+stat%3ADELIVRD+err%3A000+text%3AE2E+P >> >> >> Regards >> Anshu Sah >> > >
