?????

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






Reply via email to