Re: [PATCH] smsc-dlr-alias on SMSC connections

Already working on it ;)
--
Alejandro Guerrieri
[email protected]



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