Re: [PATCH] smsc-dlr-alias on SMSC connections
Alejandro Guerrieri <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
Yes, the only problem with that approach is that you'd lose control on the individual smsc's (since they have the same smsc-id, you cannot stop one without stopping the others). As suggested by Alex, I've made a different patch (sent it to the list yesterday) that adds an "smsc-admin-id" parameter instead, so you can control individual smsc's even when they share a same smsc-id. Regards, -- Alejandro Guerrieri [email protected] On 06/05/2009, at 0:43, Andreas Fink wrote: > this is simply solvable by having two smsc's with the same ID. > If those two SMSC's are seen as a unified virtual SMSC thats what > you do. > > > On 04.05.2009, at 21:34, Alejandro Guerrieri wrote: > >> We were facing a problem when dealing with multiple binds to the >> same carriers. >> >> >> Some of the carriers we're working with have SMSC's on >> twogeographically-distant places. They asked us to connect to both >> of them from our also replicated kannel clients. >> >> So, we have two identical connections on each of our servers to >> both of their smsc's. This guarantees that I could use >> "&smsc=mylink" on my send-sms url and kannel will choose one of the >> available links to send the messages. >> >> The problem is, in this particular scenario, the DLR for that MT >> could come back from the _other_ link (which has a different "id"), >> so even on the same server it wouldn't be possible to match the >> incoming DLR with the records stored on the DB. >> >> To solve this, I've created a patch that adds a new parameter to >> SMSC connections: smsc-dlr-alias. This parameter, if not defined, >> gets loaded with the value on smsc-id. If defined, that value is >> used when inserting to/reading from the dlr database, making it >> possible to find the dlr's despite being created on another bind. >> >> Please see this post for more info and the patch: >> >> http://www.blogalex.com/archives/121 >> >> Regards, >> -- >> Alejandro Guerrieri >> [email protected] >> >> >> >> > >