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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.