Re: [PATCH] SMS Box routing

@Stipe?

Am 29.07.2010 um 13:40 schrieb Nikos Balkanas:

> Seems that a lot of people do (overlooked the loopback smsc). Propably, because it was never documented and followed the path to oblivion, like many other undocumented tools. Normal procedure is to submit a userguide patch for any submissions. What happened? Can we still ask for a userguide update?
> 
> BR,
> Nikos
> ----- Original Message ----- From: "Alexander Malysh" <[email protected]>
> To: "Rene Kluwen" <[email protected]>
> Cc: <[email protected]>
> Sent: Thursday, July 29, 2010 10:23 AM
> Subject: Re: [PATCH] SMS Box routing
> 
> 
> Hi,
> 
> oops, seems I overlooked this fact :) but issues remain...
> 
> Thanks,
> Alexkander Malysh
> 
> Am 29.07.2010 um 01:52 schrieb Rene Kluwen:
> 
>> The smsc=loopback has already been part of Kannel since 2009/09/17. I didn't
>> know.
>> It obsoletes my patch.
>> If any more work has to be done on it, I will have a look at it.
>> 
>> == Rene
>> 
>> -----Original Message-----
>> From: Alexander Malysh [mailto:[email protected]] On Behalf Of
>> Alexander Malysh
>> Sent: Wednesday, 28 July, 2010 23:08
>> To: Rene Kluwen
>> Cc: 'Stipe Tolj'; [email protected]
>> Subject: Re: [PATCH] SMS Box routing
>> 
>> Hi,
>> 
>> it's a clean approach that costs performance. But it should be tested first,
>> how much performance it costs.
>> 
>> Now to this patch:
>> 
>> +    /* store temporary DLR data for SMSC ACK */
>> +    if (DLR_IS_ENABLED_DEVICE(msg->sms.dlr_mask) &&
>> !uuid_is_null(sms->sms.id)) {
>> +        Octstr *mid;
>> +        char id[UUID_STR_LEN + 1];
>> +
>> +        uuid_unparse(sms->sms.id, id);
>> +        mid = octstr_create(id);
>> +
>> +        dlr_add(conn->id, mid, sms);
>> 
>> dlr_add without dlr_find is not good. It will just grow DB...
>> 
>> +    if (conn->reroute_to_smsc) {
>> +        sms->sms.smsc_id = octstr_duplicate(conn->reroute_to_smsc);
>> +    } else {
>> +        sms->sms.smsc_id = octstr_duplicate(conn->id);
>> +    }
>> 
>> reroute belongs to abstraction layer...
>> 
>> Thanks,
>> Alexander Malysh
>> 
>> 
>> Am 28.07.2010 um 20:59 schrieb Rene Kluwen:
>> 
>>> No, you are right. I saw your solution only after I made the
>>> smsbox-route-between patch.
>>> I think your solution is cleaner. It depends of the routing options that
>> are
>>> already available.
>>> I attached your (Stipe's) patch another time, as I see that it is still
>> not
>>> committed to svn trunk.
>>> 
>>> So the 2 questions here:
>>> 
>>> 1. What do the other developers thing about this patch,
>>> 
>>> and:
>>> 
>>> 2. Can this patch (either one) submitted to Kannel svn, so people can
>>> benefit from smsbox (open smppbox) to smsbox routing?
>>> 
>>> Previously, there hasn't been a lot of requests for it, other than be able
>>> to use sms-service from an smsbox request.
>>> Currently, I have been getting a lot of requests for this functionality
>>> because open smppbox depends on it.
>>> 
>>> == Rene
>>> 
>>> 
>>> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]] On Behalf
>>> Of Stipe Tolj
>>> Sent: Wednesday, 28 July, 2010 17:44
>>> Cc: [email protected]
>>> Subject: Re: [PATCH] SMS Box routing
>>> 
>>>> As per popular request, I made a patch for bearerbox that enable the
>>>> following configuration:
>>>> 
>>>> # multi-group:
>>>> group = smsbox-route-between
>>>> smsbox-id1 = localbox1
>>>> smsbox-id2 = remotebox1
>>>> # shortcode is optional
>>>> shortcode = +1234567;+7654321
>>>> 
>>>> 
>>>> This is the opposite of "reroute" for smsc's. It routes messages from
>>>> smsbox/sqlbox/open smppbox to another box that is connected.
>>>> 
>>>> This allows for:
>>>> 
>>>> 1. client-to-client routing, concerning open smppbox.
>>>> 2. Call sms services from one of the boxes. Right now you can only call
>>> them
>>>> via an smsc.
>>>> 3. Many more interesting things
>>> 
>>> thanks a lot Rene for the patch.
>>> 
>>> I'm at the moment -0 for this, due to the fact that it logically
>> duplicates
>>> the
>>> behavior that we already have via the 'smsc = loopback' type.
>>> 
>>> In your approach you do the re-routing here in the bearebox abstractive
>>> layer,
>>> where the loopback smsc module does it in the smsc module layer. The
>>> benefits
>>> here are we get the MT and MO entry logged to access-log while running,
>> and
>>> there are no further config groups needed, as you can define the same
>>> routing
>>> you intend between smsbox instances bound to the same bearerbox by using
>> the
>>> loopback smsc, and the smsbox-route group already.
>>> 
>>> Do I miss some advantages here from this approach?
>>> 
>>> Stipe
>>> 
>>> -- 
>>> -------------------------------------------------------------------
>>> Kφlner Landstrasse 419
>>> 40589 Dόsseldorf, NRW, Germany
>>> 
>>> tolj.org system architecture      Kannel Software Foundation (KSF)
>>> http://www.tolj.org/              http://www.kannel.org/
>>> 
>>> mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
>>> -------------------------------------------------------------------
>>> 
>>> 
>>> <smsc_loopback.diff>
>> 
>> 
>> 
> 
>