Am 05.05.2009 um 13:26 schrieb Alejandro Guerrieri:
Ok, here it is.
As usual, you were right: this approach is neater :)
thanks ;)
I've also modified the status page to display the admin-id enclosed
in brackets next to the connection id.
please provide userguide part and then I'm ++1 for this patch.
Thanks,
Alex
Regards
--
Alejandro Guerrieri
aguerri...@kannel.org
<kannel-conn-admin-id.patch>
On 05/05/2009, at 12:43, Alexander Malysh wrote:
Am 05.05.2009 um 11:20 schrieb Alejandro Guerrieri:
Ok, got it.
So what you propose is to turn the parameter into a special "id"
to be given to each bind, so they can be individually targeted on
admin commands even when they have the same smsc-id.
yes... And it can be easily done in generic code for SMSCconn :)
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 05/05/2009, at 9:35, Alexander Malysh wrote:
Hi Alex,
not really -1 but I think smsc-dlr-alias is the wrong option. It
should be called smsc-admin-id or the like
because it really only admin issue...
what do you think about it?
Thanks,
Alex
Am 04.05.2009 um 23:53 schrieb Alejandro Guerrieri:
Shall I interpret that as a -1? ;)
--
Alejandro Guerrieri
aguerri...@kannel.org
On 04/05/2009, at 23:40, Alexander Malysh wrote:
Am 04.05.2009 um 23:23 schrieb Alejandro Guerrieri:
Well, we tried that approach in the first place. While it
might be appropriate on many cases, we'd lose control over the
individual links that way.
For our particular case, that's a showstopper, and it might be
for others as well:
* You wouldn't be able to manually shutdown one of the binds
with shutdown-smsc, since all of them would share the same
smsc-id. I've confirmed this with 2 fakesmsc instances: stop-
smsc kills both instances. I can imagine this would be
specially painful with AT modems.
this is the only issue that count...
* Your carrier may require you to route all your outbound
traffic to a particular bind according to rules that exceed
kannel's routing capabilities (time slots and other "non-
standard" requirements some carriers _love_ to do ;)).
This can be handled with my config example
* mt-routing rules over particular binds wouldn't be possible
either.
ditto...
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 04/05/2009, at 22:47, Alexander Malysh wrote:
Hi Alex,
why do you need this?
here is needed config for you:
# first connection
group = smsc
smsc-id = mylink
allowed-smsc = mylink;mylink1
# second connection
group = smsc
smsc-id = mylink
allowed-smsc = mylink;mylink2
So you can send with &smsc=mylink and bearerbox loadbalance
between two links,
with &smsc=mylink[1|2] you can choose between two links.
In both cases DLRs added to DB with mylink as SMSC.
Why do you need dlr alias?
Thanks,
Alex
Am 04.05.2009 um 21:34 schrieb Alejandro Guerrieri:
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
aguerri...@kannel.org
