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