Re: [PATCH] Fix MO concatenation
"Nikos Balkanas" <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <005101ca62db$b4f893f0$02b2a8c0@tardis> |
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 >> >> > >