Re: [PATCH] Fix MO concatenation
Alejandro Guerrieri <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
????? I you've read the smpp 3.4, sar_msg_ref_num, sar_total_segments and sar_segment_seqnum are defined as a vaild way to handle concatenation. In fact many major carriers around the globe use that method to handle concatenated MO's. See sections 5.3.22, .23 and .24. The only drawback is: according to the spec, they cannot coexist with UDH. Regards, -- Alejandro Guerrieri [email protected] On 11/11/2009, at 15:31, Nikos Balkanas wrote: > 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 >>> >>> >> >