Dear Krnrd, Please share your Kannel access logs as well as well as smsc conf file.
On Fri, Jan 24, 2014 at 11:50 AM, krnrd b <[email protected]> wrote: > When i did that the delivery report which is coming on Rx connection re > submited to Tx connection. > > > On Fri, Jan 24, 2014 at 11:42 AM, John alero <[email protected]> wrote: > >> Dear Krnrd, >> >> >> Please use same smsc-id name for TX as well as RX session (RND-1). >> >> >> Kindly find the sample example in given below. >> >> SMSC connections: >> RND-1[RND-1] SMPP:xxx.xxx.xxx.xxx:2161/0:TestAT:SMPP_RND >> (online 72s, rcvd: sms 0 / dlr 0, sent: sms 1 / dlr 0, failed 0, queued >> 0 msgs) >> RND-1[RND-1] SMPP:xxx.xxx.xxx.xxx:0/2161:TestAT:SMPP_RND >> (online 73s, rcvd: sms 0 / dlr 0, sent: sms 0 / dlr 0, failed 0, queued >> 0 msgs) >> >> >> >> >> On Fri, Jan 24, 2014 at 11:35 AM, krnrd b <[email protected]> wrote: >> >>> Hi All, >>> >>> Any inputs for the issue I am facing. >>> >>> Please point me in right direction if I am doing any mistake. >>> >>> Thanks, >>> KRNRDB >>> >>> >>> On Thu, Jan 23, 2014 at 10:47 PM, krnrd b <[email protected]> wrote: >>> >>>> I have try to rename RND-1-Rx bind to RND-1 same then dlr received >>>> showing on kannel status page but the serious problem is the dlr's which i >>>> am receiving, kannel sending the same dlr in submit_sm that means on Tx >>>> connection the same delivery report submitted as submit_sm. >>>> >>>> But when i use TRx mode kannel performing normally also submit and >>>> delivery repots showing on kannel status page. >>>> >>>> separate Tx and Rx binds use to work perfectly on kannel 1.4.3 but on >>>> kannel 1.5.0 the same separate Tx and Rx connections not working properly >>>> for same SMSC provider. >>>> >>>> My be i am missing some configuration parameters or this is the >>>> behavior of kannel 1.5.0. >>>> >>>> Configuration which is working fine with kannel 1.4.3 and which not >>>> working with kannel 1.5.0 >>>> >>>> # GROUP SMSC Tx >>>> group = smsc >>>> smsc = smpp >>>> smsc-id = RND-1 >>>> throughput = 1 >>>> #transceiver-mode = yes >>>> host = xxx.xxx.xxx.xxx >>>> port = xxxx >>>> system-type = "RND" >>>> smsc-username = "xxxxx" >>>> smsc-password = "xxxxx" >>>> address-range = " " >>>> reconnect-delay = 2 >>>> alt-charset = "ASCII" >>>> enquire-link-interval = 30 >>>> >>>> # Rx connection >>>> group = smsc >>>> smsc = smpp >>>> smsc-id = RND-1-Rx >>>> throughput = 1 >>>> host = xxx.xxx.xxx.xxx >>>> port = xxxx >>>> system-type = "RND" >>>> smsc-username = "xxxxx" >>>> smsc-password = "xxxxx" >>>> address-range = " " >>>> reconnect-delay = 2 >>>> enquire-link-interval = 30 >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jan 23, 2014 at 10:17 PM, Ciaran Scolard < >>>> [email protected]> wrote: >>>> >>>>> It should happen automatically. >>>>> >>>>> I’m a bit new to kannel so I could be wrong but I think you just have >>>>> to have the binds named the same. >>>>> >>>>> Try renaming your RND-1-Rx bind to RND-1 and see if that works. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* krnrd b [mailto:[email protected]] >>>>> *Sent:* 23 January 2014 15:46 >>>>> *To:* Ciaran Scolard >>>>> *Cc:* users >>>>> >>>>> *Subject:* Re: DLR: received showing 0 in kannel status page >>>>> >>>>> >>>>> >>>>> How would I match DLR/ID ? >>>>> >>>>> >>>>> >>>>> for Kannel 1.4.3 I use same configuration incoming and outgoing shows >>>>> properly. >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> KRNRDB >>>>> >>>>> >>>>> >>>>> On Thu, Jan 23, 2014 at 7:22 PM, Ciaran Scolard < >>>>> [email protected]> wrote: >>>>> >>>>> Currently the Tx and Rx binds are named RND-1 and RND-1-Rx. >>>>> >>>>> Wouldn’t the SMPP binds have to be named the same for the DLR/ID >>>>> matching to work? >>>>> >>>>> >>>>> >>>>> *From:* users [mailto:[email protected]] *On Behalf Of *krnrd b >>>>> *Sent:* 23 January 2014 12:22 >>>>> *To:* users >>>>> *Subject:* Re: DLR: received showing 0 in kannel status page >>>>> >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> Any one faced this issue before? >>>>> >>>>> >>>>> >>>>> Sorry just curious to know . >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> KRNRDB >>>>> >>>>> On Thursday, January 23, 2014, krnrd b <[email protected]> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> I am using kannel 1.5.0 devel version. When i use Tx and Rx separated >>>>> while connecting SMSC now problem is when submit_sm happening message >>>>> delivered to handset and sms sent as 1 on kannel status page and showing >>>>> properly for Tx connection but when i receiving DLR on Rx connection it's >>>>> showing DLR: received 0 on kannel status page but dlr's coming properly on >>>>> kannel logs. >>>>> >>>>> >>>>> >>>>> Please suggest me why dlr's showing on kannel log but not showing on >>>>> kannel status page. >>>>> >>>>> >>>>> >>>>> Please find the attached kannel status page. >>>>> >>>>> >>>>> >>>>> Kannel bearerbox version `1.5.0'. Build `Jan 15 2014 15:56:30', >>>>> compiler `4.1.2 20070626 (Red Hat 4.1.2-14)'. System Linux, release >>>>> 2.6.18-53.el5, version >>>>> >>>>> #1 SMP Wed Oct 10 16:34:19 EDT 2007, machine x86_64. Hostname >>>>> Blade1, IP 172.16.8.206. Libxml version 2.6.26. Using OpenSSL 0.9.8b 04 >>>>> May >>>>> 2006. Compiled >>>>> >>>>> with MySQL 5.1.35, using MySQL 5.1.35. Using native malloc. >>>>> >>>>> >>>>> >>>>> Status: running, uptime 0d 0h 1m 15s >>>>> >>>>> >>>>> >>>>> WDP: received 0 (0 queued), sent 0 (0 queued) >>>>> >>>>> >>>>> >>>>> SMS: received 0 (0 queued), sent 1 (0 queued), store size 0 >>>>> >>>>> SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.02,0.01,0.01) >>>>> msg/sec >>>>> >>>>> >>>>> >>>>> DLR: received 0, sent 0 >>>>> >>>>> DLR: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00) >>>>> msg/sec >>>>> >>>>> DLR: 19 queued, using mysql storage >>>>> >>>>> >>>>> >>>>> Box connections: >>>>> >>>>> smsbox:(none), IP 127.0.0.1 (0 queued), (on-line 0d 0h 1m 4s) >>>>> >>>>> >>>>> >>>>> SMSC connections: >>>>> >>>>> RND-1[RND-1] SMPP:xxx.xxx.xxx.xxx:2161/0:TestAT:SMPP_RND >>>>> (online 72s, rcvd: sms 0 / dlr 0, sent: sms 1 / dlr 0, failed 0, queued 0 >>>>> msgs) >>>>> >>>>> RND-1-Rx[RND-1-Rx] >>>>> SMPP:xxx.xxx.xxx.xxx:0/2161:TestAT:SMPP_RND (online 73s, rcvd: sms 0 / >>>>> dlr >>>>> 0, sent: sms 0 / dlr 0, failed 0, queued 0 msgs) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> PDU : >>>>> >>>>> >>>>> >>>>> Tx >>>>> >>>>> ------------- >>>>> >>>>> >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: throughput >>>>> (0.00,1.00) >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP[RND-1]: Sending PDU: >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP PDU 0x2aaaac000a80 dump: >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: type_name: submit_sm >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: command_id: 4 = 0x00000004 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: command_status: 0 = 0x00000000 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: sequence_number: 2 = >>>>> 0x00000002 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: service_type: NULL >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: source_addr_ton: 5 = >>>>> 0x00000005 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: source_addr_npi: 0 = >>>>> 0x00000000 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: source_addr: "xxxx" >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: dest_addr_ton: 2 = 0x00000002 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: dest_addr_npi: 1 = 0x00000001 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: destination_addr: >>>>> "xxxxxxxxxxxx" >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: esm_class: 3 = 0x00000003 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: protocol_id: 0 = 0x00000000 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: priority_flag: 0 = 0x00000000 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: schedule_delivery_time: NULL >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: validity_period: NULL >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: registered_delivery: 1 = >>>>> 0x00000001 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: replace_if_present_flag: 0 = >>>>> 0x00000000 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: data_coding: 0 = 0x00000000 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: sm_default_msg_id: 0 = >>>>> 0x00000000 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: sm_length: 16 = 0x00000010 >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: short_message: "Testing from >>>>> RnD" >>>>> >>>>> 2014-01-23 11:12:17 [20558] [6] DEBUG: SMPP PDU dump ends. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Rx >>>>> >>>>> -------- >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: SMPP[RND-1-Rx]: Got PDU: >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: SMPP PDU 0x1e909800 dump: >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: type_name: deliver_sm >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: command_id: 5 = 0x00000005 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: command_status: 0 = 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: sequence_number: 647515690 = >>>>> 0x26984e2a >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: service_type: NULL >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: source_addr_ton: 0 = >>>>> 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: source_addr_npi: 0 = >>>>> 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: source_addr: "xxxx" >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: dest_addr_ton: 0 = 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: dest_addr_npi: 0 = 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: destination_addr: >>>>> "xxxxxxxxxxxx" >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: esm_class: 4 = 0x00000004 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: protocol_id: 0 = 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: priority_flag: 0 = 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: schedule_delivery_time: NULL >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: validity_period: NULL >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: registered_delivery: 0 = >>>>> 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: replace_if_present_flag: 0 = >>>>> 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: data_coding: 0 = 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: sm_default_msg_id: 0 = >>>>> 0x00000000 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: sm_length: 111 = 0x0000006f >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: short_message: >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: Octet string at 0x1e909a60: >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: len: 111 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: size: 112 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: immutable: 0 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: data: 69 64 3a 31 33 31 34 >>>>> 30 31 32 33 31 31 31 32 31 id:1314012311121 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: data: 38 36 31 35 31 30 20 >>>>> 73 75 62 3a 30 30 31 20 64 861510 sub:001 d >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: data: 6c 76 72 64 3a 30 30 >>>>> 31 20 73 75 62 6d 69 74 20 lvrd:001 submit >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: data: 64 61 74 65 3a 31 34 >>>>> 30 31 32 33 31 31 31 32 20 date:1401231112 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: data: 64 6f 6e 65 20 64 61 >>>>> 74 65 3a 31 34 30 31 32 33 done date:140123 >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: data: 31 31 31 32 20 73 74 >>>>> 61 74 3a 44 45 4c 49 56 52 1112 stat:DELIVR >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: data: 44 20 65 72 72 3a 30 >>>>> 30 31 20 54 65 78 74 3a D err:001 Text: >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: Octet string dump ends. >>>>> >>>>> 2014-01-23 11:12:59 [20558] [7] DEBUG: SMPP PDU dump ends. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> KRNRDB >>>>> >>>>> >>>>> >>>> >>>> >>> >> >
