Re: {PATCH] final smsc-id passing in ack msg type

we have already callback infrastructure, it's called DLR :)
I don't see sense in this feature because all this could be done with  
already implemented
and well known method DLR.

Thanks,
Alex

Am 20.03.2009 um 21:21 schrieb Stipe Tolj:

> Alexander Malysh schrieb:
>> Hi Stipe,
>>
>> did you really tested this patch? I don't think so...
>>
>> in smsc2_route(...):
>> /* function to route outgoing SMS'es
>> *
>> * If finds a good one, puts into it and returns SMSCCONN_SUCCESS
>> * If finds only bad ones, but acceptable, queues and
>> * returns SMSCCONN_QUEUED  (like all acceptable currently  
>> disconnected)
>> * if message acceptable but queues full returns  
>> SMSCCONN_FAILED_QFULL and
>> * message is not destroyed.
>> * If cannot find nothing at all, returns SMSCCONN_FAILED_DISCARDED  
>> and
>> * message is NOT destroyed (otherwise it is)
>> */
>>
>> and then at the end of the function:
>>    msg_destroy(msg);
>>    return SMSCCONN_SUCCESS;
>> }
>>
>> so you have 100% bum in bb_boxc.
>>
>> Beside implementation error I don't think this will work as you  
>> would like.
>> As far as message accepted by bearerbox you want return smsc-id in  
>> ack.
>> That's ok.
>> But what do you want todo if the same message is then temporarily
>> undelivered by this smsc and
>> you make retry? What is todo there, you already returned "wrong"  
>> smsc-id
>> to smsbox.
>> So this feature just doesn't make any sense for me.
>
> yep, Alex is right. We destroy the msg already in the smsc2_rout()  
> before coming
> back.
>
> The retry can't be an argument here. Of course, "if" the msg is re- 
> queued and
> takes an alternative route, there is no way to inform the smsbox  
> connection of
> this event. But this is not a show stopper for the basic concept of  
> the
> approach: informing the tier 2 layer (smsbox) of the routing outcome.
>
> This is legitime since we don't have a full-synchronized callback  
> anyway. "If"
> we would wait for a real confirmation from the SMSC, then we "could"  
> provide the
> de-facto final smsc-id as end-point information.
>
> I.e. sqlbox will also be able to "log" the smsc-id routing endpoint  
> in a CDR
> based logging facility.
>
> 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
> -------------------------------------------------------------------
>