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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >> > > > -- > > Jeff Thorn > Principal Software Architect > Thorn Technologies, LLC > (410) 429-0255 > www.thorntech.com > @thorntech <http://twitter.com/thorntech> | > LinkedIn<http://www.linkedin.com/in/jeffthorn> | > Facebook <http://www.facebook.com/thorntechnologies> >
