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

Here's the userguide part.

Regards,
--
Alejandro Guerrieri
[email protected]


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

Index: doc/userguide/userguide.xml
===================================================================
--- doc/userguide/userguide.xml	(revision 32)
+++ doc/userguide/userguide.xml	(working copy)
@@ -1910,7 +1910,7 @@
    <entry valign="bottom">
         Re-start a single SMSC link. Password required. Additionally
 		  the <literal>smsc</literal> parameter must be given to identify
- 		  which <literal>smsc-id</literal> should be re-started.
+ 		  which <literal>smsc-admin-id</literal> should be re-started.
    </entry></row>
 
   	<row><entry><literal>stop-smsc</literal></entry>
@@ -2436,6 +2436,19 @@
 
      </entry></row>
 
+   <row><entry><literal>smsc-admin-id</literal></entry>
+     <entry><literal>string</literal></entry>
+     <entry valign="bottom">
+        An optional id for the smsc to be used on administrative
+        commands. This allows commands targeted to individual binds
+        even if they share the same <literal>smsc-id</literal>
+        (for load balancing scenarios, for example). Any string is
+        acceptable, but semicolon ';' may cause problems, so avoid
+        it and any other special non-alphabet characters.
+        Several SMSCs can have the same admin-id, though it's not
+        recommended. The name is case-insensitive.
+     </entry></row>
+
     <row><entry><literal>throughput</literal></entry>
       <entry><literal>float (messages/sec)</literal></entry>
       <entry valign="bottom">