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



Reply via email to