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
>>>
>>>
>>>
>>
>>
>
