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