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;
