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

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