Re: Another broken SMSC DLR implementation?
"David Tully" <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <009901c3a923$733a83b0$ae36fea9@DELLLAPTOP> |
If you're running all connections on one bearerbox instance, follow Stipe's advice. I've two binds to one operator, running separate bearerbox/smsbox instances. It works like this: The client app is aware of which bind to send messages down. When going out on one bind, DLR status 12 gets written to mysql DLR. DLR status 1 comes in on other bind - looks up the record in mysql and finds a match, because the SMSC-ID's are the same. ----- Original Message ----- From: Alex Kinch To: David Tully ; [email protected] Sent: Wednesday, November 12, 2003 1:34 PM Subject: Re: Another broken SMSC DLR implementation? Thanks Dave How would giving the binds the same SMSC-ID affect a request to suspend a particular connection, or if one of the connections goes down? We're binding four connections on one instance of bearerbox to two smpp systems on this provider, as explained on a previous mail one on each system for alpha sender and one on each system for numeric sender. Alex ----- Original Message ----- From: David Tully To: [email protected] ; Alex Kinch Sent: Wednesday, November 12, 2003 1:05 PM Subject: Re: Another broken SMSC DLR implementation? Sounds like a provider issue.. We have a provider that does just this - delivers DLRs on one bind that relate to another bind. I get round this by giving the binds the same SMSC-ID. Dave. ----- Original Message ----- From: Alex Kinch To: [email protected] Sent: Wednesday, November 12, 2003 12:54 PM Subject: Another broken SMSC DLR implementation? Before I start ranting, this is a question - and not a statement, so please don't flame me if I'm wrong! :-) If you have multiple SMPP connections to a provider, shouldn't the DLRs come back on the connection that the message was sent out on? We're having an issue with one of our providers that DLRs are coming back on the wrong SMPP connection, so Kannel is ignoring them. The only way I've found of fixing it so far is disabling the other three connections, so the only way they can return the DLRs is through the originating connection. Any suggestions? Alex