Re: [PATCH] Sending catenated messages in incorrect order
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/
---
Re: SQLBox Postgres update
Wilfried Goesgens wrote:
On Wed, Nov 09, 2005 at 03:20:12PM +0100, Stipe Tolj wrote:
Rene Kluwen wrote:
Do you want to implement kind of a patch-o-matic, like netfilter has?
Just an idea...
hmm, don't know about that one... would have to review. What's its benefit?
Stipe
maybe darcs is the thing youre looking for?
http://freshmeat.net/projects/darcs/
other question, are there plans of a SVN migration?
this would ease many of the actual problems.
yep, looking on how we get roadmap'ed there. Alex and I am quite busy with other
things, so we need to coordinate.
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/
---
Re: [PATCH] Sending catenated messages in incorrect order
On Thursday 10 November 2005 10:20, Stipe Tolj wrote: 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 now, I'm +0 on this patch. Others, please comment? Just something that bugged me - according to the two above mentioned criteria, I don't see why SAR (segmentation and reassembly) messages get to different places on the queue. Surely several parts of a SAR message will have the same priority and same time, so they should be sent in the order they were introduced into the queue. If this is not the case, then I suggest that this problem would be fixed instead of doing high level content analysis on outgoing messages. -- Oded
Re: SQLBox Postgres update
Wilfried Goesgens wrote:
On Wed, Nov 09, 2005 at 03:20:12PM +0100, Stipe Tolj wrote:
Rene Kluwen wrote:
Do you want to implement kind of a patch-o-matic, like netfilter has?
Just an idea...
hmm, don't know about that one... would have to review. What's its benefit?
Stipe
maybe darcs is the thing youre looking for?
http://freshmeat.net/projects/darcs/
nop, we're not looking for a new revision control system. We're aiming towards
how Kannel's core can add/modulize add-on, like Rene's sqlbox, my smppbox and
mmsbox etc.
Hence we need a way in letting the add-ons register for config directives in the
central configuration management and how we share msg'ing structure et al.
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/
---
Re: [PATCH] Sending catenated messages in incorrect order
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.c19 Sep 2005 22:07:33 - 1.21
+++ gw/sms.c10 Nov 2005 02:51:57 -
@@ -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;
Re: [PATCH] Sending catenated messages in incorrect order
On Thursday 10 November 2005 12:22, Alexander Malysh wrote: 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... We had a similar problem with a client where the SMSC was assembling the message. We didn't have an ordering problem but there was a bug in one of the target handsets that caused it to crash when the SAR header was put before the NBS header, and the SMSC was rearranging the UDH IEs and causing the crash (which was initially blamed on us, of course :-). We never got them to stop doing that and the quoted reason is that they track SAR messages for billing purposes - they bill the user differently for SAR messages then for normal messages. -- Oded
Re: [PATCH] Sending catenated messages in incorrect order
Alexander Malysh wrote:
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.
yep, agree'ing here to Alex's position. Mainly this was because of my +0 voting.
Actually it may be more -0 ;)
@Enver: can you please check what vendor this specific EMI SMSC is? If it is a
non standard vendor, hence, home-brewed, then you should force them to obey the
specs.
We really don't want to add workarrounds for bugs of other people's software,
that's why specs are for.
Sounds drastic, but it has to be programatic, otherwise we're the one to blame,
since we do everything, but not the clean words of the spec.
I didn't find any specific things regarding ordering of concatenated (hence udh
included) messages in EMI. If you can state that this is an anomaly of Kannel,
we'll fix it.
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/
---
Re: [PATCH] Sending catenated messages in incorrect order
Stipe, et al, 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. As a member of a company that develops their own SMSC, I have to say that lots of people break specs, even the big guys and handset manufacturers. As such, to be fully compliant with the market and not just the specs, you sometimes have to allow for stupid hacks. Otherwise you can feel good inside for being 100% compliant, sure, but you won't be able to support the market (which doesn't really make sense). Now that being said, if in fact this is some small guy (AKA home brew) SMSC, I can agree completely with not adding the functionality. They should in fact fix their code unless they have a *really* good reason for it to work like this. They don't represent a lot in the way of installed systems in that case, so it shouldn't be that big of a deal for them to fix their code. Back to being an SMSC developer, I can say that there are possible good reasons for wanting the above functionality. The UDH spec allows for an ID that should differentiate each message from another so you know what pieces get put back together. However a lot of vendors are lazy and only ever set this to some default value, ie. 1. Even if they don't, there's never any real guarantee that the unique ID is actually unique for that connection. (I refer to the concat/SAR reference number in the above.) Now if you want some higher level functionality like displaying multi-part messages as a single message for end-user tools, retries where you resend all parts should a single part fail, etc., you kind of need to know which pieces go together. I'm sure there are other uses, but those are the ones we've explored that I can think of. We really don't want to add workarrounds for bugs of other people's software, that's why specs are for. Sounds drastic, but it has to be programatic, otherwise we're the one to blame, since we do everything, but not the clean words of the spec. If it's a spec breaker, make it something you have to turn on. Then you can support the broken SMSCs should you need to, but the end-user has to enable it. Heck, even call it hack-send-in-order or something so you know every time you see it that it's just a hack. Granted there's the issue of not breaking this functionality as time progresses, but looking at the patch he submitted, it didn't look like that big of a deal. Again I'm not advocating for the addition of this feature. Personally I don't need it and don't care. But if this is some big guy SMSC and if their SMSC indeed *needs* to work this way for some reason, it should definitely be considered. My 2 cents (or whatever you local currency may be that is of equivalence). :P Jon
RE: [PATCH] Documentation changes regarding coding/dcs (was: Message Mode)
Hi Dziugas, Sorry I got a mistake when I did the send;-) The problem is I have a machine running kannel 1.2.1 that I send normal GSM messages using coding=1. In a new machine I put kannel 1.3.2 and when I send the message with coding=1 it goes binary. In the manual coding = 0 is equals coding = 1 message coding: 0 (default, 7 bits), 1 (7 bits), 2 (8 bits) or 3 (Unicode) But here you can see the differences: 2005-11-10 11:11:31 Sent SMS [SMSC:BRT] [SVC:brt] [ACT:] [BINF:] [from:90007] [to:554284017946] [flags:-1:1:-1:-1:19] [msg:5:5465737465] [udh:0:] 2005-11-10 11:12:15 Sent SMS [SMSC:BRT] [SVC:brt] [ACT:] [BINF:] [from:90007] [to:554284017946] [flags:-1:0:-1:-1:19] [msg:5:Teste] [udh:0:] Is it working properly? I took off the charset but it did not change. Thank's Douglas -Original Message- From: Dziugas Baltrunas [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 9 de novembro de 2005 19:59 To: Douglas Jurcovichi Subject: Re: [PATCH] Documentation changes regarding coding/dcs (was: Message Mode) Hi, 1. always reply also to the mailing list, so other people are involved 2. what problem exactly are you trying to solve? 3. what version of kannel are you using exactly? 4. try removing the charset parameter and look if the log line will change, although it shouldn't. On 11/9/05, Douglas Jurcovichi [EMAIL PROTECTED] wrote: Hi, The URL is: http://10.61.14.127:13013/cgi-bin/sendsms?username=tstpassword=12345from=90007to=554284017946text=Test coding=0charset=ISO-8859-1dlrmask=19 Thank's Douglas -Original Message- From: Dziugas Baltrunas [mailto:[EMAIL PROTECTED] Sent: quarta-feira, 9 de novembro de 2005 12:42 To: Douglas Jurcovichi Cc: devel@kannel.org Subject: Re: [PATCH] Documentation changes regarding coding/dcs (was: Message Mode) Hi, if you put coding=0 and you're not using alt-dcs, then the second column, which indicates the coding, should be 0 (which indicates, that coding is 7 bit) instead of 1. Could you please provide the whole sendsms URL and Kannel version exactly? And you should not worry about -1, which means default and which in most cases is 0. On 11/9/05, Douglas Jurcovichi [EMAIL PROTECTED] wrote: Hi Dziugas, thank's for help. I tested all combinations of alt-dcs and coding and when I put coding=0 kannel sends the message in the pure text mode, but it still in the bearerboxaccess.log the flags -1:1:-1:-1, how can I change the flags to 0:1:0:0 ? Thank's Douglas -Original Message- From: Dziugas Baltrunas [mailto:[EMAIL PROTECTED] Sent: terça-feira, 8 de novembro de 2005 18:36 To: Douglas Jurcovichi Cc: devel@kannel.org Subject: [PATCH] Documentation changes regarding coding/dcs (was: Message Mode) Hi, do you use alt-dcs sendsms parameter, which might also affect how the message is interpreted (in your case [flags:-1:1:-1:-1:19] indicates, that coding is 1 = binary). Btw, @Stipe and others: we should finally fix the userguide and scripts in contrib/ related all the changes relating to alt-dcs and coding parameters in order not to confuse users. Attached patch should do this. On 11/8/05, Douglas Jurcovichi [EMAIL PROTECTED] wrote: Hi list, I am using the kannel today and the bearerboxaccess.log show the messages like this: 2005-11-07 23:59:05 Sent SMS [SMSC:BRT] [SVC:brt] [ACT:] [from:6000] [to:556184720783] [flags:0:1:0:0:0] [msg:124:Teste [udh:0:] It is sending the messages in noemas mode. So, I installed the newer kannel version and it started to show the messages like this: 2005-11-08 15:10:18 Sent SMS [SMSC:BRT] [SVC:brt] [ACT:] [BINF:] [from:90007] [to:554284017946] [flags:-1:1:-1:-1:19] [msg:7:54657374652038] [udh:0:] As well, how can I take out the binary mode sending the message? I tried to change the coding value in thr URL that I'm sending the message form 1 to 0, 2 and did not make effect. Thank's Douglas -- Dziugas -- Dziugas -- Dziugas
Re: [PATCH] Sending catenated messages in incorrect order
Hi Stipe, Stipe Tolj wrote: Alexander Malysh wrote: 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. yep, agree'ing here to Alex's position. Mainly this was because of my +0 voting. Actually it may be more -0 ;) @Enver: can you please check what vendor this specific EMI SMSC is? If it is a non standard vendor, hence, home-brewed, then you should force them to obey the specs. We really don't want to add workarrounds for bugs of other people's software, that's why specs are for. The SMSC is actually a home-brewed proxy in front of the real SMSC which is there solely for billing purposes. I fully agree with the avoiding workarounds concept. With the patch, I was trying to point out a problem which happens in rare circumstances. My initial point was to post a quick and dirty solution, hopefully get some constructive comments on it (thankfully that usually does happen) and later on fix the patch to the de-jure solution. Thanks, -- Enver
Re: [PATCH] Sending catenated messages in incorrect order
Jon Houser wrote:
If it's a spec breaker, make it something you have to turn on.
Then you can support the broken SMSCs should you need to, but the
end-user has to enable it. Heck, even call it hack-send-in-order or
something so you know every time you see it that it's just a hack.
Granted there's the issue of not breaking this functionality as time
progresses, but looking at the patch he submitted, it didn't look like
that big of a deal.
Again I'm not advocating for the addition of this feature.
Personally I don't need it and don't care. But if this is some big guy
SMSC and if their SMSC indeed *needs* to work this way for some reason,
it should definitely be considered.
My 2 cents (or whatever you local currency may be that is of
equivalence). :P
ok, good 2 cents in my opinion ;)
Actually Enver states that this is a home-brew SMSC, acting as proxy only for
billing purposes.
Now, taking into account your suggestion that we may make it optional takes my
voting from -0 to +0. Which is at least some improvement.
Now, as far as I understand, you're voting +0 too on taking this approach into
account regarding ordering. Alex votes -1, clearly.
Now, I'd like to hear more opinions on this.
@Enver: can we speed up that priority ordering here? in order not to use
octstr_compare() that consumes time? Can you have a benchmark test that conducts
what the performance loose would be in adding this optional feature?
I'd like to estimate what the general impact on performance would be ok, and
I'm too lazy to setup a test-suite for this on my own ;) I admit. But this is
due to preperations to get more open bug reports resolved and get closer to next
stable release.
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/
---
Re: [PATCH] Documentation changes regarding coding/dcs (was: Message Mode)
Douglas Jurcovichi wrote:
Hi Dziugas,
Sorry I got a mistake when I did the send;-)
The problem is I have a machine running kannel 1.2.1 that I send normal GSM messages using coding=1. In a new machine I put kannel 1.3.2 and when I send the message with coding=1 it goes binary.
you should definetly move to 1.4.0 stable or even CVS head, in terms of bug
fixing and stability.
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/
---
Re: sqlbox_configure_pgsql auto_increment?
Vincent CHAVANIS wrote:
- Original Message -
From: Cesar Gutierrez Corea [EMAIL PROTECTED]
To: devel@kannel.org
Sent: Saturday, November 05, 2005 8:59 AM
Subject: sqlbox_configure_pgsql auto_increment?
1. Is it safe to use cvs sources instead of 1.4.0 in a production
server?
yes it is.
2. Does current cvs sources break compatibility with 1.4.0?
Yes, that is IMO the reason why they probably wait to release a new version.
* gwlib/cfg.def: added config directive 'port' to 'myqsl|pgsql-connection'
groups, changed mysql config directive names to 'username' and
'password' to reflect the harmonization to others. (COMPATIBILITY BREAKER)
* gw/smsbox.c: in sendsms, wait for bearerbox reply before
replying to HTTP client. NOTE: compatbility breaker if the
HTTP client is reading the reply content, plus Kannel can now
return new HTTP status codes. Use 'immediate-sendsms-reply = true'
in the smsbox group to enable old behaviour.
yep, agree'ing to both.
BTW, release 1.4.1 stable is approaching!... Alex and I are hitting the bug
resolving issue in mantis... help wanted!
We have one major show stopper in the WAP section (actually bug #260)... but
this is a long standing one, and hard to analyze
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/
---
Re: [PATCH] configurable max retries
Alexander Malysh wrote:
Index: gwlib/cfg.def
===
RCS file: /home/cvs/gateway/gwlib/cfg.def,v
retrieving revision 1.112
diff -a -u -p -r1.112 cfg.def
--- gwlib/cfg.def21 Sep 2005 02:01:22 -1.112
+++ gwlib/cfg.def26 Oct 2005 20:36:52 -
@@ -118,6 +118,8 @@ SINGLE_GROUP(core,
OCTSTR(dlr-storage)
OCTSTR(maximum-queue-length)
OCTSTR(sms-incoming-queue-limit)
+OCTSTR(sms-resend-frequency)
+OCTSTR(sms-max-resend-retry)
)
+1 on the logic, I assume you did regression test this Alex, did you?
I'm -1 on the new config directive naming, and I'd like to change it to:
sms-resend-freq
sms-resend-retry
Reasons:
'sms-resend-freq' follows naming convention as introduced to prior config
directives 'store-dump-freq' within core group and 'timer-freq' for wapbox group
'sms-resend-retry' follows naming and semantical convention introduced via
'http-request-retry' within smsbox group.
I'll change these and commit to cvs.
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/
---
Close bug 195: Reply path parameter is sent in every case
I think you can close this report. It's not really a bug as the reply path parameter is in the CIMD2 spec. The reason it is set to default 0 if not otherwise set, is because some phones will insist on trying to reply to an SMS when the RPI is absent. If you search the devel archive you should find some discussion on this bug. -- Yours sincerely, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.no/
Re: [PATCH] configurable max retries
Stipe Tolj wrote:
+1 on the logic, I assume you did regression test this Alex, did you?
I'm -1 on the new config directive naming, and I'd like to change it to:
sms-resend-freq
sms-resend-retry
Reasons:
'sms-resend-freq' follows naming convention as introduced to prior
config directives 'store-dump-freq' within core group and 'timer-freq'
for wapbox group
'sms-resend-retry' follows naming and semantical convention introduced
via 'http-request-retry' within smsbox group.
I'll change these and commit to cvs.
commited the naming convention fix for the two new directives to cvs.
@Alex: are we required in having two seperate integers in the Msg struct to
reflect the resending issue? I know that you generally do reduce needed vars as
much as possible, so a short description why two are needed would be great.
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/
---
Close bug 94: CIMD2 sender or orgininating address is not sent to CIMD host
Unable to duplicate -- Yours sincerely, Eurobate ASA Arne K. Haaje Senior Network Engineer Eurobate ASA - Postboks 4589 Nydalen - 0404 Oslo - Norway Phone: +47 23 22 73 73 - Fax: +47 23 22 73 74 - Mob: +47 92 88 44 66 http://www.eurobate.no/
Re: Message Mode
Douglas Jurcovichi wrote:
2005-11-08 15:10:18 Sent SMS [SMSC:BRT] [SVC:brt] [ACT:] [BINF:]
[from:90007] [to:554284017946] [flags:-1:1:-1:-1:19]
[msg:7:54657374652038] [udh:0:]
As well, how can I take out the binary mode sending the message?
I tried to change the coding value in thr URL that I'm sending the
message form 1 to 0, 2 and did not make effect.
now, the access.log entry stated flags:-1:1:
which means you have passed coding=1 (=8bit=binary) via the sendsms interface.
What happens if you ommit the 'coding=xx' parameter and simply send a normal
text message without specifying coding? Default is should be 7bit text.
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/
---
