Sorry, I didn't follow up on this until now. I'm not sure what exactly you mean when you say 'you can just generate concatenation udh from sar params and send message further to process'. We receive the sms 'from' (MO) from telco and kannel is unable to recognize the SAR parameters. So the message does not get concatenated and sent to our service as 'one'.
Using the SAR patch that I submitted, the kannel is able to recognize that it is receiving a multi-part SMS and waits for all the parts to arrive before forwarding to our application. On Tue, Apr 13, 2010 at 12:18 PM, Alexander Malysh <[email protected]>wrote: > Hi, > > Am 13.04.2010 um 09:10 schrieb hisham malik: > > > On Tue, Apr 13, 2010 at 2:17 AM, Alexander Malysh <[email protected]> > wrote: > >> > >> Hi, > >> > >> Am 02.04.2010 um 16:10 schrieb hisham malik: > >> > >>> I'm attaching the following patches for the kannel source. > >>> > >>> > >>> 1. Concatenate using SAR parameters: > >>> Added support for concatenation through SAR parameters in Kannel > >> > >> why don't you just make concatenation UDH from SAR parameters and then > all things will work automagicallyb? > > > > We're bound by the format that telco uses and they use SAR parameters > > instead of using concatenation UDH while transmitting multi-part SMS > > to the service. > > yes, it's ok if telco uses it but you can just generate concatenation udh > from sar params and send message further to process and it > will work automagically instead of implementing extra reassemble logic... > > > > > > >> > >>> > >>> 2. Re-Establish Transmitter Connection: > >>> Re-establish transmitter connection when connection is lost with smsc. > >> > >> do you use old smpp version? I'm unable to find this part... > >> > > > > The old check for detecting disconnection was: > > if (smpp->conn->status != SMSCCONN_ACTIVE && smpp->conn->status != > > SMSCCONN_ACTIVE_RECV) { > > > > So when SMPP is running in transmit/receive mode, and chokes on > > transmit, the connection status becomes SMSCCONN_ACTIVE_RECV, and the > > transmit problem stays undetected. The fix is to check that either the > > connection is fully active (SMSCCONN_ACTIVE) or if it is only active > > for receive(SMSCCONN_ACTIVE_RECV), then we need to ensure that the > > connection was never set to be running in transmit mode as well. So > > the patched replacement if statement is: > > if (smpp->conn->status != SMSCCONN_ACTIVE && > > !(smpp->conn->status == > SMSCCONN_ACTIVE_RECV && > > !transmitter)) { > > this code doesn't exists anymore. seems you used old version. please check > out svn archive and try > it... > > > > > Thanks. > > > >> Thanks, > >> Alexander Malysh > >> > >
