Re: [PATCH] smsc-dlr-alias on SMSC connections
Alex, have you received this? Regards, -- Alejandro Guerrieri aguerri...@kannel.org On 05/05/2009, at 14:49, Alejandro Guerrieri wrote: Here's the userguide part. Regards, -- Alejandro Guerrieri aguerri...@kannel.org 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 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
Re: [PATCH] smsc-dlr-alias on SMSC connections
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 aguerri...@kannel.org On 05/05/2009, at 14:49, Alejandro Guerrieri wrote: Here's the userguide part. Regards, -- Alejandro Guerrieri aguerri...@kannel.org 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 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
Re: [PATCH] smsc-dlr-alias on SMSC connections
No worries, just making sure that you've got it :) -- Alejandro Guerrieri aguerri...@kannel.org 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 aguerri...@kannel.org On 05/05/2009, at 14:49, Alejandro Guerrieri wrote: Here's the userguide part. Regards, -- Alejandro Guerrieri aguerri...@kannel.org 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 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
Re: [PATCH] smsc-dlr-alias on SMSC connections
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 aguerri...@kannel.org 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 aguerri...@kannel.org On 05/05/2009, at 14:49, Alejandro Guerrieri wrote: Here's the userguide part. Regards, -- Alejandro Guerrieri aguerri...@kannel.org 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 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
Re: [PATCH] smsc-dlr-alias on SMSC connections
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
Re: [PATCH] smsc-dlr-alias on SMSC connections
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. 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
Re: [PATCH] smsc-dlr-alias on SMSC connections
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
Re: [PATCH] smsc-dlr-alias on SMSC connections
Already working on it ;) -- Alejandro Guerrieri aguerri...@kannel.org 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
Re: [PATCH] smsc-dlr-alias on SMSC connections
Ok, here it is. As usual, you were right: this approach is neater :) I've also modified the status page to display the admin-id enclosed in brackets next to the connection id. Regards -- Alejandro Guerrieri aguerri...@kannel.org kannel-conn-admin-id.patch Description: Binary data 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
Re: [PATCH] smsc-dlr-alias on SMSC connections
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
Re: [PATCH] smsc-dlr-alias on SMSC connections
Here's the userguide part. Regards, -- Alejandro Guerrieri aguerri...@kannel.org kannel-conn-admin-id-doc.patch Description: Binary data 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 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
Re: [PATCH] smsc-dlr-alias on SMSC connections
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 aguerri...@kannel.org
Re: [PATCH] smsc-dlr-alias on SMSC connections
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 aguerri...@kannel.org 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 aguerri...@kannel.org
[PATCH] smsc-dlr-alias on SMSC connections
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
Re: [PATCH] smsc-dlr-alias on SMSC connections
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
Re: [PATCH] smsc-dlr-alias on SMSC connections
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. * 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 ;)). * mt-routing rules over particular binds wouldn't be possible either. 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
Re: [PATCH] smsc-dlr-alias on SMSC connections
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
