Re: [PATCH] Re: MO Concatenation

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