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
> [email protected]
>
>
>
> On 05/05/2009, at 14:49, Alejandro Guerrieri wrote:
>
>> Here's the userguide part.
>>
>> Regards,
>> --
>> Alejandro Guerrieri
>> [email protected]
>>
>> <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
>>>> [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]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>