Right... So I don't see the problem here...
-----Original Message----- From: Alexander Malysh [mailto:malys...@gmail.com] On Behalf Of Alexander Malysh Sent: donderdag 7 maart 2013 11:42 To: Rene Kluwen Cc: 'Jam Hitz'; users@kannel.org Subject: Re: No submit_sm_resp Rene, deliver_sm_resp is always without message_id. Alex Am 06.03.2013 um 19:22 schrieb Rene Kluwen <rene.klu...@chimit.nl>: > So you do send a deliver_sm_resp. Just with an empty message id. > Let me look at this closer. > > -----Original Message----- > From: Jam Hitz [mailto:is.mu...@gmail.com] > Sent: woensdag 6 maart 2013 18:40 > To: Rene Kluwen > Cc: Alexander Malysh; users@kannel.org > Subject: Re: No submit_sm_resp > > Here is the Bearerbox Log (Please NOTE: Upon the recommendations of > the telco, I have created 10 instances of saf_receiver_b SMSC as > defined in the config). I shared my settings with the telco and they > are also insisting that I raise window setting to 500 even though the > documentation says maximum is 10). Inspite of all that, I still get > like only 5 SMS/min (when I'm lucky) > > Another observation: in my bearerbox log, I am getting some > interesting errors especially when restarting the daemon: > > 2013-03-06 20:20:41 [26334] [3] ERROR: System error 98: Address > already in use [26385] [0] INFO: DLR rerouting for smsc id <saf_receiver_b> disabled. > > .... and lots of these: > 2013-03-06 20:24:43 [26488] [17] DEBUG: sms_router: handling message > (0x20bbc10 vs 0x12a4460) > 2013-03-06 20:24:43 [26488] [17] DEBUG: Routing failed, re-queued. > > ...and lots of these (saf_7711 is the transmitter SMSC bind) > WARNING: SMPP[saf_7711]: Not ACKED message found, will retransmit. > SENT<66>sec. ago, SEQ<84>, DST<12345398700> > > > Here is my bearerbox log: > > 2013-03-06 20:32:05 [26488] [9] DEBUG: SMPP[saf_receiver_b]: Sending > enquire > link: > 2013-03-06 20:32:05 [26488] [9] DEBUG: SMPP PDU 0x7f36dc000a30 dump: > 2013-03-06 20:32:05 [26488] [9] DEBUG: type_name: enquire_link > 2013-03-06 20:32:05 [26488] [9] DEBUG: command_id: 21 = 0x00000015 > 2013-03-06 20:32:05 [26488] [9] DEBUG: command_status: 0 = 0x00000000 > 2013-03-06 20:32:05 [26488] [9] DEBUG: sequence_number: 14 = 0x0000000e > 2013-03-06 20:32:05 [26488] [9] DEBUG: SMPP PDU dump ends. > 2013-03-06 20:32:06 [26488] [8] DEBUG: SMPP[saf_receiver_b]: Sending > enquire > link: > 2013-03-06 20:32:06 [26488] [8] DEBUG: SMPP PDU 0x7f36e4000e40 dump: > 2013-03-06 20:32:06 [26488] [8] DEBUG: type_name: enquire_link > 2013-03-06 20:32:06 [26488] [8] DEBUG: command_id: 21 = 0x00000015 > 2013-03-06 20:32:06 [26488] [8] DEBUG: command_status: 0 = 0x00000000 > 2013-03-06 20:32:06 [26488] [8] DEBUG: sequence_number: 88 = 0x00000058 > 2013-03-06 20:32:06 [26488] [8] DEBUG: SMPP PDU dump ends. > 2013-03-06 20:32:07 [26488] [15] DEBUG: SMPP[saf_receiver_b]: Sending > enquire link: > 2013-03-06 20:32:07 [26488] [15] DEBUG: SMPP PDU 0x7f36c0000e90 dump: > 2013-03-06 20:32:07 [26488] [15] DEBUG: type_name: enquire_link > 2013-03-06 20:32:07 [26488] [15] DEBUG: command_id: 21 = 0x00000015 > 2013-03-06 20:32:07 [26488] [15] DEBUG: command_status: 0 = 0x00000000 > 2013-03-06 20:32:07 [26488] [15] DEBUG: sequence_number: 13 = 0x0000000d > 2013-03-06 20:32:07 [26488] [15] DEBUG: SMPP PDU dump ends. > 2013-03-06 20:32:08 [26488] [11] DEBUG: SMPP[saf_receiver_b]: Sending > enquire link: > 2013-03-06 20:32:08 [26488] [11] DEBUG: SMPP PDU 0x7f36d0000e40 dump: > 2013-03-06 20:32:08 [26488] [11] DEBUG: type_name: enquire_link > 2013-03-06 20:32:08 [26488] [11] DEBUG: command_id: 21 = 0x00000015 > 2013-03-06 20:32:08 [26488] [11] DEBUG: command_status: 0 = 0x00000000 > 2013-03-06 20:32:08 [26488] [11] DEBUG: sequence_number: 14 = 0x0000000e > 2013-03-06 20:32:08 [26488] [11] DEBUG: SMPP PDU dump ends. > 2013-03-06 20:32:09 [26488] [11] DEBUG: Optional parameter tag > (0x0606) > 2013-03-06 20:32:09 [26488] [11] DEBUG: Optional parameter length read > as 1 > 2013-03-06 20:32:09 [26488] [11] WARNING: SMPP: Unknown > TLV(0x0606,0x0001,00) for PDU type (deliver_sm) received! > 2013-03-06 20:32:09 [26488] [11] DEBUG: Optional parameter tag > (0x1501) > 2013-03-06 20:32:09 [26488] [11] DEBUG: Optional parameter length read > as 13 > 2013-03-06 20:32:09 [26488] [11] WARNING: SMPP: Unknown > TLV(0x1501,0x000d,32353437323235303036313200) for PDU type > (deliver_sm) received! > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP[saf_receiver_b]: Got PDU: > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP PDU 0x7f36d0001500 dump: > 2013-03-06 20:32:09 [26488] [11] DEBUG: type_name: deliver_sm > 2013-03-06 20:32:09 [26488] [11] DEBUG: command_id: 5 = 0x00000005 > 2013-03-06 20:32:09 [26488] [11] DEBUG: command_status: 0 = 0x00000000 > 2013-03-06 20:32:09 [26488] [11] DEBUG: sequence_number: 2 = 0x00000002 > 2013-03-06 20:32:09 [26488] [11] DEBUG: service_type: "INSRV" > 2013-03-06 20:32:09 [26488] [11] DEBUG: source_addr_ton: 1 = 0x00000001 > 2013-03-06 20:32:09 [26488] [11] DEBUG: source_addr_npi: 1 = 0x00000001 > 2013-03-06 20:32:09 [26488] [11] DEBUG: source_addr: "254703842263" > 2013-03-06 20:32:09 [26488] [11] DEBUG: dest_addr_ton: 0 = 0x00000000 > 2013-03-06 20:32:09 [26488] [11] DEBUG: dest_addr_npi: 1 = 0x00000001 > 2013-03-06 20:32:09 [26488] [11] DEBUG: destination_addr: "7711" > 2013-03-06 20:32:09 [26488] [11] DEBUG: esm_class: 0 = 0x00000000 > 2013-03-06 20:32:09 [26488] [11] DEBUG: protocol_id: 0 = 0x00000000 > 2013-03-06 20:32:09 [26488] [11] DEBUG: priority_flag: 0 = 0x00000000 > 2013-03-06 20:32:09 [26488] [11] DEBUG: schedule_delivery_time: NULL > 2013-03-06 20:32:09 [26488] [11] DEBUG: validity_period: NULL > 2013-03-06 20:32:09 [26488] [11] DEBUG: registered_delivery: 0 = > 0x00000000 > 2013-03-06 20:32:09 [26488] [11] DEBUG: replace_if_present_flag: 0 = > 0x00000000 > 2013-03-06 20:32:09 [26488] [11] DEBUG: data_coding: 0 = 0x00000000 > 2013-03-06 20:32:09 [26488] [11] DEBUG: sm_default_msg_id: 0 = 0x00000000 > 2013-03-06 20:32:09 [26488] [11] DEBUG: sm_length: 48 = 0x00000030 > 2013-03-06 20:32:09 [26488] [11] DEBUG: short_message: > 2013-03-06 20:32:09 [26488] [11] DEBUG: Octet string at 0x7f36d0000f40: > 2013-03-06 20:32:09 [26488] [11] DEBUG: len: 48 > 2013-03-06 20:32:09 [26488] [11] DEBUG: size: 49 > 2013-03-06 20:32:09 [26488] [11] DEBUG: immutable: 0 > 2013-03-06 20:32:09 [26488] [11] DEBUG: data: 53 61 6d 73 6f 6e > 20 6b 61 72 69 75 6b 69 20 6e Some SMS content > 2013-03-06 20:32:09 [26488] [11] DEBUG: data: 6a 65 6e 67 61 20 > 32 38 38 39 36 39 38 20 2c 20 appears here <has > 2013-03-06 20:32:09 [26488] [11] DEBUG: data: 20 6b 69 61 6e 6a > 6f 67 75 20 20 2e 67 65 74 61 been trimmed> > 2013-03-06 20:32:09 [26488] [11] DEBUG: Octet string dump ends. > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP PDU dump ends. > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP[saf_receiver_b]: Sending PDU: > 2013-03-06 20:32:09 [26488] [20] DEBUG: send_msg: sending msg to box: > <127.0.0.1> > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP PDU 0x7f36d00016b0 dump: > 2013-03-06 20:32:09 [26488] [11] DEBUG: type_name: deliver_sm_resp > 2013-03-06 20:32:09 [26488] [11] DEBUG: command_id: 2147483653 = > 0x80000005 > 2013-03-06 20:32:09 [26488] [11] DEBUG: command_status: 0 = 0x00000000 > 2013-03-06 20:32:09 [26488] [11] DEBUG: sequence_number: 2 = 0x00000002 > 2013-03-06 20:32:09 [26488] [11] DEBUG: message_id: NULL > 2013-03-06 20:32:09 [26488] [11] DEBUG: SMPP PDU dump ends. > 2013-03-06 20:32:09 [26488] [20] DEBUG: boxc_sender: sent message to > <127.0.0.1> > 2013-03-06 20:32:09 [26488] [19] DEBUG: boxc_receiver: got ack > 2013-03-06 20:32:09 [26488] [16] DEBUG: SMPP[saf_7711]: Sending > enquire > link: > 2013-03-06 20:32:09 [26488] [16] DEBUG: SMPP PDU 0x7f36c502c720 dump: > 2013-03-06 20:32:09 [26488] [16] DEBUG: type_name: enquire_link > 2013-03-06 20:32:09 [26488] [16] DEBUG: command_id: 21 = 0x00000015 > 2013-03-06 20:32:09 [26488] [16] DEBUG: command_status: 0 = 0x00000000 > 2013-03-06 20:32:09 [26488] [16] DEBUG: sequence_number: 63 = 0x0000003f > 2013-03-06 20:32:09 [26488] [16] DEBUG: SMPP PDU dump ends. > 2013-03-06 20:32:11 [26488] [8] DEBUG: SMPP[saf_receiver_b]: Sending > enquire > link: > 2013-03-06 20:32:11 [26488] [8] DEBUG: SMPP PDU 0x7f36e4000e40 dump: > 2013-03-06 20:32:11 [26488] [8] DEBUG: type_name: enquire_link > 2013-03-06 20:32:11 [26488] [8] DEBUG: command_id: 21 = 0x00000015 > 2013-03-06 20:32:11 [26488] [8] DEBUG: command_status: 0 = 0x00000000 > 2013-03-06 20:32:11 [26488] [8] DEBUG: sequence_number: 89 = 0x00000059 > 2013-03-06 20:32:11 [26488] [8] DEBUG: SMPP PDU dump ends. > 2013-03-06 20:32:11 [26488] [15] DEBUG: SMPP[saf_receiver_b]: Got PDU: > 2013-03-06 20:32:11 [26488] [15] DEBUG: SMPP PDU 0x7f36c0000e40 dump: > 2013-03-06 20:32:11 [26488] [15] DEBUG: type_name: enquire_link_resp > 2013-03-06 20:32:11 [26488] [15] DEBUG: command_id: 2147483669 = > 0x80000015 > 2013-03-06 20:32:11 [26488] [15] DEBUG: command_status: 0 = 0x00000000 > 2013-03-06 20:32:11 [26488] [15] DEBUG: sequence_number: 13 = 0x0000000d > 2013-03-06 20:32:11 [26488] [15] DEBUG: SMPP PDU dump ends. > 2013-03-06 20:32:11 [26488] [18] DEBUG: Dumping 17016 messages to > store > > I can attach a more detailed log if you want. > > Thanks > > On Wed, Mar 6, 2013 at 6:40 PM, Rene Kluwen <rene.klu...@chimit.nl> wrote: >> Could you maybe share some log files details of the appropriate message? >> >> -----Original Message----- >> From: users-boun...@kannel.org [mailto:users-boun...@kannel.org] On >> Behalf Of Jam Hitz >> Sent: woensdag 6 maart 2013 16:34 >> To: Alexander Malysh >> Cc: users@kannel.org >> Subject: Re: No submit_sm_resp >> >> Hello, >> >> Sorry, I think I had read it wrong. The SMSC says that I am not >> responding to deliver_sm (not sending deliver_sm_resp) {NOT >> submit_sm_resp} as earlier indicated. What could be causing this? >> >> Please assist >> >> On Tue, Mar 5, 2013 at 6:24 PM, Alexander Malysh <amal...@kannel.org> > wrote: >>> And Kannel send generick NACK for unknown/wrong commands. >>> >>> Alex >>> >>> Am 05.03.2013 um 16:01 schrieb Jason Mule <jason.m...@gmail.com>: >>> >>>> Jam, >>>> >>>> The SMSC should send messages to you using either deliver_sm or >>>> data_sm >> PDUs. >>>> >>>> On 5 March 2013 09:24, Jam Hitz <is.mu...@gmail.com> wrote: >>>>> Hello. >>>>> >>>>> I have a very long queue of messages at the SMSC that Kannel is >>>>> picking up very, very slowly. We did a tcpdump and they concluded >>>>> that Kannel was not sending a submit_sm_resp after getting a >>>>> submit_sm causing the SMSC to re-transmit the submit_sm over and >>>>> over, hence the delay. >>>>> >>>>> Please help. My settings are as follows: >>>>> >>>>> # ======================== CORE ========================= group = >>>>> core admin-port = 13000 smsbox-port = 13001 admin-password = >>>>> password log-level = 0 store-type = file store-location = >>>>> /var/log/kannel/store_file store-dump-freq = 1 log-file = >>>>> "/var/log/kannel/bearerbox.log" >>>>> access-log = "/var/log/kannel/bearerbox_access.log" >>>>> box-deny-ip = "*.*.*.*" >>>>> box-allow-ip = "127.0.0.1" >>>>> dlr-storage = mysql >>>>> sms-resend-retry = 50 >>>>> >>>>> # ==================== SMS DAEMON ======================== group = >>>>> smsbox bearerbox-host = 127.0.0.1 sendsms-port = 13013 log-file = >>>>> "/var/log/kannel/smsbox.log" >>>>> log-level = 0 >>>>> access-log = "/var/log/kannel/smsbox_access.log" >>>>> http-request-retry = 10 >>>>> #sendsms-url=/send >>>>> mo-recode=true >>>>> >>>>> #---------- MYSQL DLR -------- >>>>> group = mysql-connection >>>>> id = mysql_dlr >>>>> host = localhost >>>>> username = dlr >>>>> password = dlr >>>>> database = dlr >>>>> max-connections = 1 >>>>> >>>>> group = dlr-db >>>>> id = mysql_dlr >>>>> table = dlr >>>>> field-smsc = smsc >>>>> field-timestamp = ts >>>>> field-destination = destination >>>>> field-source = source >>>>> field-service = service >>>>> field-url = url >>>>> field-mask = mask >>>>> field-status = status >>>>> field-boxc-id = boxc >>>>> >>>>> #=============== SERVICES =============== include = >>>>> "/etc/kannel/default_service.conf" >>>>> >>>>> >>>>> #=========== SMSC CONNECTIONS =========== >>>>> >>>>> group=smsc >>>>> smsc=smpp >>>>> smsc-id=saf_receiver_b >>>>> interface-version=34 >>>>> host=192.168.9.93 >>>>> receive-port=6695 >>>>> system-type= >>>>> smsc-username=<username> >>>>> smsc-password=<password> >>>>> log-level=0 >>>>> source-addr-ton = 2 >>>>> source-addr-npi = 1 >>>>> dest-addr-ton = 2 >>>>> dest-addr-npi = 1 >>>>> msg-id-type = 0x01 >>>>> alt-charset = "ASCII" >>>>> alt-addr-charset = "GSM" >>>>> enquire-link-interval = 5 >>>>> max-pending-submits = 20 >>>>> flow-control = 0 >>>>> window = 50 >>>>> wait-ack=120 >>>>> wait-ack-expire=0x02 >>>>> >>>> >>>> >>>> >>>> -- >>>> Kind regards >>>> Jason Mule >>>> >>> >> >> > >