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

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