Here is one other thought.... we do have the following setting on the core group.
sms-incoming-queue-limit = 0 The docs for this say "Value 0 means giving strict priority to outgoing messages" What exactly does this mean? Could this affect incoming DLRs (or MOs for that matter) if we are doing a heavy volume of MTs? Thanks again! Jeff On Wed, Nov 27, 2013 at 4:11 PM, Jeff Thorn <[email protected]>wrote: > Yes....that is exactly what I meant. Thanks Jason. I only set > receive-port=0 on one of the transmitter binds as a test anyway. The others > do not have that, but do have transceiver-mode = 0. > > In the PDU debug log, I am seeing a few occasional "got DLR but could not > find message or was not interested in it" ERRORS but I don't think this is > related. I am getting < 20 of these errors for over 3,000,000 DLRs received > today. So I am not too concerned about these. > > The errors I am talking about "Window on receiver full" are not occurring > in my logs. They are being reported to me by the SMSC operator. It is > occurring on their end. > > Regardless, here is an excerpt of the PDU log that shows this error. Let > me know if you want to see anything else. Thanks! > > > 2013-11-27 00:10:04 [18849] [19] DEBUG: Optional parameter length read as 1 > 2013-11-27 00:10:04 [18849] [19] DEBUG: SMPP[s-send-1]: Got PDU: > 2013-11-27 00:10:04 [18849] [19] DEBUG: SMPP PDU 0x2aaaadaf3fc0 dump: > 2013-11-27 00:10:04 [18849] [19] DEBUG: type_name: deliver_sm > 2013-11-27 00:10:04 [18849] [19] DEBUG: command_id: 5 = 0x00000005 > 2013-11-27 00:10:04 [18849] [19] DEBUG: command_status: 0 = 0x00000000 > 2013-11-27 00:10:04 [18849] [19] DEBUG: sequence_number: 3355750 = > 0x00333466 > 2013-11-27 00:10:04 [18849] [19] DEBUG: service_type: "CMT" > 2013-11-27 00:10:04 [18849] [19] DEBUG: source_addr_ton: 2 = 0x00000002 > 2013-11-27 00:10:04 [18849] [19] DEBUG: source_addr_npi: 1 = 0x00000001 > 2013-11-27 00:10:04 [18849] [19] DEBUG: source_addr: "XXXXXXXXXXX" > 2013-11-27 00:10:04 [18849] [19] DEBUG: dest_addr_ton: 2 = 0x00000002 > 2013-11-27 00:10:04 [18849] [19] DEBUG: dest_addr_npi: 1 = 0x00000001 > 2013-11-27 00:10:04 [18849] [19] DEBUG: destination_addr: "XXXXX" > 2013-11-27 00:10:04 [18849] [19] DEBUG: esm_class: 4 = 0x00000004 > 2013-11-27 00:10:04 [18849] [19] DEBUG: protocol_id: 0 = 0x00000000 > 2013-11-27 00:10:04 [18849] [19] DEBUG: priority_flag: 0 = 0x00000000 > 2013-11-27 00:10:04 [18849] [19] DEBUG: schedule_delivery_time: NULL > 2013-11-27 00:10:04 [18849] [19] DEBUG: validity_period: NULL > 2013-11-27 00:10:04 [18849] [19] DEBUG: registered_delivery: 0 = > 0x00000000 > 2013-11-27 00:10:04 [18849] [19] DEBUG: replace_if_present_flag: 0 = > 0x00000000 > 2013-11-27 00:10:04 [18849] [19] DEBUG: data_coding: 0 = 0x00000000 > 2013-11-27 00:10:04 [18849] [19] DEBUG: sm_default_msg_id: 0 = 0x00000000 > 2013-11-27 00:10:04 [18849] [19] DEBUG: sm_length: 122 = 0x0000007a > 2013-11-27 00:10:04 [18849] [19] DEBUG: short_message: > 2013-11-27 00:10:04 [18849] [19] DEBUG: Octet string at 0x2aaaad657550: > 2013-11-27 00:10:04 [18849] [19] DEBUG: len: 122 > 2013-11-27 00:10:04 [18849] [19] DEBUG: size: 123 > 2013-11-27 00:10:04 [18849] [19] DEBUG: immutable: 0 > 2013-11-27 00:10:04 [18849] [19] DEBUG: data: 69 64 3a 30 35 37 31 36 > 34 30 39 31 39 20 73 75 id:0571640919 su > 2013-11-27 00:10:04 [18849] [19] DEBUG: data: 62 3a 30 30 31 20 64 6c > 76 72 64 3a 30 30 31 20 b:001 dlvrd:001 > 2013-11-27 00:10:04 [18849] [19] DEBUG: data: 73 75 62 6d 69 74 20 64 > 61 74 65 3a 31 33 31 31 submit date:1311 > 2013-11-27 00:10:04 [18849] [19] DEBUG: data: 32 37 30 30 31 30 20 64 > 6f 6e 65 20 64 61 74 65 270010 done date > 2013-11-27 00:10:04 [18849] [19] DEBUG: data: 3a 31 33 31 31 32 37 30 > 30 31 30 20 73 74 61 74 :1311270010 stat > 2013-11-27 00:10:04 [18849] [19] DEBUG: data: 3a 44 45 4c 49 56 52 44 > 20 65 72 72 3a 30 30 30 :DELIVRD err:000 > 2013-11-27 00:10:04 [18849] [19] DEBUG: data: 20 74 65 78 74 3a 50 6c > 65 61 73 65 20 6e 6f 74 text:Please not > 2013-11-27 00:10:04 [18849] [19] DEBUG: data: 65 20 74 68 61 74 20 77 > 65 20 e that we > 2013-11-27 00:10:04 [18849] [19] DEBUG: Octet string dump ends. > 2013-11-27 00:10:04 [18849] [19] DEBUG: message_state: 2 = 0x00000002 > 2013-11-27 00:10:04 [18849] [19] DEBUG: receipted_message_id: "22128c57" > 2013-11-27 00:10:04 [18849] [19] DEBUG: SMPP PDU dump ends. > 2013-11-27 00:10:04 [18849] [19] DEBUG: SMPP[s-send-1] handle_pdu, got DLR > 2013-11-27 00:10:04 [18849] [19] DEBUG: DLR[mysql]: Looking for DLR > smsc=s-send-1, ts=571640919, dst=XXXXXXXXXXX, type=1 > 2013-11-27 00:10:04 [18849] [19] DEBUG: sql: SELECT `mask`, `service`, > `url`, `source`, `destination`, `boxc` FROM `dlr` WHERE `smsc`=? AND `ts`=? > LIMIT 1 > 2013-11-27 00:10:04 [18849] [19] DEBUG: column=mask buffer_type=3 > max_length=0 length=10 > 2013-11-27 00:10:04 [18849] [19] DEBUG: column=service buffer_type=253 > max_length=0 length=40 > 2013-11-27 00:10:04 [18849] [19] DEBUG: column=url buffer_type=253 > max_length=0 length=255 > 2013-11-27 00:10:04 [18849] [19] DEBUG: column=source buffer_type=253 > max_length=0 length=40 > 2013-11-27 00:10:04 [18849] [19] DEBUG: column=destination buffer_type=253 > max_length=0 length=40 > 2013-11-27 00:10:04 [18849] [19] DEBUG: column=boxc buffer_type=253 > max_length=0 length=40 > 2013-11-27 00:10:04 [18849] [19] WARNING: DLR[mysql]: DLR from > SMSC<s-send-1> for DST<XXXXXXXXXXX> not found. > 2013-11-27 00:10:04 [18849] [19] ERROR: SMPP[s-send-1]: got DLR but could > not find message or was not interested in it id<571640919> > dst<XXXXXXXXXXX>, type<1> > 2013-11-27 00:10:04 [18849] [19] DEBUG: SMPP[s-send-1]: Sending PDU: > 2013-11-27 00:10:04 [18849] [19] DEBUG: SMPP PDU 0x2aaaaf7bfe20 dump: > 2013-11-27 00:10:04 [18849] [19] DEBUG: type_name: deliver_sm_resp > 2013-11-27 00:10:04 [18849] [19] DEBUG: command_id: 2147483653 = > 0x80000005 > 2013-11-27 00:10:04 [18849] [19] DEBUG: command_status: 0 = 0x00000000 > 2013-11-27 00:10:04 [18849] [19] DEBUG: sequence_number: 3355750 = > 0x00333466 > 2013-11-27 00:10:04 [18849] [19] DEBUG: message_id: NULL > > > > > On Wed, Nov 27, 2013 at 2:48 PM, Jason Mule <[email protected]> wrote: > >> I think he meant that he set receive-port = 0 on transmitters only and >> he only expects DLRs to come through on receiver binds. For some >> reason, he's getting DLRs on transmitter binds as well. >> >> Are you able to post your PDU logs? Just the sections with DLRs. >> >> On 27 November 2013 22:32, spameden <[email protected]> wrote: >> > Most likely that's because you set receiver-port = 0. >> > >> > >> > Check your smsc log as well and post here any errors you find. >> > >> > >> > 2013/11/27 Jeff Thorn <[email protected]> >> >> >> >> The SMSC Operator said they were getting "Window on receiver link full" >> >> errors from us when trying to send DLRs. Is that possible? >> >> >> >> We are not using sqlbox and we do have the dlr table indexed. I will >> >> confirm the version of kannel. >> >> >> >> >> >> On Wed, Nov 27, 2013 at 1:52 PM, spameden <[email protected]> wrote: >> >>> >> >>> >> >>> >> >>> >> >>> 2013/11/27 Jeff Thorn <[email protected]> >> >>>> >> >>>> I see. So does that mean the the DLRs I am seeing on the transmit >> binds >> >>>> are only status 8s? Would the volume of 8 messages impact the >> sending of >> >>>> other status from the SMSC? I am trying to understand the cause of >> the error >> >>>> from the operator "Window on receiver link full". >> >>> >> >>> >> >>> "Window on receiver" means your sending rate is much higher than your >> >>> operator allows you to. >> >>> >> >>> max-pending-submits - basically means "the window" - the number of >> >>> submit_sm's without response. >> >>> also there is throughput parameter which controls the actual number of >> >>> submit_sm's per second (acknowledged). >> >>> >> >>> well, volume of DLR=8 is equal to number of MT's you're pushing. >> >>> >> >>> but kannel receives DLR=8 from bearerbox not the SMSC operator. >> >>> >> >>> do you use sqlbox at all? also try adding an index on dlr table >> (smsc_id, >> >>> ts). >> >>> >> >>>> >> >>>> >> >>>> I appreciate your help with this. We are definitely doing a >> considerable >> >>>> volume. We do report the status of 8s. So I am thinking I may need >> to tune >> >>>> the mysql dlr database. >> >>> >> >>> >> >>> Most likely, try sending same amount of MTs without DLR and using >> >>> internal kannel storage. >> >>> >> >>> Btw, what's the kannel version you're on? Better use latest revision >> from >> >>> SVN, it's considered to be production stable. >> >>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Wed, Nov 27, 2013 at 1:32 PM, spameden <[email protected]> >> wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> 2013/11/27 Jeff Thorn <[email protected]> >> >>>>>> >> >>>>>> The documentation says to set receive-port = 0 to disable I/O on >> this >> >>>>>> bind. I tested this on the one sample config I posted and it had >> no effect. >> >>>>>> Our other binds look like this and they too are receiving DLRs. >> What should >> >>>>>> be changed to make this a "pure transmitter bind"? Will DLRs be >> received on >> >>>>>> pure transmitter binds? >> >>>>> >> >>>>> >> >>>>> That's correct. As I said before status=8 kannel sends DLR itself to >> >>>>> report that submit_sm was accepted. So if you don't want status=8 >> you need >> >>>>> to use appropriate dlr_mask, i.e. dlr_mask=1+2+16=19 (for rejected >> messages, >> >>>>> delivered, and failed). >> >>>>> >> >>>>>> >> >>>>>> >> >>>>>> group = smsc >> >>>>>> smsc = smpp >> >>>>>> smsc-id = s-send-1 >> >>>>>> smsc-admin-id = s-send-2 >> >>>>>> throughput = 150 >> >>>>>> transceiver-mode = 0 >> >>>>>> host = xxx.xxx.xxx.xxx >> >>>>>> port = 17800 >> >>>>>> smsc-username = "xxxxxx" >> >>>>>> smsc-password = xxxxx >> >>>>>> system-type = "" >> >>>>>> address-range = "" >> >>>>>> source-addr-ton = 2 >> >>>>>> source-addr-npi = 1 >> >>>>>> dest-addr-ton = 2 >> >>>>>> dest-addr-npi = 1 >> >>>>>> enquire-link-interval = 30 >> >>>>>> msg-id-type = 0x03 >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> On Wed, Nov 27, 2013 at 12:36 PM, Jason Mule <[email protected] >> > >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> First of all, to bind in pure transmitter mode do not set >> >>>>>>> receive-port. After this you should have 6 pure transmit binds >> and 4 pure >> >>>>>>> receiver binds. >> >>>>>>> >> >>>>>>> On Nov 27, 2013 8:15 PM, "Jeff Thorn" <[email protected] >> > >> >>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> Thanks for the response. In my scenario, we want to be able to >> send >> >>>>>>>> as fast as possible. We are regularly submitting MTs at a rate >> of 200 / >> >>>>>>>> second. We get DLRs at a rate of 1.5 - 2 times this (300 - 400 / >> second). >> >>>>>>>> This makes sense to me since we get multiple DLRs for every MT >> (status >> >>>>>>>> 8,4,1). We do need the DLRs for reporting purposes. Our >> architecture was >> >>>>>>>> just not setup to process them at the rate we are receiving them. >> >>>>>>>> >> >>>>>>>> The apache server that hosts our dlr.php says it is receiving >> >>>>>>>> requests at a rate of 30 / second. The kannel status page says >> we are >> >>>>>>>> receiving DLRs at a rate of 300 / second. I cannot figure out >> where the >> >>>>>>>> bottleneck is. The apache status page shows idle worker threads. >> So I do not >> >>>>>>>> think that is the bottleneck. Is smsbox not sending to our dlr >> url as fast >> >>>>>>>> as it is receiving them from the smsc? >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Wed, Nov 27, 2013 at 11:57 AM, spameden <[email protected]> >> >>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> You can control DLR via dlr_mask parameter, if its unset you >> won't >> >>>>>>>>> receive any DLRs. >> >>>>>>>>> >> >>>>>>>>> About speed - it's strange for me that speed of DLRs is much >> higher >> >>>>>>>>> than MT submit speed. >> >>>>>>>>> >> >>>>>>>>> Don't think there is any algorhythm implemented to control >> inbound >> >>>>>>>>> information coming, you might turn into transmitter mode, thus >> it should >> >>>>>>>>> stop receiving DLRs. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> 2013/11/27 Jeff Thorn <[email protected]> >> >>>>>>>>>> >> >>>>>>>>>> It looks like setting receive-port=0 has no effect on DLRs. Is >> >>>>>>>>>> there any way to control which binds receive DLRs or to >> somehow control how >> >>>>>>>>>> fast they are received? >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On Wed, Nov 27, 2013 at 10:15 AM, Jeff Thorn >> >>>>>>>>>> <[email protected]> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> If we are getting DRs faster than we can process them, I >> assume >> >>>>>>>>>>> if we reduce the number of receive binds the rate that we get >> DRs would go >> >>>>>>>>>>> down. Is this generally true? >> >>>>>>>>>>> >> >>>>>>>>>>> We have a total of 10 binds setup - the desired design is to >> have >> >>>>>>>>>>> 6 transmit binds for sending MTs and 4 receive binds for >> accepting MOs and >> >>>>>>>>>>> Deliver Receipts. However, it appears that all 10 of our >> binds are receiving >> >>>>>>>>>>> Delivery Receipts. The SMSC is reporting several "Windows on >> receiver links >> >>>>>>>>>>> full" errors. I assume this is because they are sending DRs >> faster than we >> >>>>>>>>>>> are able to process them. >> >>>>>>>>>>> >> >>>>>>>>>>> I tried setting receive-port = 0 on one of our transmit binds. >> >>>>>>>>>>> However, we still seem to be receiving DRs on this bind. Here >> the config for >> >>>>>>>>>>> this bind. Am I missing something? >> >>>>>>>>>>> >> >>>>>>>>>>> group = smsc >> >>>>>>>>>>> smsc = smpp >> >>>>>>>>>>> smsc-id = s-send-1 >> >>>>>>>>>>> smsc-admin-id = send-1 >> >>>>>>>>>>> throughput = 60 >> >>>>>>>>>>> host = xxx.xxx.xxx.xxx >> >>>>>>>>>>> port = 17800 >> >>>>>>>>>>> receive-port = 0 >> >>>>>>>>>>> smsc-username = "xxxxxxx" >> >>>>>>>>>>> smsc-password = xxxxxxx >> >>>>>>>>>>> system-type = "" >> >>>>>>>>>>> address-range = "" >> >>>>>>>>>>> source-addr-ton = 2 >> >>>>>>>>>>> source-addr-npi = 1 >> >>>>>>>>>>> dest-addr-ton = 2 >> >>>>>>>>>>> dest-addr-npi = 1 >> >>>>>>>>>>> enquire-link-interval = 30 >> >>>>>>>>>>> msg-id-type = 0x03 >> >>>>>>>>>>> >> >>>>>>>>>>> I appreciate any help on this issue. >> >>>>>>>>>>> >> >>>>>>>>>>> Thanks! >> >>>>>>>>>>> >> >>>>>>>>>>> Jeff >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On Tue, Nov 26, 2013 at 5:36 PM, Jeff Thorn >> >>>>>>>>>>> <[email protected]> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> Hello Group, >> >>>>>>>>>>>> We are receiving DLRs from the SMSC faster than we can >> process >> >>>>>>>>>>>> them. Our setup is supposed to have 6 transmit binds and 4 >> receive binds. >> >>>>>>>>>>>> However, I just looked at status page showing all our binds >> and it looks >> >>>>>>>>>>>> like all 10 of our binds are receiving DLRs and they are >> coming in at a rate >> >>>>>>>>>>>> greater than 250 / second. >> >>>>>>>>>>>> >> >>>>>>>>>>>> If I set the "receive-port" setting to 0 on our transmit >> binds, >> >>>>>>>>>>>> will I stop receiving DLRs on these binds? >> >>>>>>>>>>>> >> >>>>>>>>>>>> If this reduces the number of binds that can receive DLRs, >> >>>>>>>>>>>> should the rate they are received go down? Or is that >> totally dependent upon >> >>>>>>>>>>>> the SMSC? >> >>>>>>>>>>>> >> >>>>>>>>>>>> Is there anything I can control in my config that would >> reduce >> >>>>>>>>>>>> the rate they are received or is that something only the >> SMSC can control? >> >>>>>>>>>>>> >> >>>>>>>>>>>> Thanks, >> >>>>>>>>>>>> Jeff >> >>>>>>>>>> >> >>>>>>>>>> >> >>
