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.
now, I'm +0 on this patch.
Reasons:
I don't see any "relevance" for the ordering within the EMI/UCP spec. Actually
this may be a "flavored behaviour" of your local EMI SMSC? Which vendor is it?
2 times octstr_compare() does hit the performance break with high-load systems,
right?
Others, please comment?
Stipe
mailto:stolj_{at}_wapme-group.de
-------------------------------------------------------------------
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
-------------------------------------------------------------------
