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

both patches commited to cvs.

Thanks,
Alex

Am 06.05.2009 um 16:49 schrieb Alejandro Guerrieri:

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