Watch out here
If you have TWO EMI/UCP connection to the same SMSC's (like to
overcome speed limitations while windowing = 0) which have the same
id, then they actually can have one SMS come in on one link and the
other on the other. For the SMSC its just two different SMS's. Same
is true for delivery reports! This is considered "one" smsc as long
as the smsc-id is the same even though two SMSC driver instances
exist. So it might not be a good idea to do it on the driver instance
level.
On 08.01.2007, at 16:10, Alexander Malysh wrote:
Am 08.01.2007, 15:50 Uhr, schrieb Paul Bagyenda
<[EMAIL PROTECTED]>:
On Jan 08, 2007, at 17:04, Stipe Tolj wrote:
Alexander Malysh wrote:
Hi Paul,
+1 for the at2 part.
-1 for the reassemble part. Your patch will never work reliable
because not only msisdn + refnum should be considered.
Reassemble should have triple as key: SMSC, msisdn, refnum.
IMO bb_boxc.c is the wrong place for this, bb_smscconn suites
better because bb_boxc just generic connection module for
external boxes and should have nothing todo with SMS magic.
agree'ing here with Alex... bb_boxc should not to "semantical SMS
processing", it's the box connection layer. The bb_smscconn is
the SMSC protocol abstraction layer, and MO re-assemling fits
into that scope.
So presumably this would be in bb_smscconn_receive, and the
incoming concat queue would be held in the SMSCConn structure so
that it is per SMSC, and the call to all the added code would be
just before the call to route_incoming_to_boxc?
yes, but concat queue can't be in SMSCConn struct because we can
have more as one "equal" SMSCConns.
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
-------------------------------------------------------------------
--
Thanks,
Alex
