[PATCH] Fix MO concatenation

Paul Bagyenda bagyenda at dsmagic.com
Thu Nov 12 17:07:06 CET 2009


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 at kannel.org 
>> >
>> To: "Nikos Balkanas" <nbalkanas at gmail.com>
>> Cc: "Alejandro Guerrieri" <aguerrieri at kannel.org>; "Kannel Devel" <devel at kannel.org 
>> >
>> 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 at kannel.org 
>>> >
>>> To: "Nikos Balkanas" <nbal at amdtelecom.net>
>>> Cc: "Kannel Devel" <devel at kannel.org>
>>> 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 at kannel.org
>>>>
>>>>
>>>>
>>>> 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 at kannel.org
>>>>>>
>>>>> To: "Kannel Devel" <devel at kannel.org>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>




More information about the devel mailing list