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
>>
>>
>
>