[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