Nikos, hmm seems you not reading anything just posting back? I come to this conclusion because I posted description of the issue together with a patch and if you would read code and specs how to assemble concatenated SMS then you would know what I'm speaking about...
Sorry for hard words but we waste time and bandwidth for such emails... Thanks, Alexander Malysh Am 11.11.2009 um 16:19 schrieb Nikos Balkanas: > Hi, > > No i haven't read the code. And i don't think I should. A couple of lines > about what the patch is intended to do/or correct would be much more > preferable, inasmuch the code by itself can lead to the wrong conclusion > (unless you put it in the debugger with the exact concat conditions). > > @Alejandro: I was not referring to the sar implementation in the SMPP spec. > But the approach in the submitted patch, which is general for all smscs, uses > some heuristic like if they have the same udh, which i have not the > experience or knowledge if it holds. > > BR, > Nikos > ----- Original Message ----- From: "Alexander Malysh" <[email protected]> > To: "Nikos Balkanas" <[email protected]> > Cc: "Alejandro Guerrieri" <[email protected]>; "Kannel Devel" > <[email protected]> > Sent: Wednesday, November 11, 2009 4:36 PM > Subject: Re: [PATCH] Fix MO concatenation > > > Nikos, > > did you read the code? I don't think so... Please do it before saying > anything... > > Thanks, > Alexander Malysh > > Am 11.11.2009 um 15:31 schrieb Nikos Balkanas: > >> I see. But according to SMS spec any concat should be specified in the UDH >> header (?). Why do we try to support it outside the spec and with a rather >> "iffy" approach? >> >> BR, >> Nikos >> ----- Original Message ----- From: "Alejandro Guerrieri" >> <[email protected]> >> To: "Nikos Balkanas" <[email protected]> >> Cc: "Kannel Devel" <[email protected]> >> Sent: Wednesday, November 11, 2009 4:25 PM >> Subject: Re: [PATCH] Fix MO concatenation >> >> >>> Concatenation works, but only if it's done with the UDH parameters. >>> >>> On SMPP the sar_ optional values could be used as well, but kannel ignores >>> that afaik. >>> >>> Regards, >>> -- >>> Alejandro Guerrieri >>> [email protected] >>> >>> >>> >>> On 11/11/2009, at 15:24, Nikos Balkanas wrote: >>> >>>> Hi, >>>> >>>> Any background info? Did MO concatenation work so far? If yes what is >>>> wrong now? Any relevant ticket? Does this fix concat for the case that >>>> udh doesn't specify it? >>>> >>>> BR, >>>> Nikos >>>> ----- Original Message ----- From: "Alexander Malysh" <[email protected] >>>> > >>>> To: "Kannel Devel" <[email protected]> >>>> Sent: Wednesday, November 11, 2009 4:16 PM >>>> Subject: [PATCH] Fix MO concatenation >>>> >>>> >>>> Hi, >>>> >>>> attached if patch that fixes issue in MO concatenation handling. Just >>>> example: >>>> >>>> - First MO with 2 parts (from:123, to:456, reference id in concat=0, udh=A) >>>> - Second MO also with 2 parts (from:123, to:456, reference id in concat=0, >>>> udh=B) >>>> >>>> Now when we receive part 1 from first MO and then part 2 from second MO >>>> we will put them together. >>>> >>>> We are not really able to differentiate First MO parts and second MO parts >>>> but we at least able to minimize >>>> possibility to wrong assemble parts when we check whether UDH (without >>>> concatenation info) is the same. >>>> >>>> Please check attached patch. >>>> Looking for feedback... >>>> >>>> Thanks, >>>> Alexander Malysh >>>> >>>> >>> >> >> >
