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
> [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]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>