Hi Spameden, Didn't know the reason from all those "got delivery but can't find message..." myself . Thanks. Great to be aware.
Saludos Ombongi Moraa fe On 5 February 2013 12:56, <users-requ...@kannel.org> wrote: > Send users mailing list submissions to > users@kannel.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.kannel.org/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > users-requ...@kannel.org > > You can reach the person managing the list at > users-ow...@kannel.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of users digest..." > > > Today's Topics: > > 1. Re: AW: Multiple SMSC connections to the same SMSC Instace > DLR inconsistency (spameden) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 5 Feb 2013 13:55:56 +0400 > From: spameden <spame...@gmail.com> > To: David Szanto <dsza...@genasys.com> > Cc: users@kannel.org > Subject: Re: AW: Multiple SMSC connections to the same SMSC Instace > DLR inconsistency > Message-ID: > <CAHCALeya61NT-fA= > pcf8lc+p0svpnj484xb-dkho7b1ozvd...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Kannel only requests DLR for the first part of each message. > > So if you're sending concatenated message that means you're getting only 1 > DLR instead of the X DLRs for each message part. > > Some SMSC operators sending anyways X DLRs instead of 1 even if you don't > request DLR for each part, hope that helps. > > 2013/2/5 David Szanto <dsza...@genasys.com> > > > Hi spameden! > > Thanks for the info! that is VERY helpfull. We've been testing a lot > > using the same smsc-id but we're still getting the error message at least > > 900 times for every 100000 DLR recieved. > > The only difference now is that the message mentions type=2 instead of 1. > > > > > > 2013-02-04 11:92:35 [33491] [11] ERROR: SMPP[A]: got DLR but could not > > find message or was not interested in it id<27299> dst<20034628200743>, > > type<2> > > > > We'll be testing what Alvaro suggested regarding the msg-id-type > parameter > > in conjuntion to having the same smsc-id, which is clearly something we > > should be doing. > > > > Also, we're not very sure if some routing would help or not in this case. > > Thanks for all your input!! > > David > > > > El 04/02/13 09:55, spameden escribi?: > > > > Kannel matches specific DLR via SMSC-id (defined in the config) and > Unique > > ID given by your SMSC operator. > > > > Are you using MySQL as a backend for DLRs? > > > > As everyone stated before if you're using multiple logins to the same > SMSC > > operator just use same SMSC-ID. > > > > 2013/2/4 David Szanto <dsza...@genasys.com> > > > >> Hi Thomas!! > >> Thanks for the tips!! > >> We did try setting the same name for all smsc-id's, but had no luck. We > >> still got the error message for certain DLR that got unmatch with their > >> original MT message. > >> > >> The problem was that since they all had the same ids, we could tell what > >> connection was used to send back the DLR. Yet, it didn't help much. > >> We'll try doing what Alvaro suggested (testing the DLR id in Hex vs > >> Decimal, etc... ) plus setting all smsc-id's the same. > >> > >> Correct me if I'm wrong, but kannel sets the ID for the message using > the > >> message ID + the SMSC-ID, right? > >> Are there any more parameters used in the equation? > >> > >> Thanks you all for the help!!! > >> > >> > >> El 01/02/13 14:51, Thomas G?ttgens escribi?: > >> > >> Use the same name for the SMSC ID's. So not A,B,C and D but just A. > This way > >> no matter what link the DLR is delivered on, it will match the original > >> message. We've had the same setup in production with 6 binds (via > EMI/UCP) > >> for years. > >> > >> -----Urspr?ngliche Nachricht----- > >> Von: users-boun...@kannel.org [mailto:users-boun...@kannel.org < > users-boun...@kannel.org>] Im Auftrag > >> von David Szanto > >> Gesendet: Freitag, 1. Februar 2013 14:10 > >> An: users@kannel.org > >> Betreff: Multiple SMSC connections to the same SMSC Instace DLR > >> inconsistency > >> > >> Hi everyone! > >> > >> We have a scenario with a single SMSC (using SMPP) for which we have > >> created 4 binds. > >> > >> So basically we have 4 SMSC groups in kannel for a single SMSC (and > >> single account). > >> > >> We'll call Binds A,B,C and D. > >> > >> So, message 328515 is sent using bind A, but DLR for this message is > >> delivered from the SMSC using bind B, which results in the following log > >> error: > >> > >> smsc-sim4.log:2013-01-29 12:55:57 [16831] [35] ERROR: SMPP[B]: got DLR > >> but could not find message or was not interested in it id<328515> > >> dst<20034628200743>, type<1> > >> > >> Except for the smsc-id parameter, all other SMSC configuration > >> parameters in kannel are identical: > >> > >> group = smsc > >> smsc = smpp > >> smsc-id = A > >> host = smschost > >> port = 2771 > >> receive-port = 2771 > >> smsc-username = smppclient1 > >> smsc-password = password > >> system-type = VMA > >> log-file = /var/log/kannel/smsc-sim1.log > >> log-level = 0 > >> > >> group = smsc > >> smsc = smpp > >> smsc-id = B > >> host = smschost > >> port=2771 > >> receive-port = 2771 > >> smsc-username = smppclient1 > >> smsc-password = password > >> system-type = VMA > >> log-file = /var/log/kannel/smsc-sim1.log > >> log-level = 2 > >> > >> group = smsc > >> smsc = smpp > >> smsc-id = C > >> host = smschost > >> port=2771 > >> receive-port = 2771 > >> smsc-username = smppclient1 > >> smsc-password = password > >> system-type = VMA > >> log-file = /var/log/kannel/smsc-sim1.log > >> log-level = 2 > >> > >> group = smsc > >> smsc = smpp > >> smsc-id = D > >> host = smschost > >> port=2771 > >> receive-port = 2771 > >> smsc-username = smppclient1 > >> smsc-password = password > >> system-type = VMA > >> log-file = /var/log/kannel/smsc-sim1.log > >> log-level = 2 > >> > >> > >> > >> We believe that because the DLR messages are incomming using a different > >> smsc connection, the internal record for that message (328515) doesn't > >> match up, thus leaving kannel not knowing what message the DLR recieved > >> is for. > >> > >> So here is our question: > >> If this is the problem: > >> How can we avoid this? > >> How can we assure kannel is able to match up DLR messages with their > >> corresponding MT records? > >> > >> Any help will be greatly appreciated!! > >> > >> Thanks! > >> > >> David Szanto > >> > >> > >> > >> > >> > >> -- > >> > >> *David Szanto > >> Sistemas* > >> > >> * * > >> > >> (+34) 91 364 91 00 - ext. 116 > >> dsza...@genasys.com > >> > >> Genasys II Spain, S.A.U. > >> Pza. Sta. Mar?a Soledad Torres Acosta, 2, 4?A > >> 28004 Madrid > >> www.genasys.com > >> > >> This message contains confidential information and is intended only for > >> the individual named. If you are not the named addressee you should not > >> disseminate, distribute or copy this e-mail. Please notify the sender > >> immediately by e-mail if you have received this e-mail by mistake and > >> delete this e-mail from your system. E-mail transmission cannot be > >> guaranteed to be secure or error-free as information could be > intercepted, > >> corrupted, lost, destroyed, arrive late or incomplete, or contain > viruses. > >> The sender therefore does not accept liability for any errors or > omissions > >> in the contents of this message, which arise as a result of e-mail > >> transmission. > >> > > > > > > > > -- > > > > *David Szanto > > Sistemas* > > > > * * > > > > (+34) 91 364 91 00 - ext. 116 > > dsza...@genasys.com > > > > Genasys II Spain, S.A.U. > > Pza. Sta. Mar?a Soledad Torres Acosta, 2, 4?A > > 28004 Madrid > > www.genasys.com > > > > This message contains confidential information and is intended only for > > the individual named. If you are not the named addressee you should not > > disseminate, distribute or copy this e-mail. Please notify the sender > > immediately by e-mail if you have received this e-mail by mistake and > > delete this e-mail from your system. E-mail transmission cannot be > > guaranteed to be secure or error-free as information could be > intercepted, > > corrupted, lost, destroyed, arrive late or incomplete, or contain > viruses. > > The sender therefore does not accept liability for any errors or > omissions > > in the contents of this message, which arise as a result of e-mail > > transmission. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.kannel.org/pipermail/users/attachments/20130205/737ab2ac/attachment.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: image/png > Size: 12175 bytes > Desc: not available > URL: < > http://www.kannel.org/pipermail/users/attachments/20130205/737ab2ac/attachment.png > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: image/png > Size: 12175 bytes > Desc: not available > URL: < > http://www.kannel.org/pipermail/users/attachments/20130205/737ab2ac/attachment-0001.png > > > > ------------------------------ > > _______________________________________________ > users mailing list > users@kannel.org > http://www.kannel.org/mailman/listinfo/users > > > End of users Digest, Vol 78, Issue 9 > ************************************ >
