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]
