to help this patch out, the following has been working really well for ages for
us.
long bb_smscconn_receive_message(SMSCConn *conn, Msg *sms)
{
.......
if( catenation_incoming ) // config to switch on feature
{
if(catenation_udh(sms,&part_no,&num_messages) != 0 ) // by catentation
commands in udh
{
if(part_no < num_messages)
{
gwlist_append(incoming_sms_parts,sms);
return 0;
}
if(part_no == num_messages) //got all the parts
{
sms = catenation_mesgs(sms,incoming_sms_parts);
}
}
else if(sms->sms.smsc_partid !=-1) //using the smpp protocol fields
{
if(sms->sms.segseqnum < sms->sms.totalsegs)
{
gwlist_append(incoming_sms_parts,sms);
return 0;
}
if(sms->sms.segseqnum == sms->sms.totalsegs)
{
sms= catenation_mesgs(sms,incoming_sms_parts);
}
}
so when the last part is seen, they all get combined to form one Msg.
the hard part may be recombining them.
Msg *catenation_mesgs(Msg *last_msg, List *mesg_list)
{
struct cat_env env;
long i;
Msg *msg;
Octstr *ostr;
env.msgparts = gwlist_create();
env.msg = last_msg;
gwlist_enumeratefn(mesg_list,&env,enumfnExtractParts);
gwlist_sort(env.msgparts,sort_message_parts);
gwlist_enumeratefn( env.msgparts,0,prntmsgs);
ostr = octstr_create("");
for (i = 0; i < gwlist_len(env.msgparts); ++i)
{
msg = (Msg*)gwlist_get(env.msgparts, i);
gwlist_delete_equal(mesg_list,msg);
ostr = octstr_cat(ostr,msg->sms.msgdata);
store_save_ack(msg, ack_success);
msg_destroy(msg);
}
gwlist_destroy(env.msgparts,NULL);
ostr = octstr_cat(ostr,last_msg->sms.msgdata);
octstr_destroy(last_msg->sms.msgdata);
last_msg->sms.msgdata = ostr;
// correct the udh to 1 part
multipart_udh2one(&last_msg->sms.udhdata);
return last_msg;
}
its mostly successful because the SMSC helps out in the cases I have..
ie (esp note the smsc_partid )
smsc_smpp.c
Msg *pdu_to_msg(SMPP *smpp, SMPP_PDU *pdu, long *reason)
{
................
msg->sms.smsc_partid = pdu->u.deliver_sm.TLVNAME(sar_msg_ref_num);
msg->sms.totalsegs = pdu->u.deliver_sm.TLVNAME(sar_total_segments);
msg->sms.segseqnum = pdu->u.deliver_sm.TLVNAME(sar_segment_seqnum);
----- Original Message -----
From: "Paul Bagyenda" <[EMAIL PROTECTED]>
To: "Kannel Devel" <[email protected]>
Sent: Tuesday, January 09, 2007 8:16 PM
Subject: Re: [PATCH] Re: MO Concatenation
So we have some sort of agreement, except that I can't seem to find
any reference to 'smsc-group-id' in the conf or the structure, so I
shall use smscid instead. A new patch will be forthcoming once I have
successfully fought a few local fires!
P.
On Jan 09, 2007, at 11:08, Andreas Fink wrote:
>
>
> On 09.01.2007, at 08:59, Δημήτρης Ευμορφόπουλος
> wrote:
>
>> So you mean msisdn + refnum + smsc-group-id not smscid ... That is
>> valid!
>
> well group-id seems to be new and I have not looked at this part
> for a while.
> but sounds logical.
>
>> BTW, what do you think that the time-to-live for each part should
>> be? We show that anything over 3 minutes is already too much.
>>
> 3 minutes doesnt sound that wrong to me. You must consider an
> incoming SMS from a SIM card where the second part cant be hit
> because the phone was processing the first part (yes there are
> still bogous SMSC's out there) so the second part would deliver as
> retry a few minutes later. This can be even 10 minutes. Maybe make
> it default to 3 minutes and make it uer configurable.
>
>> Dimitris Evmorfopoulos
>>
>> -----Original Message-----
>> From: Andreas Fink [mailto:[EMAIL PROTECTED]
>> Sent: Monday, January 08, 2007 7:45 PM
>> To: Δημήτρης Ευμορφόπουλος
>> Cc: [email protected]; Alexander Malysh
>> Subject: Re: [PATCH] Re: MO Concatenation
>>
>>
>> On 08.01.2007, at 17:38, Δημήτρης Ευμορφόπουλος
>> wrote:
>>
>>> The triple key is not valid. From personal experience I was getting
>>> the SMS parts from all SMSC's not the one that transmitted the
>>> first part only. All the operators I worked with do the same thing.
>>> So the key should remain msisdn + refnum only.
>>
>> msisdn + refnum + smscid.
>>
>> multiple SMSC's behaving the same are / must be grouped in the same
>> smsc-id for DLR consolidation too.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
