both patches commited to cvs.
Thanks,
Alex
Am 06.05.2009 um 16:49 schrieb Alejandro Guerrieri:
No worries, just making sure that you've got it :)
--
Alejandro Guerrieri
[email protected]
On 06/05/2009, at 16:41, Alexander Malysh wrote:
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]
