Re: [PATCH] Sending catenated messages in incorrect order

Alexander Malysh <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
Hi,

sorry but it seems we make workarounds for buggy SMSC. I'm -1 for this 
patch. They must fix SMSC instead of adding some workarounds where those 
  don't belong to. Priority has _nothing_ todo with receiver and udh. 
Instead SMSC devels should read spec properly (EMI 4.0, GSM 03.38, GSM 
03.40). There is not sign of catenated msgs ordering.

And second thing: why in hell they try to reasseble the msg? it's a 
handset job...

Thanks,
Alex

Enver ALTIN wrote:
> Hey,
> 
> I've been stuggling to find out why some catenated messages submitted by 
> Kannel were getting rejected by our EMI SMSC. Apparently the problem was 
> the supersmart SMSC expecting catenated messages to arrive in proper 
> order. It was getting rejected if we send the second part of the 3-piece 
> splitted SMS before the first part, for example.
> 
> I said easy :) After some hours(!) of overnight code reading to learn 
> where exactly the big message gets splitted and where are the splitted 
> parts stored; I noticed that smsc/smsc_emi.c is making full use of the 
> new priority queue implementation and messages get ordered according to:
> 
>     1. Msg->sms.priority (Apparently only EMI and AT uses this)
>     2. Msg->sms.time
> 
> Attached patch changes the sms.c:sms_priority_compare() to compare 
> messages against Msg->sms.udhdata too, only when Msg->sms.receiver of 
> the messages being compared are the same.
> 
> -HTH
> 
> 
> ------------------------------------------------------------------------
> 
> Index: gw/sms.c
> ===================================================================
> RCS file: /home/cvs/gateway/gw/sms.c,v
> retrieving revision 1.21
> diff -u -p -d -r1.21 sms.c
> --- gw/sms.c	19 Sep 2005 22:07:33 -0000	1.21
> +++ gw/sms.c	10 Nov 2005 02:51:57 -0000
> @@ -401,8 +401,11 @@ int sms_priority_compare(const void *a, 
>              ret = 1;
>          else if (msg1->sms.time < msg2->sms.time)
>              ret = -1;
> -        else
> -            ret = 0;
> +        else if (octstr_compare(msg1->sms.receiver, msg2->sms.receiver) == 0)
> +            ret = octstr_compare(msg1->sms.udhdata, msg2->sms.udhdata) * -1;
> +        else {
> +            ret = 0;
> +        }
>      }
>      
>      return ret;
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.