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 <cia...@phonovation.com>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:krn...@gmail.com] > *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 <cia...@phonovation.com> > 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:users-boun...@kannel.org] *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 <krn...@gmail.com> 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 > > >
