So it looks deliver_sm_resps are being sent back without any delay. The assumption is that the SMSC sees "window full" when they don't get a certain number of ACKs within a period.
Have you tried sms-incoming-queue-limit = -1? Also you mentioned that dlr requests are posted to your server. Do you need MySQL DLR storage as well? You could try turning this off temporarily as well. On 28 November 2013 00:40, Jeff Thorn <[email protected]> wrote: > 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 >>> >>>>>>>>>> >>> >>>>>>>>>> >>> > -- Jason Mule
