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