|

»

»

[PATCH] Fix MO concatenation

View: New views

11 Messages — Rating Filter: Alert me

	[PATCH] Fix MO concatenation by Alexander Malysh :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 bb_smscconn_concat.diff (6K) Download Attachment
	Re: [PATCH] Fix MO concatenation by Nikos Balkanas-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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" <amalysh@...> To: "Kannel Devel" <devel@...> 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
	Re: [PATCH] Fix MO concatenation by Alejandro Guerrieri-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 aguerrieri@... 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" <amalysh@... > > > To: "Kannel Devel" <devel@...> > 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 > >
	Re: [PATCH] Fix MO concatenation by Nikos Balkanas :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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" <aguerrieri@...> To: "Nikos Balkanas" <nbal@...> Cc: "Kannel Devel" <devel@...> 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 > aguerrieri@... > > > > 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" <amalysh@... >> > >> To: "Kannel Devel" <devel@...> >> 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 >> >> > >
	Re: [PATCH] Fix MO concatenation by Alexander Malysh :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message background info is bellow please read given example and read code. there is nothing I can add to this info... Thanks, Alexander Malysh Am 11.11.2009 um 15:24 schrieb Nikos Balkanas: > 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" <amalysh@...> > To: "Kannel Devel" <devel@...> > 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 >
	Re: [PATCH] Fix MO concatenation by Alexander Malysh :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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" <aguerrieri@...> > To: "Nikos Balkanas" <nbal@...> > Cc: "Kannel Devel" <devel@...> > 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 >> aguerrieri@... >> >> >> >> 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" <amalysh@... >>> > >>> To: "Kannel Devel" <devel@...> >>> 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 >>> >>> >> > >
	Re: [PATCH] Fix MO concatenation by Alejandro Guerrieri-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message ????? 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 aguerrieri@... 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" <aguerrieri@... > > > To: "Nikos Balkanas" <nbal@...> > Cc: "Kannel Devel" <devel@...> > 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 >> aguerrieri@... >> >> >> >> 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" <amalysh@... >>> > >>> To: "Kannel Devel" <devel@...> >>> 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 >>> >>> >> >
	Re: [PATCH] Fix MO concatenation by Nikos Balkanas :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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" <amalysh@...> To: "Nikos Balkanas" <nbalkanas@...> Cc: "Alejandro Guerrieri" <aguerrieri@...>; "Kannel Devel" <devel@...> 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" > <aguerrieri@...> > To: "Nikos Balkanas" <nbal@...> > Cc: "Kannel Devel" <devel@...> > 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 >> aguerrieri@... >> >> >> >> 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" >>> <amalysh@... >>> > >>> To: "Kannel Devel" <devel@...> >>> 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 >>> >>> >> > >
	Re: [PATCH] Fix MO concatenation by Alexander Malysh :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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" <amalysh@...> > To: "Nikos Balkanas" <nbalkanas@...> > Cc: "Alejandro Guerrieri" <aguerrieri@...>; "Kannel Devel" <devel@...> > 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" <aguerrieri@...> >> To: "Nikos Balkanas" <nbal@...> >> Cc: "Kannel Devel" <devel@...> >> 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 >>> aguerrieri@... >>> >>> >>> >>> 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" <amalysh@... >>>> > >>>> To: "Kannel Devel" <devel@...> >>>> 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 >>>> >>>> >>> >> >> >
	Re: [PATCH] Fix MO concatenation by P. A. Bagyenda :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Definitely an improvement IMO. And It does not break what we had before. On Nov 11, 2009, at 18:36, Alexander Malysh wrote: > 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" <amalysh@... >> > >> To: "Nikos Balkanas" <nbalkanas@...> >> Cc: "Alejandro Guerrieri" <aguerrieri@...>; "Kannel Devel" <devel@... >> > >> 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" <aguerrieri@... >>> > >>> To: "Nikos Balkanas" <nbal@...> >>> Cc: "Kannel Devel" <devel@...> >>> 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 >>>> aguerrieri@... >>>> >>>> >>>> >>>> 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" <amalysh@... >>>>>> >>>>> To: "Kannel Devel" <devel@...> >>>>> 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 >>>>> >>>>> >>>> >>> >>> >> > >
	Re: [PATCH] Fix MO concatenation by Alexander Malysh :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hi, patch commited to cvs... Thanks, Alexander Malysh Am 11.11.2009 um 15:16 schrieb Alexander Malysh: > 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 > <bb_smscconn_concat.diff>