Alexander Malysh wrote:
Hi,
this patch seems to be broken in all areas. Stipe? what should this
patch do?
1) I don't like call bb_alog_sms from smsc module, it's up to smsc layer
the call to bb_alog_sms() is in order to log the "FAILING DLR receive" event.
Unfortunatly we don't pass any MO/DLR to the upper (abstractive) layer, hence we
can't do the alog call there?!... I know it's a bit kludgy, any better suggestions?
2) even if all agreeing with (1) it's incomplete because handle only
data_sm pdu
you're right... damn... I missed the deliver_sm case switch. Need to fix it.
BTW, I'd suggest anyway to "handle" DLRs that could not be "found" in DLR
storage somehow... ie. by putting them into a seperate DB table, so legacy
systems can access them. And for kannel the table is the message sink.
3) msg->sms.charset should go away because we have _always_ internal
charset UTF-8
that was _before_ you introduced UTF-8 patch. We had latin1 as default, meaning
no MTs could be forwarded to GSM-03.38 defaulted (data_coding = 0x00) SMSCs for
connected smsbox instances... Now this needs other treatment after your UTF-8 patch.
4) we didn't see this patch posted to ML and it changed behavior
Nop... there is no behaviour change. The patch works only different if msg
struct carries the "GSM-03.38" as msg->sms.charset which smsbox does not do. So
behaviour remains the same here. Also for bb_alog() logging, it's ony a feature
add. :pp
p
I'm vote ++1 for reverting this patch.
nop... it doesn't need reverting... it needs simply clearing up the situation
from my "let's support GSM-03.38 trully for SMPP conections" and your more
generic UTF-8 patch.
Stipe
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
