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

No worries, just making sure that you've got it :)
--
Alejandro Guerrieri
[email protected]



On 06/05/2009, at 16:41, Alexander Malysh wrote:

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