Strange Characters in MO Url from sms service
Hello All, I am seeing some odd characters in the HTTP call we are getting form smsbox for MOs. I expect the text from the phone to be: "RE: Testing reply ---testing iden" Here is the URL we are getting: /mo.php?id=b0be9dd5-2087-490c-8cb2-a34e15dd8b9f&sc=&phone=XX&text=RE%3A %C3%B6Testing+reply+--+Testing+iden&dt=2013-03-26+15:27:55&unixts=1364311675&coding=0&charset=UTF-8 HTTP/1.1" 200 165 "-" "Kannel/svn-r4910M" %3A is clearly the colon. Does anyone know what %C3%B6 are? In both ASCII and UTF-8, these are random characters that don't make any sense (o with diaeresis if utf8, A with tilde and paragraph sign in ascii). The charset field is listed as utf8, which would mean this character is ö. But I am quite sure the user did not enter this character on the phone. Any ideas? Thanks, Jeff
Windows on receiver links full (message queue full)
Hello Kannel Users, I need some help tracking down an issue that was reported to us by the SMSC we are connected to. They sent the following notification: We are seeing an increase in “Windows on receiver links full (message queue full)” on the RX binds to you, which is translating to x14 being sent back from you to the SMSC. These are primarily notifications (DAN) but a small percentage of these do appear to be actual messages (DAM). I am not really sure how to go about troubleshooting this. We did a tremendous amount of SMS Volume the day they reported these errors. Our kannel instance sent over 3.1 million MTs this day. I am guessing the issue was caused by the volume of delivery receipts generated by these MTs. We only have 2 incoming binds connected to the SMSC. Could that be the cause of the problem? Or is the problem related to latency in our application when processing the MO or DLR url? Here is the an excerpt of our kannel configuration. Is the error that the SMSC is reporting due to kannel itself or because our mo.php script is taking too long to return? Would additional incoming binds address the issue? group = core admin-port = 13000 admin-password = xx status-password = xx admin-deny-ip = "*.*.*.*" admin-allow-ip = "192.168.*.*" smsbox-port = 13001 #wapbox-port = 13002 box-deny-ip = "*.*.*.*" box-allow-ip = "192.168.*.*" wdp-interface-name = "*" log-file = "/var/log/kannel/bearerbox.log" log-level = 0 dlr-storage = mysql store-type = file store-location = /var/log/kannel/msg-store.db sms-incoming-queue-limit = 0 group = sms-service keyword-regex = .* catch-all = yes max-messages = 0 get-url = " http://192.168.11.100/sms/mo.php?id=%I&sc=%P&phone=%p&text=%a&meta=%D&dt=%t&unixts=%T " Thank you for your help! Jeff -- Jeff Thorn Principal Software Architect Thorn Technologies, LLC www.thorntech.com @thorntech <http://twitter.com/thorntech> | LinkedIn<http://www.linkedin.com/in/jeffthorn> | Facebook <http://www.facebook.com/thorntechnologies>
receiving DLRs too fast - how to throttle?
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
Re: receiving DLRs too fast - how to throttle?
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 = "xxx" smsc-password = xxx 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 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>
Re: receiving DLRs too fast - how to throttle?
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 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 = "xxx" > smsc-password = xxx > 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 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 >> >
Re: receiving DLRs too fast - how to throttle?
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 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 > >> 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 >> 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 = "xxx" >>> smsc-password = xxx >>> 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 >>> 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>
Re: receiving DLRs too fast - how to throttle?
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? 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 = "xx" smsc-password = x 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 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" 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 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 >>> >>>> 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 < >>>> j...@thorntechnologies.com> 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 = "xxx" >>>>> smsc-password = xxx >>>>> 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 >>>>> &g
Re: receiving DLRs too fast - how to throttle?
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 wrote: > > > > 2013/11/27 Jeff Thorn > >> 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 = "xx" >> smsc-password = x >> 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 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" >>> 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 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 >>>>> >>>>>> 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 < >>>>>> j...@thorntechnologies.com> 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 >>>>>
Re: receiving DLRs too fast - how to throttle?
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 wrote: > > > > 2013/11/27 Jeff Thorn > >> 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 wrote: >> >>> >>> >>> >>> 2013/11/27 Jeff Thorn >>> >>>> 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 = "xx" >>>> smsc-password = x >>>> 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 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" >>>>> 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 t
Re: receiving DLRs too fast - how to throttle?
[mysql]: DLR from SMSC for DST 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, 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 0x2f7bfe20 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 = 0x8005 2013-11-27 00:10:04 [18849] [19] DEBUG: command_status: 0 = 0x 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 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 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 > >> > >> 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 wrote: > >>> > >>> > >>> > >>> > >>> 2013/11/27 Jeff Thorn > >>>> > >>>> 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 wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> 2013/11/27 Jeff Thorn > >>>>>> > >>>>>> 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, > &
Re: receiving DLRs too fast - how to throttle?
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 wrote: > Yesthat 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 0x2daf3fc0 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 = 0x0005 > 2013-11-27 00:10:04 [18849] [19] DEBUG: command_status: 0 = 0x > 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 = 0x0002 > 2013-11-27 00:10:04 [18849] [19] DEBUG: source_addr_npi: 1 = 0x0001 > 2013-11-27 00:10:04 [18849] [19] DEBUG: source_addr: "XXX" > 2013-11-27 00:10:04 [18849] [19] DEBUG: dest_addr_ton: 2 = 0x0002 > 2013-11-27 00:10:04 [18849] [19] DEBUG: dest_addr_npi: 1 = 0x0001 > 2013-11-27 00:10:04 [18849] [19] DEBUG: destination_addr: "X" > 2013-11-27 00:10:04 [18849] [19] DEBUG: esm_class: 4 = 0x0004 > 2013-11-27 00:10:04 [18849] [19] DEBUG: protocol_id: 0 = 0x > 2013-11-27 00:10:04 [18849] [19] DEBUG: priority_flag: 0 = 0x > 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 = > 0x > 2013-11-27 00:10:04 [18849] [19] DEBUG: replace_if_present_flag: 0 = > 0x > 2013-11-27 00:10:04 [18849] [19] DEBUG: data_coding: 0 = 0x > 2013-11-27 00:10:04 [18849] [19] DEBUG: sm_default_msg_id: 0 = 0x > 2013-11-27 00:10:04 [18849] [19] DEBUG: sm_length: 122 = 0x007a > 2013-11-27 00:10:04 [18849] [19] DEBUG: short_message: > 2013-11-27 00:10:04 [18849] [19] DEBUG:Octet string at 0x2d657550: > 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 74text: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 = 0x0002 > 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=XXX, t
troubleshooting MT queuing in Kannel / MT queue persistence question
Hi group, We currently have 7 different Tx binds setup to our SMSC. We have been sending MT volumes of up to 3,000,000 messages per day at a rate of almost 200 / second. We've been doing this for more than a year now with no problems. Suddenly about a week and a half ago, we noticed our throughput drop suddenly. The kannel status page shows we are only sending about 150 msgs / sec, but each of the 7 binds have over 50,000 MT messages queued. These queues eventually empty out, but some messages get delivered hours later than when they were sent by our platform. I am trying to troubleshoot this sudden drop in throughput and excessive queuing. The only thing I can think of is network latency between our network and the SMSC network. I don't know how to go about troubleshooting this though. Is there any other reason that might explain the sudden need for excessive queuing? Side question.if kannel was restarted with so many MT messages queued for delivery, would they all be lost? Any assistance or tips for troubleshooting why so many messages are suddenly queuing would be extremely appreciated. Thanks, Jeff
Re: troubleshooting MT queuing in Kannel / MT queue persistence question
Thanks spamden. 1 and 2 seem fine. We are working on 3 and 4. I don't know what would have caused the sudden change in throughput when everything was working fine. But I will send an update for the group if we figure it out. I am noticing something strange thoughour MT queues are starting to deplete now. However, if I look at the kannel "store-status" page, I still see messages queued from 4 hours ago. All new MT requests, however, are now going out immediately. Is this by design? Why doesn't kannel send queued messages before newer ones? Thanks, Jeff On Tue, Mar 11, 2014 at 3:05 PM, spameden wrote: > > > > 2014-03-11 22:46 GMT+04:00 Jeff Thorn : > > Hi group, >> >> We currently have 7 different Tx binds setup to our SMSC. We have been >> sending MT volumes of up to 3,000,000 messages per day at a rate of almost >> 200 / second. We've been doing this for more than a year now with no >> problems. >> >> Suddenly about a week and a half ago, we noticed our throughput drop >> suddenly. The kannel status page shows we are only sending about 150 msgs / >> sec, but each of the 7 binds have over 50,000 MT messages queued. These >> queues eventually empty out, but some messages get delivered hours later >> than when they were sent by our platform. >> >> I am trying to troubleshoot this sudden drop in throughput and excessive >> queuing. The only thing I can think of is network latency between our >> network and the SMSC network. I don't know how to go about troubleshooting >> this though. Is there any other reason that might explain the sudden need >> for excessive queuing? >> > > There are many potential factors could be related to the actual sending > speed. > > Also I don't find speed in the kannel's web interface very accurate. > > 1) set verbose mode to 0 for your SMSC logs and check if there are any > throttling errors > 2) check for maximum number of open files for kannel (ulimit under kannel > user) and adjust if needed (this needed if you use kanel-store = spool) > 3) check your backend speed (e.g. dlr-url script or MySQL db how much > queries it can handle simultaneously). > 4) contact your SMSC operator for troubleshooting (e.g. tcpdump the > traffic and try to check if there are any network problems, massive tcp > retransmits or anything else) > > >> >> Side question.if kannel was restarted with so many MT messages queued >> for delivery, would they all be lost? >> > > No, if you're using kannel-spool or kannel-store mode. > >> >> Any assistance or tips for troubleshooting why so many messages are >> suddenly queuing would be extremely appreciated. >> >> Thanks, >> Jeff >> > >
Re: troubleshooting MT queuing in Kannel / MT queue persistence question
Hi spamden, I just wanted to follow up on this issue. It appeared that the reason for the sudden excessive queuing was because of another VM on the same VM server that was doing excessive disk I/O. We moved the VM and now only the kannel server is running and things seem much better. FYIwe are using store-type = file. And kannel would definitely start swapping once queues got too full. I do have one final question based on your previous reply. You said "Yes, it's by design, new submitted messages are going right after they are submitted". If new submitted messages go right away, even though there are older messages queued, can you briefly explain the logic that kannel uses to determine whether a message should be queued or sent right away? Thanks, Jeff On Wed, Mar 12, 2014 at 2:02 AM, spameden wrote: > > > > 2014-03-11 23:48 GMT+04:00 Jeff Thorn : > > Thanks spamden. 1 and 2 seem fine. We are working on 3 and 4. I don't know >> what would have caused the sudden change in throughput when everything was >> working fine. But I will send an update for the group if we figure it out. >> >> I am noticing something strange thoughour MT queues are starting to >> deplete now. However, if I look at the kannel "store-status" page, I still >> see messages queued from 4 hours ago. All new MT requests, however, are now >> going out immediately. Is this by design? Why doesn't kannel send queued >> messages before newer ones? >> > > Yes, it's by design, new submitted messages are going right after they are > submitted unless you use an sqlbox with custom SQL query to get only > certain MT messages to send to. > > What do you use for store? Spool or just a single file? > > Also check any errors in the dmesg or syslog. And check if kannel is > swapping or anything else (free -m). > >> >> Thanks, >> Jeff >> >> >> >> On Tue, Mar 11, 2014 at 3:05 PM, spameden wrote: >> >>> >>> >>> >>> 2014-03-11 22:46 GMT+04:00 Jeff Thorn : >>> >>> Hi group, >>>> >>>> We currently have 7 different Tx binds setup to our SMSC. We have been >>>> sending MT volumes of up to 3,000,000 messages per day at a rate of almost >>>> 200 / second. We've been doing this for more than a year now with no >>>> problems. >>>> >>>> Suddenly about a week and a half ago, we noticed our throughput drop >>>> suddenly. The kannel status page shows we are only sending about 150 msgs / >>>> sec, but each of the 7 binds have over 50,000 MT messages queued. These >>>> queues eventually empty out, but some messages get delivered hours later >>>> than when they were sent by our platform. >>>> >>>> I am trying to troubleshoot this sudden drop in throughput and >>>> excessive queuing. The only thing I can think of is network latency between >>>> our network and the SMSC network. I don't know how to go about >>>> troubleshooting this though. Is there any other reason that might explain >>>> the sudden need for excessive queuing? >>>> >>> >>> There are many potential factors could be related to the actual sending >>> speed. >>> >>> Also I don't find speed in the kannel's web interface very accurate. >>> >>> 1) set verbose mode to 0 for your SMSC logs and check if there are any >>> throttling errors >>> 2) check for maximum number of open files for kannel (ulimit under >>> kannel user) and adjust if needed (this needed if you use kanel-store = >>> spool) >>> 3) check your backend speed (e.g. dlr-url script or MySQL db how much >>> queries it can handle simultaneously). >>> 4) contact your SMSC operator for troubleshooting (e.g. tcpdump the >>> traffic and try to check if there are any network problems, massive tcp >>> retransmits or anything else) >>> >>> >>>> >>>> Side question.if kannel was restarted with so many MT messages >>>> queued for delivery, would they all be lost? >>>> >>> >>> No, if you're using kannel-spool or kannel-store mode. >>> >>>> >>>> Any assistance or tips for troubleshooting why so many messages are >>>> suddenly queuing would be extremely appreciated. >>>> >>>> Thanks, >>>> Jeff >>>> >>> >>> >> >
coding=0 vs coding=1
We've been using kannel for a very long time, sending messages with the default coding value of 0. We just received a complaint that underscore characters are not appearing in messages which I believe is a known issue with the GSM7 charset. I am trying to understand the impact of moving from a coding value of 0 to 1. The way our platform is configured, this would be a global change for all messages we send (our application does not know about the coding parameter, we'd have to hard code it into the URL for all kannel requests). Is there any risk of using coding=1 for all messages? Are there some handsets out there that will not be able to view the messages if the coding =1 ? Thanks, Jeff
Re: coding=0 vs coding=1
Just wanted to follow up on this question. What is the impact of moving from coding=0 to coding=1 for all MT messages? Do we risk some handsets not being able to view the message? 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> On Thu, Apr 10, 2014 at 5:39 PM, Jeff Thorn wrote: > We've been using kannel for a very long time, sending messages with the > default coding value of 0. We just received a complaint that underscore > characters are not appearing in messages which I believe is a known issue > with the GSM7 charset. > > I am trying to understand the impact of moving from a coding value of 0 to > 1. The way our platform is configured, this would be a global change for > all messages we send (our application does not know about the coding > parameter, we'd have to hard code it into the URL for all kannel requests). > Is there any risk of using coding=1 for all messages? Are there some > handsets out there that will not be able to view the messages if the coding > =1 ? > > Thanks, > Jeff > > >
ERROR due to Delivery Reports from different smsc-id
We are seeing an increased number of error messages like the following: ERROR: SMPP[bind-b]: got DLR but could not find message or was not interested in it id dst, type<1> We have a number of binds setup to handle bulk messaging (which may queue in kannel) or interactive messaging (which is less frequent). I've noticed these errors occur when we receive the Delivery Report on one bind (bind-b), but the original MT was sent from a different bind (bind-a). In the DLR database table, the message with the same id and dst exists, but the smsc value is different (bind-a vs bind-b). Is there anyway to ensure that Delivery Reports come back on the same smsc-id that the message was sent from? Thanks! Jeff
Re: ERROR due to Delivery Reports from different smsc-id
I've searched the user groups for this issue and everyone says to use the same smsc-id. We specifically need different smsc-ids so our interactive messages can be delivered in real time. On Wed, Apr 23, 2014 at 4:45 PM, Jeff Thorn wrote: > We are seeing an increased number of error messages like the following: > > ERROR: SMPP[bind-b]: got DLR but could not find message or was not > interested in it id dst, type<1> > > We have a number of binds setup to handle bulk messaging (which may queue > in kannel) or interactive messaging (which is less frequent). > > I've noticed these errors occur when we receive the Delivery Report on one > bind (bind-b), but the original MT was sent from a different bind (bind-a). > In the DLR database table, the message with the same id and dst exists, but > the smsc value is different (bind-a vs bind-b). > > Is there anyway to ensure that Delivery Reports come back on the same > smsc-id that the message was sent from? > > Thanks! > > Jeff > > >
Re: ERROR due to Delivery Reports from different smsc-id
I've searched the user groups for this issue and everyone says to use the same smsc-id. We specifically need different smsc-ids so our interactive messages can be delivered in real time and not get queued with our bulk messages. Is there anyway to ensure that Delivery Reports come back on the same smsc-id that the message was sent from? Otherwise, I don't understand why there is an option to specify different smsc-ids. Thanks! On Wed, Apr 23, 2014 at 4:45 PM, Jeff Thorn wrote: > We are seeing an increased number of error messages like the following: > > ERROR: SMPP[bind-b]: got DLR but could not find message or was not > interested in it id dst, type<1> > > We have a number of binds setup to handle bulk messaging (which may queue > in kannel) or interactive messaging (which is less frequent). > > I've noticed these errors occur when we receive the Delivery Report on one > bind (bind-b), but the original MT was sent from a different bind (bind-a). > In the DLR database table, the message with the same id and dst exists, but > the smsc value is different (bind-a vs bind-b). > > Is there anyway to ensure that Delivery Reports come back on the same > smsc-id that the message was sent from? > > Thanks! > > Jeff > > >
Re: ERROR due to Delivery Reports from different smsc-id
Thanks for the response spamden. That is very unfortunate. We have a legitimate need to have different smsc-ids but have only one account. How feasible would it be to use meta data or some other way to match the sending smsc-id instead of the receiving smsc-id? If all else fails, what is the risk of matching the DLR on destination and timestamp alone? The reason we need multiple smsc-id is because we are routing interactive messages to binds that are less active since many of our other binds may have several thousand messages queued at any given time. If using multiple smsc-ids is not a valid approach, is there some other way to accomplish what we are trying to do. Perhaps the "priority" field is what we need? How does the priority field affect MT messages on a bind that already has several thousand messages queued for sending by kannel? Thanks! Jeff On Thu, Apr 24, 2014 at 3:23 AM, spameden wrote: > > > > 2014-04-24 1:20 GMT+04:00 Jeff Thorn : > > I've searched the user groups for this issue and everyone says to use the >> same smsc-id. We specifically need different smsc-ids so our interactive >> messages can be delivered in real time and not get queued with our bulk >> messages. >> > > Only if you use same bind server and same login you need to use same > smsc-id parameter. Because remote server doesn't know through which > connection it should send DLR report. > >> >> Is there anyway to ensure that Delivery Reports come back on the same >> smsc-id that the message was sent from? Otherwise, I don't understand why >> there is an option to specify different smsc-ids. >> > > It's always the same from which it was sent, just make sure you don't have > same credentials / same server specified more than once. > >> >> Thanks! >> >> >> On Wed, Apr 23, 2014 at 4:45 PM, Jeff Thorn >> wrote: >> >>> We are seeing an increased number of error messages like the following: >>> >>> ERROR: SMPP[bind-b]: got DLR but could not find message or was not >>> interested in it id dst, type<1> >>> >>> We have a number of binds setup to handle bulk messaging (which may >>> queue in kannel) or interactive messaging (which is less frequent). >>> >>> I've noticed these errors occur when we receive the Delivery Report on >>> one bind (bind-b), but the original MT was sent from a different bind >>> (bind-a). In the DLR database table, the message with the same id and dst >>> exists, but the smsc value is different (bind-a vs bind-b). >>> >>> Is there anyway to ensure that Delivery Reports come back on the same >>> smsc-id that the message was sent from? >>> >>> Thanks! >>> >>> Jeff >>> >>> >>> >> >
Re: ERROR due to Delivery Reports from different smsc-id
Hi Juan, That is an interesting approach. Are you saying that if a bind has an smsc-id of "bind-a" but I add allowed-smsc-id with a value of "bind-b" then only messages that have the "smsc=bind-b" in the sendsms URL will get routed to that bind? It doesn't seem like that should work. Am I understanding your suggestion properly? Thanks! Jeff On Apr 26, 2014 10:26 AM, "Juan Nin" wrote: > > Use the same smsc-id on all of them, but different allowed-smsc-id on each. > That way the DLRs will all use the smsc-id, but you use the allowed-smsc-id to route your MTs. > > Also use smsc-admin-id so that you can start/stop/whatever each bind individually > > Regards > > > On Thu, Apr 24, 2014 at 10:49 AM, Jeff Thorn wrote: >> >> Thanks for the response spamden. That is very unfortunate. We have a legitimate need to have different smsc-ids but have only one account. How feasible would it be to use meta data or some other way to match the sending smsc-id instead of the receiving smsc-id? If all else fails, what is the risk of matching the DLR on destination and timestamp alone? >> >> The reason we need multiple smsc-id is because we are routing interactive messages to binds that are less active since many of our other binds may have several thousand messages queued at any given time. If using multiple smsc-ids is not a valid approach, is there some other way to accomplish what we are trying to do. Perhaps the "priority" field is what we need? How does the priority field affect MT messages on a bind that already has several thousand messages queued for sending by kannel? >> >> Thanks! >> >> Jeff >> >> >> >> >> On Thu, Apr 24, 2014 at 3:23 AM, spameden wrote: >>> >>> >>> >>> >>> 2014-04-24 1:20 GMT+04:00 Jeff Thorn : >>> >>>> I've searched the user groups for this issue and everyone says to use the same smsc-id. We specifically need different smsc-ids so our interactive messages can be delivered in real time and not get queued with our bulk messages. >>> >>> >>> Only if you use same bind server and same login you need to use same smsc-id parameter. Because remote server doesn't know through which connection it should send DLR report. >>>> >>>> >>>> Is there anyway to ensure that Delivery Reports come back on the same smsc-id that the message was sent from? Otherwise, I don't understand why there is an option to specify different smsc-ids. >>> >>> >>> It's always the same from which it was sent, just make sure you don't have same credentials / same server specified more than once. >>>> >>>> >>>> Thanks! >>>> >>>> >>>> On Wed, Apr 23, 2014 at 4:45 PM, Jeff Thorn wrote: >>>>> >>>>> We are seeing an increased number of error messages like the following: >>>>> >>>>> ERROR: SMPP[bind-b]: got DLR but could not find message or was not interested in it id dst, type<1> >>>>> >>>>> We have a number of binds setup to handle bulk messaging (which may queue in kannel) or interactive messaging (which is less frequent). >>>>> >>>>> I've noticed these errors occur when we receive the Delivery Report on one bind (bind-b), but the original MT was sent from a different bind (bind-a). In the DLR database table, the message with the same id and dst exists, but the smsc value is different (bind-a vs bind-b). >>>>> >>>>> Is there anyway to ensure that Delivery Reports come back on the same smsc-id that the message was sent from? >>>>> >>>>> Thanks! >>>>> >>>>> Jeff >>>>> >>>>> >>>> >>> >> >
deliver_sm_resp status if get-url is down?
Hi group, What does kannel report to SMSC if it cannot hit the URL specified in the get-url of the kannel sms-service configuration? More specifically - what status does kannel deliver to SMSC in DELIVER_SM_RESP pdu if the sms-service get-url is unavailable? Does it report an error back to the SMSC? If not, what is the recommended way of handling these errors. It is absolutely critical that we process every request received from smsc. If our web server that is hosting the get-url script is down, is there any way to reprocess messages received by kannel? Ideally it would report an error back to smsc so they can retry delivery. Is this possible? Thanks in advance for the help. Jeff
Re: deliver_sm_resp status if get-url is down?
Just following up on this question. Is there any way to report a failure to SMSC if the sms-server get-url is unavailable? Thanks! Jeff On Wed, Jun 25, 2014 at 5:06 PM, Jeff Thorn wrote: > Hi group, > What does kannel report to SMSC if it cannot hit the URL specified in the > get-url of the kannel sms-service configuration? > > More specifically - what status does kannel deliver to SMSC > in DELIVER_SM_RESP pdu if the sms-service get-url is unavailable? > > Does it report an error back to the SMSC? If not, what is the recommended > way of handling these errors. It is absolutely critical that we process > every request received from smsc. If our web server that is hosting the > get-url script is down, is there any way to reprocess messages received by > kannel? Ideally it would report an error back to smsc so they can retry > delivery. Is this possible? > > Thanks in advance for the help. > > Jeff > > >
impact of bearerbox running without smsbox
Hello, We had a instance of the bearerbox running for a few hours without smsbox running. Looks like we had a number of incoming message (deliver_sm) attempts. The logs show this (several times): WARNING: smsbox_list empty! WARNING: incoming messages queue too long, dropping a message WARNING: SMPP: Unknown TLV(0x000e,0x0001,03) for PDU type (deliver_sm) received! In this situation, what does bearerbox return to the SMSC in the deliver_sm_resp? I am trying to determine if we potentially lost incoming messages permanently. If bearerbox returns a status of success even though it could not deliver to sms, then I assume the messages are lost. If kannel returns a status of failure, then the SMSC should retry the failed message. Can someone confirm what bearerbox does in this situation? Thanks, Jeff
Re: impact of bearerbox running without smsbox
Unfortunately verbose logging was not turned on. All we see in the logs are errors and warnings. I am really trying to confirm what gets returned in the deliver_sm_resp pdu to the smsc. If it's 0, then I think messages are lost forever. If it's something else, then smsc should retry. On Sep 30, 2015 10:38 PM, "spameden" wrote: > > > 2015-10-01 5:23 GMT+03:00 Jeff Thorn : > >> Hello, >> We had a instance of the bearerbox running for a few hours without smsbox >> running. Looks like we had a number of incoming message (deliver_sm) >> attempts. >> >> The logs show this (several times): >> >> WARNING: smsbox_list empty! >> WARNING: incoming messages queue too long, dropping a message >> WARNING: SMPP: Unknown TLV(0x000e,0x0001,03) for PDU type (deliver_sm) >> received! >> >> In this situation, what does bearerbox return to the SMSC in the >> deliver_sm_resp? I am trying to determine if we potentially lost incoming >> messages permanently. If bearerbox returns a status of success even though >> it could not deliver to sms, then I assume the messages are lost. If kannel >> returns a status of failure, then the SMSC should retry the failed message. >> >> Can someone confirm what bearerbox does in this situation? >> > > I think in this situation brearerbox simply is receiving all messages from > your SMSC and not submitting any MT back. > > Basically bearerbox is a core communication center whilst smsbox/sqlbox is > used to submit/process messages on your side. > > You can try looking into logs of your smsc (if you had them turned on > verbose), there you must find all received messages. > > >> Thanks, >> Jeff >> >> >
RE: Kannel TPS reduces gradually if DLR is used
Are you storing dlrs in a database? Without the proper indexes it performance will definitely degrade as it takes longer and longer to look up the dlr. Kannel doesn't optimize the dlr database. You need to do that. On Apr 24, 2016 5:55 AM, "Nanda Kumar P" wrote: > Thanks for the quick response Vangelis. > > > > For point #1, All my texts are under less the 50 ASCII characters each. So > I expect one DLR for one outgoing SMS. > > > > Is there anything that I’m missing? > > > > Please do let me know if there is any other information required. I’ll be > happy to share. > > > > Thanks & Regards, > > Nanda > > > > *From:* Vangelis Typaldos [mailto:vty...@outlook.com] > *Sent:* 24 April 2016 15:19 > *To:* Nanda Kumar P; users@kannel.org > *Subject:* RE: Kannel TPS reduces gradually if DLR is used > > > > > > For point 1: It sounds like you get DLR for multipart sms. Note that for > multipart messages you receive DLR for each part. > > > > For point 2: You are absolutely correct. Ignore my statement. My bad. > > > > BR > > > > *From: *Nanda Kumar P > *Sent: *Sunday, April 24, 2016 10:34 AM > *To: *Vangelis Typaldos ; users@kannel.org > *Subject: *RE: Kannel TPS reduces gradually if DLR is used > > > > Thank you Vangelis. > > > > Few follow up questions though: > > 1. While I understand the point about the throughput dropping to > half, I fail to understand how it went as low as 25 per second. > > 2. What is the significance of changing the dlr-mask from 3 to 7 or > 15? Would it not lower the speeds further as it has to deal with calling > the dlr-url for two other flags aside from delivered and undelivered? > > > > Thanks & Regards, > > Nanda > > > > *From:* Vangelis Typaldos [mailto:vty...@outlook.com ] > > *Sent:* 24 April 2016 12:56 > *To:* Nanda Kumar P; users@kannel.org > *Subject:* RE: Kannel TPS reduces gradually if DLR is used > > > > The throughput assigned by your operator/smsc includes DLR activity. > > So the actual bind throughput would drop to the half you if you request > DLR for any MT. I would suggest to raise dlr-mask from 3 to 7 or 15. > > > > Kind Regards, > > Vangelis > > > > *From: *Nanda Kumar P > *Sent: *Sunday, April 24, 2016 8:08 AM > *To: *users@kannel.org > *Subject: *Kannel TPS reduces gradually if DLR is used > > > > Hi, > > > > I’m using kannel to send SMS to SMSC and in the send-sms url, I’m also > using the dlr-mask as 3 (Delivered and undelivered) and providing a dlr-url > callback for the same. > > I have set the throughput as 300/sec. > > > > If I do not use the delivery report, the TPS is consistent and close to > 300/sec. However, if I do use delivery report with the above said > parameters, the TPS starts from 300 but gradually reduces to less than 25 > per second. It would be great if someone can tell me what the reason for > this could be. > > > > Thanks & Regards, > > Nanda > > >
what to do with store.bak file after Kannel crash?
Hello Group, I just experienced a very rare crash of Kannel. We are using the following settings for store type: store-type = file store-location = /var/log/kannel/msg-store.db After restarting everything, I noticed a very large (3 GB) msg-store.db.bak file. Kannel took several minutes to start back up after this crash during this time the CPU was nearly maxed out. I assume during this time, Kannel was processing saved messages from the store file. Is this correct? What exactly is in the contents of the msg-store.db.bak file? Did these messages get handled by kannel or did the database simply get saved for backup purposes. Do I need to do anything specifically to handle all these messages in the .bak file? Or is it safe to delete now that kannel is back up? Thanks, Jeff
Re: Issue in sending long sms emojis
We have noticed the same issue. My guess is that since emojis are multi byte characters the message is getting split mid emoji. For the time being, we have a policy not to put an emoji character around the 36 character position. On Dec 13, 2016 1:21 AM, "Manas Mohanty" wrote: > Hi, > > I am sending emojis through kannel-1.4.4. > > Upto 35 emojis i,e without splitting the sms its delivered to the handset > without any issue. > > But if I send 36 emojis i,s more than one sms split 35 emojis and extra ?? > is getting delivered to handset. If I send 37 emojis, 36 and extra ?? is > getting delivered. > > So I think one character is getting split with long message(emojis) . > > Please suggest how I can send more that 35 emojis without any issue. > > Thanks, > Manas > > >
Re: web server information disclosure vulnerability
We always proxy kannel with Apache or Nginx. That should resolve your issue. Jeff Jeff Thorn CEO / Principal Software Architect Thorn Technologies, LLC www.thorntech.com @thorntech <http://twitter.com/thorntech> | LinkedIn <http://www.linkedin.com/in/jeffthorn> | Facebook <http://www.facebook.com/thorntechnologies> On Thu, Mar 16, 2017 at 10:34 AM, Ajay Patel wrote: > Hi All, > > Do kannel have any configuration to change "Server" information which is > coming in response of http response header. > > This leads to vulnerability "web server information disclosure". > > [image: Inline image 1] > > Thanks, > Ajay Patel > > > > *STL Disclaimer:* > The content of this message may be legally privileged and confidential and > are for the use of the intended recipient(s) only. It should not be read, > copied and used by anyone other than the intended recipient(s). If you have > received this message in error, please immediately notify the sender, > preserve its confidentiality and delete it. Before opening any attachments > please check them for viruses and defects. No employee or agent is > authorised to conclude any binding agreement on behalf of Sterlite > Technologies Limited with another party by email without express written > confirmation by authorised person. Visit us at www.sterlitetech.com > Please consider environment before printing this email ! > > > > >
Re: Any solution for MMS?
What kind of mms service do you need? We looked into mbuni a year or so ago and determined it was not stable enough for production. But since the mms mm4 spec is virtually identical to smtp we were easily able to implement something custom in java. The mm7 spec is based on soap, which is a pain. So we implemented a Rest style HTTP to MM4 interface for a major U.S. carrier that can send several hundred MMS messages per second. It processes the mm4 response messages as well to get delivery receipts and mobile originating messages. Reply to me directly without the user group if you want more info. Jeff Thorn CEO Thorn Technologies, LLC https://www.thorntech.com On Dec 20, 2017 8:38 PM, "Arya F" wrote: > There was the Mbuni project, but it looks like it's dead at this point, > the latest release is from 2011 and I read reports online that it no longer > compiles on newer Linux distros due to dependency issues. > > Is there anyway to have a MMS gateway? does Kannel have any plans to add > MMS support? >
bug? command_status field (%A) missing in DLR of split messages
Hello, I think we are experiencing a bug in kannel (1.4.4) that does not include command_status details in the DLR url for long messages that were split. See the excerpt of the debug log below. 2018-04-11 19:00:38 [30573] [6] ERROR: SMPP[]: SMSC returned error code 0x000b (Invalid Destination Address) in response to submit_sm PDU. 2018-04-11 19:00:38 [30573] [6] DEBUG: Set split msg status to 3 2018-04-11 19:00:38 [30573] [6] DEBUG: Parts of concatenated message failed. 2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[]: creating DLR message 2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[]: DLR = https://myurl/api/dlr?status=%d&code=%A&id=123456&dt=%t Normally for rejected messages the value of the %A parameter is something like: NACK/0x000b/Invalid Destination Address However, when the original MT message is a long message that gets split, the %A parameter in the DLR url looks like this: NACK/ Is this a known issue? Is there a fix for this? Thanks, Jeff Thorn
Re: bug? command_status field (%A) missing in DLR of split messages
Hi Kannel Users, I wanted to follow up on this issue I reported last week. Has anyone seen this before? I am having trouble getting the command_status field (%A) in my dlrs if the original MT message was a long sms message. Thanks, Jeff Jeff Thorn CEO / 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> On Wed, Apr 11, 2018 at 4:07 PM, Jeff Thorn wrote: > Hello, > I think we are experiencing a bug in kannel (1.4.4) that does not include > command_status details in the DLR url for long messages that were split. > See the excerpt of the debug log below. > > 2018-04-11 19:00:38 [30573] [6] ERROR: SMPP[]: SMSC returned error > code 0x000b (Invalid Destination Address) in response to submit_sm PDU. > 2018-04-11 19:00:38 [30573] [6] DEBUG: Set split msg status to 3 > 2018-04-11 19:00:38 [30573] [6] DEBUG: Parts of concatenated message > failed. > 2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[]: creating DLR message > 2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[]: DLR = > https://myurl/api/dlr?status=%d&code=%A&id=123456&dt=%t > > Normally for rejected messages the value of the %A parameter is something > like: > > NACK/0x000b/Invalid Destination Address > > However, when the original MT message is a long message that gets split, > the %A parameter in the DLR url looks like this: > > NACK/ > > Is this a known issue? Is there a fix for this? > > Thanks, > Jeff Thorn >
SMS command_status for long MT messages
Hi group, Looking for a little help on this The DLR command status flag (%A) appears blank when the original MT message was a long message ( > 160 chars). Is there a solution to this issue? Here is an example from our logs. 2018-04-11 19:00:38 [30573] [6] ERROR: SMPP[]: SMSC returned error code 0x000b (Invalid Destination Address) in response to submit_sm PDU. 2018-04-11 19:00:38 [30573] [6] DEBUG: Set split msg status to 3 2018-04-11 19:00:38 [30573] [6] DEBUG: Parts of concatenated message failed. 2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[]: creating DLR message 2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[]: DLR = https://myurl/api/dlr?status=%d&code=%A&id=123456&dt=%t Normally for rejected messages the value of the %A parameter is something like: NACK/0x000b/Invalid Destination Address However, when the original MT message is a long message that gets split, the %A parameter in the DLR url looks like this: NACK/ Any feedback is appreciated. Thanks! Jeff Thorn CEO / Principal Software Architect Thorn Technologies, LLC www.thorntech.com @thorntech <http://twitter.com/thorntech> | LinkedIn <http://www.linkedin.com/in/jeffthorn> | Facebook <http://www.facebook.com/thorntechnologies>
Re: SMS command_status for long MT messages
Hi Alex, Thanks for explaining, makes sense. The most common status we get is invalid destination address (0x000b). In this case all 3 parts in your example would have the same status. Would it make sense to include the status of it was the same for all parts? Jeff Thorn CEO Thorn Technologies, LLC https://www.thorntech.com On Sat, Jun 2, 2018, 8:09 AM wrote: > Hi, > > this is expected behaviour because we have to put all statuses into one > DLR message. > Just imagine if you have 3 parts and each of this part will be rejected > with different error code, > would you expect all 3 error codes in the status? > > Thanks, > Alex > > > Am 30.05.2018 um 20:50 schrieb Jeff Thorn : > > Hi group, > Looking for a little help on this The DLR command status flag (%A) > appears blank when the original MT message was a long message ( > 160 > chars). > > Is there a solution to this issue? Here is an example from our logs. > > 2018-04-11 19:00:38 [30573] [6] ERROR: SMPP[]: SMSC returned error > code 0x000b (Invalid Destination Address) in response to submit_sm PDU. > 2018-04-11 19:00:38 [30573] [6] DEBUG: Set split msg status to 3 > 2018-04-11 19:00:38 [30573] [6] DEBUG: Parts of concatenated message > failed. > 2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[]: creating DLR message > 2018-04-11 19:00:38 [30573] [6] DEBUG: SMSC[]: DLR = > https://myurl/api/dlr?status=%d&code=%A&id=123456&dt=%t > > Normally for rejected messages the value of the %A parameter is something > like: > > NACK/0x000b/Invalid Destination Address > > However, when the original MT message is a long message that gets split, > the %A parameter in the DLR url looks like this: > > NACK/ > > Any feedback is appreciated. Thanks! > > > Jeff Thorn > CEO / Principal Software Architect > Thorn Technologies, LLC > www.thorntech.com > @thorntech <http://twitter.com/thorntech> | LinkedIn > <http://www.linkedin.com/in/jeffthorn> | Facebook > <http://www.facebook.com/thorntechnologies> > > >
Re: Kannel delivering MT in LIFO
I've notice this in the past as well. In our case it seems to occur when we send a large number of messages in "batch A" which causes messages to queue in the local file store. We use the kannel status monitor web interface quite often. When this occurs, the status page shows the number of queued messages increasing. At the same time, the sending rate of outgoing MT messages goes down. My guess is that kannel is spending more time writing to disk vs sending directly to the smsc. When "batch B" starts, it appears that some of these messages are sent immediately instead of being cached in the local file store, which would resemble the LIFO scenario you described. I've been very curious about the logic kannel implements to decide when to cache messages locally and when not to. For what it's worth, this started happening less frequently for us when we began using redis for the dlr store. It is much faster than the mysql db we where using. Now this doesn't happen until we exceed 400 messages per second on a single kannel server. When we load balance multie kannel instances, we can reach nearly 1000 messages per second before this occurs. Hope this helps. Maybe someone can elaborate on that local caching logic. Jeff Thorn CEO Thorn Technologies, LLC https://www.thorntech.com On Sat, Oct 19, 2019, 12:15 PM Rene Kluwen wrote: > Your observaction is a bit “odd” in the sense that by nature, Kannel > should send messages FIFO. > > > > The smpp smsc handles things differently as it takes the priority field > into account. The http smsc does not. > > > > Apart from that SMS in general is store-and-forward and a particular order > is not guaranteed so you cannot rely and that either. Even though that > wasn’t your question. > > > > You can consider this as a background – I know it’s not a definitive > answer, but maybe it helps. > > > > == Rene > > > > > > *Van:* users *Namens *Louis Rouxel > *Verzonden:* zaterdag 19 oktober 2019 16:06 > *Aan:* users@kannel.org > *Onderwerp:* Kannel delivering MT in LIFO > > > > Hello there, > > > > > > I'm currently having issues with Kannel delivering MTs in LIFO (last in > first out) priority mode. > > > > I'm using Kannel 1.4.4 and filesystem directory spool storage (Debian > jessie, ext4). > > > > I'm submitting large amounts of messages (let's call them "batch A)" for > via cgi-bin/sendsms http endpoint; they all get ingested in the store. > > > > One hour later, some messages are still in queue, and I'm submitting a > large amount of another message (let's call them "batch B"), the same way. > > > > Both messages are sent without any priority defined. > > > > > > What I'm observing, in such situations, is that delivery of messages from > batch A are interrupted when batch B starts, Kannel is now only delivering > messages from batch B. > > Deliveries for batch A will only resume when batch B is finished. > > > > I've been trying to understand if Kannel "officially" working in LIFO or > FIFO, but can't really get a proper understanding. > > > > 9 years ago, Nikos seemed to indicate the queue should work in FIFO > > https://www.kannel.org/pipermail/users/2010-July/011951.html > > > > But that's really not what I'm observing. > > Also, I found someone suggesting a patch to make Kannel work in FIFO > instead of LIFO (that would confirm my supposition) > > https://stackoverflow.com/questions/37461349/kannel-queue-type > > > > But unfortunately this does not get a lot of attention, and I'm not very > comfortable changing the source code as I have no experience in C. > > > > > > What do you guys think? > > Can anyone confirm if Kannel is operating in LIFO and the behaviour I'm > observing is normal? > > Would anyone have a recommendation to achieve a FIFO behaviour without > taking too many risks? > > > > > > Thanks a lot, > > > > -- > > Louis >
what happens if kannel cannot store dlr?
We are using Redis for our DLR store. If there is an issue with the Redis database and kannel cannot save the DLR info, does the MT request get sent anyway or does the whole request fail? Thanks! Jeff Thorn CEO Thorn Technologies, LLC www.thorntech.com @thorntech <http://twitter.com/thorntech> | LinkedIn <http://www.linkedin.com/in/jeffthorn> | Facebook <http://www.facebook.com/thorntechnologies>
Re: Temporary message store for multi-part SMSs
We have encountered this very situation. The solution I settled on has multiple kannel servers configured with transmit binds. So a load balancer can hit any instance for sending MT messages. However, only ONE instance is configured with receive binds. My logic was that the SMSC will queue MO and DLR messages if this one kannel instance goes down. So we really don't need to load balance for receiving messages. Since all MOs are coming in to the same server, long messages will be properly concatinated. This works fine for us because the volume of MT messages we send is significantly higher than MOs. We queue the DLRs and process them asynchronously at our own pace so the one kannel server with receive binds doesn't get bogged down. Hope this helps. Jeff Thorn CEO Thorn Technologies, LLC https://www.thorntech.com On Sun, Mar 29, 2020, 3:49 PM Antony Stone < antony.st...@kannel.open.source.it> wrote: > On Sunday 29 March 2020 at 18:42:12, Alexander Malysh wrote: > > > Hi, > > > > unfortunately you mixed two things together. > > Very probably. I didn't find the documentation too clear on this topic. > > > 1. Store support. > > It’s a snapshot of messages that Kannel has in his memory (RAM) > stored > > either on disk (spool, file) or in Redis. This store is used for a case > if > > Kannel crashes, then messages are not lost. This is _NOT_ shared between > > Kannel instances, but different instance can read store if first instance > > gone for long time. > > So, is this where the first-received part of a multi-part message gets > stored, > so that it can be combined with the second part when that arrives? > > You say that this is not shared between kannel instances - what happens if > two > instances are pointing at the same redis database, and each receives one > part > of the multi-part message? > > > 2. DLR support. > > It’s temp. DLR storage to storing messages where Kannel still > waiting for > > a DLR to arrive. DLR storage can be shared (like same MySQL DB and table) > > and if one instance receive DLR for the message sent via second instance, > > DLR will be mapped and processed (please set same SMSC-IDs for both > > instances/binds). > > Yes, this is working fine for me. DLRs are processed successfully even > when > kannel instance A sent the message and kannel instance B gets the DLR. > > > DBPool is just internal Kannel Database Pool that supports multiple > > databases and is used for all database accesses in kannel. > > So, if that's used for "all database accesses in kannel", why can't I use > the > MySQL connection which works for DLR, as the message store (which seems > only > to know about redis)? > > > I hope it’s a little bit clearer now. > > In some ways, yes, but I'm still wondering what is the solution for a load- > balanced pair of kannel servers where each receives a different part of a > multi-part SMS from the upstream SMSC. > > I don't see any way in which either of my servers could know that the > other > one has already seen the other part of the message, and therefore either: > > a) reject the subsequent part so that the remote SMSC delivers it instead > to > the "first" server, or > > b) forward the second part itself to the "first" server. > > So, what do other people do in such a situation? > > > Thanks, > > > Antony. > > -- > There are 10 types of people in the world: > those who understand binary notation, > and those who don't. > >Please reply to the > list; > please *don't* CC > me. > >
Re: Pipe Symbol Issue
The pipe symbol is not a standard GSM 7 character. It needs to be escaped when using the default 7 bit charset ( https://www.developershome.com/sms/gsmAlphabet.asp). Try changing your "coding" param to 1 to for 8 bit characters, or 2 if you need extended utf8 characters. https://kannel.org/download/1.5.0/userguide-1.5.0/userguide.html#AEN4623 Jeff Thorn CEO Thorn Technologies, LLC www.thorntech.com @thorntech <http://twitter.com/thorntech> | LinkedIn <http://www.linkedin.com/in/jeffthorn> | Facebook <http://www.facebook.com/thorntechnologies> On Tue, Aug 18, 2020 at 2:53 PM Wan Md Arif Noor Bin. Wan Nizam < md.a...@forest-interactive.com> wrote: > Hi Anyone? > > > > I’ve updated to svn-r5302M and still seeing the same problem. > > > > 26892:2020-08-19 02:45:42 [9506] [7] DEBUG: SMPP PDU 0x7efcd8006d30 dump: > > 26893:2020-08-19 02:45:42 [9506] [7] DEBUG: type_name: submit_sm > > 26894:2020-08-19 02:45:42 [9506] [7] DEBUG: command_id: 4 = 0x0004 > > 26895:2020-08-19 02:45:42 [9506] [7] DEBUG: command_status: 0 = > 0x > > 26896:2020-08-19 02:45:42 [9506] [7] DEBUG: sequence_number: 8 = > 0x0008 > > 26897:2020-08-19 02:45:42 [9506] [7] DEBUG: service_type: NULL > > 26898:2020-08-19 02:45:42 [9506] [7] DEBUG: source_addr_ton: 0 = > 0x > > 26899:2020-08-19 02:45:42 [9506] [7] DEBUG: source_addr_npi: 1 = > 0x0001 > > 26900:2020-08-19 02:45:42 [9506] [7] DEBUG: source_addr: "" > > 26901:2020-08-19 02:45:42 [9506] [7] DEBUG: dest_addr_ton: 1 = 0x0001 > > 26902:2020-08-19 02:45:42 [9506] [7] DEBUG: dest_addr_npi: 1 = 0x0001 > > 26903:2020-08-19 02:45:42 [9506] [7] DEBUG: destination_addr: "" > > 26904:2020-08-19 02:45:42 [9506] [7] DEBUG: esm_class: 3 = 0x0003 > > 26905:2020-08-19 02:45:42 [9506] [7] DEBUG: protocol_id: 0 = 0x > > 26906:2020-08-19 02:45:42 [9506] [7] DEBUG: priority_flag: 0 = 0x > > 26907:2020-08-19 02:45:42 [9506] [7] DEBUG: schedule_delivery_time: NULL > > 26908:2020-08-19 02:45:42 [9506] [7] DEBUG: validity_period: NULL > > 26909:2020-08-19 02:45:42 [9506] [7] DEBUG: registered_delivery: 0 = > 0x > > 26910:2020-08-19 02:45:42 [9506] [7] DEBUG: replace_if_present_flag: 0 = > 0x > > 26911:2020-08-19 02:45:42 [9506] [7] DEBUG: data_coding: 0 = 0x > > 26912:2020-08-19 02:45:42 [9506] [7] DEBUG: sm_default_msg_id: 0 = > 0x > > 26913:2020-08-19 02:45:42 [9506] [7] DEBUG: sm_length: 2 = 0x0002 > > 26914:2020-08-19 02:45:42 [9506] [7] DEBUG: short_message: > > 26915:2020-08-19 02:45:42 [9506] [7] DEBUG:Octet string at > 0x7efcd80058f0: > > 26916:2020-08-19 02:45:42 [9506] [7] DEBUG: len: 2 > > 26917:2020-08-19 02:45:42 [9506] [7] DEBUG: size: 1024 > > 26918:2020-08-19 02:45:42 [9506] [7] DEBUG: immutable: 0 > > 26919:2020-08-19 02:45:42 [9506] [7] DEBUG: data: 1b > 40 .@ > > 26920:2020-08-19 02:45:42 [9506] [7] DEBUG:Octet string dump ends. > > 26921:2020-08-19 02:45:42 [9506] [7] DEBUG: SMPP PDU dump ends. > > > > Best Regards > > > > *From:* users *On Behalf Of *Wan Md Arif Noor > Bin. Wan Nizam > *Sent:* Tuesday, August 18, 2020 6:05 PM > *To:* kannel users@kannel.org > *Subject:* Pipe Symbol Issue > > > > Hi There, > > > > I’ve notice that sending | symbol converted into @ instead regardless > alt-charset set to UTF-8 or not. Kindly assist. > > > > CGI : > > > > curl > "localhost:13017/cgi-bin/sendsms?username=smsSMPP2&password=smsPass&from=68123&SMPP2&to=601132495424&text=%7c" > > > > Kannel bearerbox version `svn-r5299M'. > > > > Debug Log : > > > > 291852:2020-08-18 17:44:37 [62170] [7] DEBUG: SMPP PDU 0x7fa23c01c3a0 dump: > > 291853:2020-08-18 17:44:37 [62170] [7] DEBUG: type_name: submit_sm > > 291854:2020-08-18 17:44:37 [62170] [7] DEBUG: command_id: 4 = 0x0004 > > 291855:2020-08-18 17:44:37 [62170] [7] DEBUG: command_status: 0 = > 0x > > 291856:2020-08-18 17:44:37 [62170] [7] DEBUG: sequence_number: 9333 = > 0x2475 > > 291857:2020-08-18 17:44:37 [62170] [7] DEBUG: service_type: NULL > > 291858:2020-08-18 17:44:37 [62170] [7] DEBUG: source_addr_ton: 0 = > 0x > > 291859:2020-08-18 17:44:37 [62170] [7] DEBUG: source_addr_npi: 1 = > 0x0001 > > 291860:2020-08-18 17:44:37 [62170] [7] DEBUG: source_addr: "68123" > > 291861:2020-08-18 17:44:37 [62170] [7] DEBUG: dest_addr_ton: 1 = > 0x0001 > > 291862:2020-
