yep, I got it, but busy with other things...
Am 06.05.2009 um 16:18 schrieb Alejandro Guerrieri:
Alex, have you received this?
Regards,
--
Alejandro Guerrieri
[email protected]
On 05/05/2009, at 14:49, Alejandro Guerrieri wrote:
Here's the userguide part.
Regards,
--
Alejandro Guerrieri
[email protected]
<kannel-conn-admin-id-doc.patch>
On 05/05/2009, at 14:02, Alexander Malysh wrote:
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
[email protected]
<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
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
