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