Re: [PATCH] allow setting service-type for SMPP SMSC
At 04:49 PM 2/18/03 +0100, Stipe Tolj wrote: > > just kidding. I guess you're then interested in getting smppbox into > > Kannel's cvs repository, right?! > > No, it's a standalone app that has nothing to do with Kannel. I know (or I assumed to be more precise :). But I guessed you'd be interested in playing arround with out SMPP server implementation based on Kannel's sources. I think many of us on the list would love to play with yur smpp box...hint... ;-) nisan Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] allow setting service-type for SMPP SMSC
At 01:51 PM 2/18/03 +, David Holland wrote: Please find below a patch to allow an SMPP SMSC group to contain a service-type definition. Previously Kannel would always send NULL, i.e. "use default service-type". I've tested this patch and it works against Xwireless/Mblox SMPP server. If no-one objects I'll commit it to CVS and update the userguide. looks good +1 nisan
multiple bearer box ?
hello all, i am new to this mailing list, i want to know if anybody's working on multi-bearer box architecture or there are any plans as it was identified as one of the key performance bottleneck issues, also the persistance of message streams as they pass through bearer box. Can someone also guide me where can i find detailed status on the projects overal status Regards Asif __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com
Re: Cookie handling
Citando "Wilms, Stefan, VIS-THND" <[EMAIL PROTECTED]>: > Dear all, > > trying to get access to our intranet via WAP, using kannel 1.1.6 (with > --enable-cookies compiled) There's something wrong with cookie support but as I'm gonna need them to work soon for a project of mine, I'll look at the code and will make sure they work. -- Davi / Bruno.RodriguesLitux.Org Litux.org: 19:07:34 up 87 days, 20:23, 5 users, load average: 0.07, 0.09, 0.16 'May you do Good Magic with Perl. -- Larry Wall's blessing'
Re: [PATCH] allow setting service-type for SMPP SMSC
> > just kidding. I guess you're then interested in getting smppbox into > > Kannel's cvs repository, right?! > > No, it's a standalone app that has nothing to do with Kannel. I know (or I assumed to be more precise :). But I guessed you'd be interested in playing arround with out SMPP server implementation based on Kannel's sources. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] allow setting service-type for SMPP SMSC
Stipe Tolj <[EMAIL PROTECTED]> wrote: > Ian Cass wrote: >> Heh, I wrote that server :) > > ok, so we know who to blaim ;)) heh > just kidding. I guess you're then interested in getting smppbox into > Kannel's cvs repository, right?! No, it's a standalone app that has nothing to do with Kannel. -- Ian Cass
Re: [PATCH] allow setting service-type for SMPP SMSC
Ian Cass wrote: > > David Holland <[EMAIL PROTECTED]> wrote: > > I've tested this patch and it works > > against Xwireless/Mblox SMPP server. > > Heh, I wrote that server :) ok, so we know who to blaim ;)) just kidding. I guess you're then interested in getting smppbox into Kannel's cvs repository, right?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] allow setting service-type for SMPP SMSC
Am Dienstag, 18. Februar 2003 15:34 schrieb Stipe Tolj: > > +1 from me too. We use similar patch for a while... > > so why didn't you post it ;)) ahh I thought it is uninteresting for all ;) > > Stipe > > [EMAIL PROTECTED] > --- > Wapme Systems AG > > Vogelsanger Weg 80 > 40470 Düsseldorf > > Tel: +49-211-74845-0 > Fax: +49-211-74845-299 > > E-Mail: [EMAIL PROTECTED] > Internet: http://www.wapme-systems.de > --- > wapme.net - wherever you are -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de msn: [EMAIL PROTECTED]
Re: [PATCH] allow setting service-type for SMPP SMSC
David Holland <[EMAIL PROTECTED]> wrote: > I've tested this patch and it works > against Xwireless/Mblox SMPP server. Heh, I wrote that server :) -- Ian Cass
Cookie handling
Title: Nachricht Dear all, trying to get access to our intranet via WAP, using kannel 1.1.6 (with --enable-cookies compiled), I can log in, but dependent on the device I´m using, I´m directly bounced back to the login prompt after successful login. It seems that we do have issues with keeping the session (handled by the weblogic cookies). The log says: WARNING: Skipping header: Set-Cookie: Apache=195.233.211.12.28307107282567; path=/ 2003-02-05 13:14:42 [1]ERROR: WSP: Do not know how to encode header type 65 2003-02-05 13:14:42 [1]WARNING: Skipping header: Set-Cookie: unique_id=356e149f944c6b70b465f1610ca5e519; expires=Monday, 04-Aug-2003 12:14:43 GMT; path= 2003-02-05 13:14:42 [1]ERROR: WSP: Do not know how to encode header type 65 2003-02-05 13:14:42 [1] WARNING: Skipping header: Set-Cookie: auto_login=FALSE; expires=Monday, 04-Aug-2003 12:14:43 GMT; path= 2003-02-05 13:14:42 [1]ERROR: WSP: Do not know how to encode header type 65 2003-02-05 13:14:42 [1] WARNING: Skipping header: Set-Cookie: WebLogicSession=PkEAMmOgNtNJG71VTLyxeRFiM1gz6agSgkGKum1NvBvXg0Exk7eQ|-8360459692770970825/1131413859/6/280/280/8510/8510/280/-1; path=/ Do the errors and warnings indicate that cookies might be dropped and could this be the reason for the session not being kept or does kannel keep the cookies independent on these errors? Thanks for your useful hints in advance, Stefan _ Stefan WilmsVodafone Information Systems GmbHNetwork & SecurityRehhecke 50 D-40885 Ratingen-LintorfTel.: +49 2102 97-1114Fax: +49 2102 9770-1114 Mail: [EMAIL PROTECTED] http://www.vodafone-is.de
Re: [PATCH] allow setting service-type for SMPP SMSC
On Tue, Feb 18, 2003 at 03:34:24PM +0100, Stipe Tolj wrote: > so why didn't you post it ;)) Too late, I've committed it now :-) Dave -- :: David Holland :: Systems Manager :: 3G Lab :: +44 01223 478900 :: "Fare evasion also adds a much needed element of excitement to the otherwise dull trek to work." -- Ronald Seegers
Re: [PATCH] allow setting service-type for SMPP SMSC
> +1 from me too. We use similar patch for a while... so why didn't you post it ;)) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: DCS and PID handling in Kannel
Bruno Rodrigues wrote: >It's not a "Kannel decision", it's a "kannel option" > >did you understand the "you can generate every valid dcs" ? > >did you understand that third parties, which might not have a clue about dcs and >like to just say &mclass=1 for flash or &coding=3&text= for unicode accented >chars? Bruno, you are talking about sendsms interface (MTs), and David is trying to explain a problem (or lack of funcionality) in MOs. What David is proposing is to copy the DCS and PID fields of the MOs received in a corresponding msg->sms.x fields (keeping also the actual fields) and forward them to smsbox and the corresponding %urlpatterns. For example, msg->sms.orig_dcs, msg->sms.orig_pid, etc. David, did I explain it right? Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08
Re: [PATCH] allow setting service-type for SMPP SMSC
Hi, +1 from me too. We use similar patch for a while... Am Dienstag, 18. Februar 2003 15:08 schrieb Stipe Tolj: > David Holland wrote: > > On Tue, Feb 18, 2003 at 02:58:12PM +0100, Stipe Tolj wrote: > > > One thing only: what's the default of the value if *no* config > > > directive is given?! > > > > NULL. (and I have tested that -- it appears correctly in the PDU dump) > > > > > It looks you don't initialize the variable and > > > hence you will pass garbage, or does cfg_get() return NULL in case the > > > value is not given?! > > > > Yes, that's what happens. > > ok, then I'm off with ++1 :) > > Stipe > > [EMAIL PROTECTED] > --- > Wapme Systems AG > > Vogelsanger Weg 80 > 40470 Düsseldorf > > Tel: +49-211-74845-0 > Fax: +49-211-74845-299 > > E-Mail: [EMAIL PROTECTED] > Internet: http://www.wapme-systems.de > --- > wapme.net - wherever you are -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh ___ Centrium GmbH Ehrenstraße 2 50672 Köln Fon: +49 (0221) 277 49 240 Fax: +49 (0221) 277 49 109 email: [EMAIL PROTECTED] web: www.centrium.de msn: [EMAIL PROTECTED]
Re: [PATCH] allow setting service-type for SMPP SMSC
David Holland wrote: > > On Tue, Feb 18, 2003 at 02:58:12PM +0100, Stipe Tolj wrote: > > One thing only: what's the default of the value if *no* config > > directive is given?! > > NULL. (and I have tested that -- it appears correctly in the PDU dump) > > > It looks you don't initialize the variable and > > hence you will pass garbage, or does cfg_get() return NULL in case the > > value is not given?! > > Yes, that's what happens. ok, then I'm off with ++1 :) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: [PATCH] allow setting service-type for SMPP SMSC
On Tue, Feb 18, 2003 at 02:58:12PM +0100, Stipe Tolj wrote: > One thing only: what's the default of the value if *no* config > directive is given?! NULL. (and I have tested that -- it appears correctly in the PDU dump) > It looks you don't initialize the variable and > hence you will pass garbage, or does cfg_get() return NULL in case the > value is not given?! Yes, that's what happens. Dave -- :: David Holland :: Systems Manager :: 3G Lab :: +44 01223 478900 :: "Even if you are on the right track, you'll get run over if you just sit there."
Re: [PATCH] allow setting service-type for SMPP SMSC
David Holland wrote: > > Please find below a patch to allow an SMPP SMSC group to contain a > service-type definition. Previously Kannel would always send NULL, i.e. > "use default service-type". I've tested this patch and it works against > Xwireless/Mblox SMPP server. If no-one objects I'll commit it to CVS and > update the userguide. > > Many thanks to Nick Clarey for writing this when I realised what the > missing functionality was. seems clean to me from first glance, +1. One thing only: what's the default of the value if *no* config directive is given?! It looks you don't initialize the variable and hence you will pass garbage, or does cfg_get() return NULL in case the value is not given?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
[PATCH] allow setting service-type for SMPP SMSC
Please find below a patch to allow an SMPP SMSC group to contain a
service-type definition. Previously Kannel would always send NULL, i.e.
"use default service-type". I've tested this patch and it works against
Xwireless/Mblox SMPP server. If no-one objects I'll commit it to CVS and
update the userguide.
Many thanks to Nick Clarey for writing this when I realised what the
missing functionality was.
Dave
--
:: David Holland :: Systems Manager :: 3G Lab :: +44 01223 478900 ::
"Standards ought to be less whimsical than, say, Microsoft APIs."
-- Graham Nelson
Index: gw/smsc/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.23
diff -u -r1.23 smsc_smpp.c
--- gw/smsc/smsc_smpp.c 14 Feb 2003 10:44:39 - 1.23
+++ gw/smsc/smsc_smpp.c 18 Feb 2003 13:34:11 -
@@ -89,6 +89,7 @@
Octstr *address_range;
Octstr *our_host;
Octstr *my_number;
+Octstr *service_type;
int source_addr_ton;
int source_addr_npi;
int dest_addr_ton;
@@ -120,7 +121,7 @@
int max_pending_submits, int reconnect_delay,
int version, int priority, Octstr *my_number,
int smpp_msg_id_type, int autodetect_addr,
- Octstr *alt_charset)
+ Octstr *alt_charset, Octstr *service_type)
{
SMPP *smpp;
@@ -144,6 +145,7 @@
smpp->alt_dcs = alt_dcs;
smpp->our_host = octstr_duplicate(our_host);
smpp->my_number = octstr_duplicate(my_number);
+smpp->service_type = octstr_duplicate(service_type);
smpp->transmit_port = transmit_port;
smpp->receive_port = receive_port;
smpp->enquire_link_interval = enquire_link_interval;
@@ -173,6 +175,7 @@
octstr_destroy(smpp->username);
octstr_destroy(smpp->password);
octstr_destroy(smpp->system_type);
+octstr_destroy(smpp->service_type);
octstr_destroy(smpp->address_range);
octstr_destroy(smpp->our_host);
octstr_destroy(smpp->my_number);
@@ -326,6 +329,9 @@
pdu->u.submit_sm.source_addr = octstr_duplicate(msg->sms.sender);
pdu->u.submit_sm.destination_addr = octstr_duplicate(msg->sms.receiver);
+
+/* Set the service type of the outgoing message */
+pdu->u.submit_sm.service_type = octstr_duplicate(smpp->service_type);
/* Check for manual override of source ton and npi values */
if(smpp->source_addr_ton > -1 && smpp->source_addr_npi > -1) {
@@ -1252,6 +1258,7 @@
long dest_addr_npi;
Octstr *our_host;
Octstr *my_number;
+Octstr *service_type;
SMPP *smpp;
int ok;
int transceiver_mode;
@@ -1284,6 +1291,7 @@
address_range = cfg_get(grp, octstr_imm("address-range"));
our_host = cfg_get(grp, octstr_imm("our-host"));
my_number = cfg_get(grp, octstr_imm("my-number"));
+service_type = cfg_get(grp, octstr_imm("service-type"));
system_id = cfg_get(grp, octstr_imm("system-id"));
if (system_id != NULL) {
@@ -1328,6 +1336,11 @@
error(0, "SMPP: Configuration file doesn't specify system-type.");
ok = 0;
}
+if (octstr_len(service_type) > 6) {
+error(0, "SMPP: Service type must be 6 characters or less.");
+ok = 0;
+}
+
if (!ok)
return -1;
@@ -1379,7 +1392,7 @@
dest_addr_npi, alt_dcs, enquire_link_interval,
max_pending_submits, reconnect_delay,
version, priority, my_number, smpp_msg_id_type,
- autodetect_addr, alt_charset);
+ autodetect_addr, alt_charset, service_type);
conn->data = smpp;
conn->name = octstr_format("SMPP:%S:%d/%d:%S:%S",
@@ -1401,6 +1414,7 @@
octstr_destroy(my_number);
octstr_destroy(smsc_id);
octstr_destroy(alt_charset);
+octstr_destroy(service_type);
conn->status = SMSCCONN_CONNECTING;
Index: gwlib/cfg.def
===
RCS file: /home/cvs/gateway/gwlib/cfg.def,v
retrieving revision 1.81
diff -u -r1.81 cfg.def
--- gwlib/cfg.def 14 Feb 2003 10:55:37 - 1.81
+++ gwlib/cfg.def 18 Feb 2003 13:34:11 -
@@ -232,6 +232,7 @@
OCTSTR(source-addr-npi)
OCTSTR(dest-addr-ton)
OCTSTR(dest-addr-npi)
+OCTSTR(service-type)
OCTSTR(source-addr-autodetect)
OCTSTR(enquire-link-interval)
OCTSTR(max-pending-submits)
Re: DCS and PID handling in Kannel
Citando Dave White <[EMAIL PROTECTED]>: > Bruno Rodrigues wrote: > > > > Kannel should decide for the 0x0x "spelling" unless you pass alt-dcs > field, > > which will select the 0xFx "spelling". > > > > This isn't Kannel's decision to make; this is data set by the end user's > telephone, which may have requirements neither you nor I are (or could > be) aware of. The analogy to a case-insensitive filesystem namespace is > quite fitting if you think about it carefully. > > I did look at alt-dcs, and I consider it a kludge. Sorry. It's not a "Kannel decision", it's a "kannel option" did you understand the "you can generate every valid dcs" ? did you understand that third parties, which might not have a clue about dcs and like to just say &mclass=1 for flash or &coding=3&text= for unicode accented chars? sorry. it's not my decision anymore. I vote +0 for a dcs field but no changes to other fields. -- Davi / Bruno.RodriguesLitux.Org Litux.org: 13:19:04 up 87 days, 14:34, 4 users, load average: 0.06, 0.04, 0.04 'Turn right here. No! NO! The OTHER right!'
Re: [PATCH] Fix for gw/smsc/smsc_smpp.c - bogus coding and no udh on deliver_sm
Citando Dave White <[EMAIL PROTECTED]>:
> This patch fixes the following issues:
>
> *) Kannel coding param is overwritten with wrong values by pdu_to_msg
> (e.g. a Nokia business card, which is 8-bit data encoded as iso-8859-1,
> is processed by Kannel as 7-bit text, and will be forwarded as coding 1.)
I see your point now. Setting msg->sms.coding by hand is broken. If you can
gather a dcs field from smsc pdu, you should call:
if (! dcs_to_fields(&msg, dcs)) {
error(0, "EMI2[%s]: invalid dcs received",
octstr_get_cstr(privdata->name));
/* XXX Should we discard message ? */
dcs_to_fields(&msg, 0);
}
which will fill sms.coding, sms.compress, sms.mclass and sms.mwi correctly.
I'm now commiting a quick patch to set alt-dcs too on MO messages.
Similary, you should get msg and passing it to fields_to_dcs(msg), you'll get
the right dcs based on coding, compress, mclass, mwi and alt-dcs
> *) UDH is ignored in SMS-MO
If SMPP developers agree with this code, I vote +1 for it and give a thank you
very much for your help
--
Davi / Bruno.RodriguesLitux.Org
Litux.org: 12:59:19 up 87 days, 14:14, 4 users, load average: 0.37, 0.17, 0.08
'Linux is obsolete
(Andrew Tanenbaum)'
Re: [PATCH] Fix for gw/smsc/smsc_smpp.c - bogus coding and no udh on deliver_sm
Citando Dave White <[EMAIL PROTECTED]>:
> This patch fixes the following issues:
>
> *) Kannel coding param is overwritten with wrong values by pdu_to_msg
> (e.g. a Nokia business card, which is 8-bit data encoded as iso-8859-1,
> is processed by Kannel as 7-bit text, and will be forwarded as coding 1.)
I see your point now. Setting msg->sms.coding by hand is broken. If you can
gather a dcs field from smsc pdu, you should call:
if (! dcs_to_fields(&msg, dcs)) {
error(0, "EMI2[%s]: invalid dcs received",
octstr_get_cstr(privdata->name));
/* XXX Should we discard message ? */
dcs_to_fields(&msg, 0);
}
which will fill sms.coding, sms.compress, sms.mclass and sms.mwi correctly.
I'm now commiting a quick patch to set alt-dcs too on MO messages.
Similary, you should get msg and passing it to fields_to_dcs(msg), you'll get
the right dcs based on coding, compress, mclass, mwi and alt-dcs
> *) UDH is ignored in SMS-MO
If SMPP developers agree with this code, I vote +1 for it and give a thank you
very much for your help
--
Davi / Bruno.RodriguesLitux.Org
Litux.org: 12:59:19 up 87 days, 14:14, 4 users, load average: 0.37, 0.17, 0.08
'Linux is obsolete
(Andrew Tanenbaum)'
Re: DCS and PID handling in Kannel
Bruno Rodrigues wrote: > Kannel should decide for the 0x0x "spelling" unless you pass alt-dcs field, which will select the 0xFx "spelling". This isn't Kannel's decision to make; this is data set by the end user's telephone, which may have requirements neither you nor I are (or could be) aware of. The analogy to a case-insensitive filesystem namespace is quite fitting if you think about it carefully. I did look at alt-dcs, and I consider it a kludge. Sorry. David WHITE CONNECT AUSTRIA
Re: DCS and PID handling in Kannel
Citando Dave White <[EMAIL PROTECTED]>: > Say we have a binary (8-bit) message without compression, but with > message class 1. These are pretty common; Nokia phones use these for > most Smart Messaging MO's. > > There are two valid representations of this as a DCS octet: > > (WARNING -- try a fixed-width font if this looks like junk) > > 0001 0101 = 0x15 >^^ ^ ^ >|| | |_ Message Class 1 >|| |___ 8 bit data >||__ Message class present >|___ No compression > > 0101 = 0xF5 > ^ ^ ^ > | | |_ Message class 1 > | |___ 8 bit data > |__ Message class present > > Another fun example is 7-bit "flash" (Class 0) SMs > > 0001 = 0x10 > > = 0x240 > > Given the information Kannel passes over HTTP POST, it is impossible to > decide which of the two "spellings" of an equivalent DCS was originally > sent in the MO. Kannel should decide for the 0x0x "spelling" unless you pass alt-dcs field, which will select the 0xFx "spelling". see X-Kannel-Alt-DCS -- Davi / Bruno.RodriguesLitux.Org Litux.org: 12:55:12 up 87 days, 14:10, 4 users, load average: 0.15, 0.13, 0.06 'lp1 on fire -- One of the more obfuscated kernel messages'
Re: DCS and PID handling in Kannel
Citando Dave White <[EMAIL PROTECTED]>: > Say we have a binary (8-bit) message without compression, but with > message class 1. These are pretty common; Nokia phones use these for > most Smart Messaging MO's. > > There are two valid representations of this as a DCS octet: > > (WARNING -- try a fixed-width font if this looks like junk) > > 0001 0101 = 0x15 >^^ ^ ^ >|| | |_ Message Class 1 >|| |___ 8 bit data >||__ Message class present >|___ No compression > > 0101 = 0xF5 > ^ ^ ^ > | | |_ Message class 1 > | |___ 8 bit data > |__ Message class present > > Another fun example is 7-bit "flash" (Class 0) SMs > > 0001 = 0x10 > > = 0x240 > > Given the information Kannel passes over HTTP POST, it is impossible to > decide which of the two "spellings" of an equivalent DCS was originally > sent in the MO. Kannel should decide for the 0x0x "spelling" unless you pass alt-dcs field, which will select the 0xFx "spelling". see X-Kannel-Alt-DCS -- Davi / Bruno.RodriguesLitux.Org Litux.org: 12:55:12 up 87 days, 14:10, 4 users, load average: 0.15, 0.13, 0.06 'lp1 on fire -- One of the more obfuscated kernel messages'
[PATCH] Fix for gw/smsc/smsc_smpp.c - bogus coding and no udh ondeliver_sm
This patch fixes the following issues:
*) Kannel coding param is overwritten with wrong values by pdu_to_msg
(e.g. a Nokia business card, which is 8-bit data encoded as iso-8859-1,
is processed by Kannel as 7-bit text, and will be forwarded as coding 1.)
*) UDH is ignored in SMS-MO
The patch is included as an attachment.
It has been tested for basic correctness and seems to work.
Have fun!
David WHITE
CONNECT AUSTRIA
? smpp-patch.txt
? smpp.patch
Index: gw/smsc/smsc_smpp.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.22
diff -u -r1.22 smsc_smpp.c
--- gw/smsc/smsc_smpp.c 2 Jan 2003 14:43:00 - 1.22
+++ gw/smsc/smsc_smpp.c 18 Feb 2003 12:37:58 -
@@ -234,6 +234,7 @@
static Msg *pdu_to_msg(SMPP *smpp, SMPP_PDU *pdu)
{
Msg *msg;
+int udh_offset = 0;
gw_assert(pdu->type == deliver_sm);
@@ -242,10 +243,17 @@
pdu->u.deliver_sm.source_addr = NULL;
msg->sms.receiver = pdu->u.deliver_sm.destination_addr;
pdu->u.deliver_sm.destination_addr = NULL;
-msg->sms.msgdata = pdu->u.deliver_sm.short_message;
-pdu->u.deliver_sm.short_message = NULL;
dcs_to_fields(&msg, pdu->u.deliver_sm.data_coding);
+if (pdu->u.deliver_sm.esm_class & ESM_CLASS_SUBMIT_UDH_INDICATOR) {
+udh_offset = octstr_get_char(pdu->u.deliver_sm.short_message,0)+1;
+msg->sms.udhdata = octstr_copy(pdu->u.deliver_sm.short_message,0,udh_offset);
+msg->sms.msgdata =
+octstr_copy(pdu->u.deliver_sm.short_message,udh_offset,octstr_len(pdu->u.deliver_sm.short_message)-udh_offset);
+} else {
+ msg->sms.msgdata = pdu->u.deliver_sm.short_message;
+pdu->u.deliver_sm.short_message = NULL;
+}
+
/* handle default data coding */
switch (pdu->u.deliver_sm.data_coding) {
case 0x00: /* default SMSC alphabet */
@@ -257,11 +265,9 @@
if (charset_convert(msg->sms.msgdata,
octstr_get_cstr(smpp->alt_charset), "ISO-8859-1") != 0)
error(0, "Failed to convert msgdata from charset <%s> to <%s>,
will leave as is.",
octstr_get_cstr(smpp->alt_charset), "ISO-8859-1");
-msg->sms.coding = DC_7BIT;
} else { /* assume GSM 03.38 7-bit alphabet */
charset_gsm_to_latin1(msg->sms.msgdata);
-msg->sms.coding = DC_7BIT;
}
break;
case 0x01: /* ASCII or IA5 - not sure if I need to do anything */
@@ -288,7 +294,6 @@
* you implement them if you feel like it
*/
default:
-msg->sms.coding = DC_7BIT;
}
msg->sms.pid = pdu->u.deliver_sm.protocol_id;
Re: DCS and PID handling in Kannel
Citando Stipe Tolj <[EMAIL PROTECTED]>: > If it's DCS is really broken up in MO SMPP, then please re-send the > patch. Use [PATCH] in the mail subject line. > > And try to explain in the mail what the problem was and what you patch > does to fix it. Thanks in advance. > > I'm definetly willing to review it and vote. > > At least we can offer you that alternative option. If you want I can re-ask for a SMPP connection and do some debugging in here to fix what's wrong with with fields <=> DCS. -- Davi / Bruno.RodriguesLitux.Org Litux.org: 12:42:06 up 87 days, 13:57, 2 users, load average: 0.24, 0.10, 0.03 'Sex dumps core (Sex is a Simple editor for X11) -- Seen on debian bugtracking'
Re: DCS and PID handling in Kannel
Stipe Tolj wrote: If it's DCS is really broken up in MO SMPP, then please re-send the patch. Use [PATCH] in the mail subject line. The SMPP patch just fixes the following issues: *) Kannel coding param is overwritten with wrong values by pdu_to_msg (e.g. a Nokia business card, which is 8-bit data encoded as iso-8859-1, is processed by Kannel as 7-bit text, and will be forwarded as coding 1.) *) UDH is ignored in SMS-MO I'll repost my revised smsc_smpp.c patch a little later, with [PATCH] in the Subject line. Hopefully, it will apply and be useful. These bugs made a larger issue with Kannel considerably worse; the DCS problem can be illustrated with the following example: Say we have a binary (8-bit) message without compression, but with message class 1. These are pretty common; Nokia phones use these for most Smart Messaging MO's. There are two valid representations of this as a DCS octet: (WARNING -- try a fixed-width font if this looks like junk) 0001 0101 = 0x15 ^^ ^ ^ || | |_ Message Class 1 || |___ 8 bit data ||__ Message class present |___ No compression 0101 = 0xF5 ^ ^ ^ | | |_ Message class 1 | |___ 8 bit data |__ Message class present Another fun example is 7-bit "flash" (Class 0) SMs 0001 = 0x10 = 0x240 Given the information Kannel passes over HTTP POST, it is impossible to decide which of the two "spellings" of an equivalent DCS was originally sent in the MO. My proposal for variant DCS and PID handling was: *) keep the "parsed" ambiguous representation (mwi,mclass,coding,compress etc.) *) add the original DCS octet as an additional parameter *) add "parsed" fields for the bit fields in protocol_id (in particular, the "replace message class" has some useful properties) That was the proposal. Sorry if it wasn't clear before. David WHITE CONNECT AUSTRIA
Re: DCS and PID handling in Kannel
If it's DCS is really broken up in MO SMPP, then please re-send the patch. Use [PATCH] in the mail subject line. And try to explain in the mail what the problem was and what you patch does to fix it. Thanks in advance. I'm definetly willing to review it and vote. At least we can offer you that alternative option. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
RE: Kannel wap limits ?
Citando Igor Ivoilov <[EMAIL PROTECTED]>: > I have to fix wpt layer to do not panic if psn is going to be > 255 > but this is a limit of SAR and can be overcome with ESAR. > Does 3650 support ESAR? I don't have such a phone to check it by myself So it seems altough kannel's only relevant information is the 350K sdu. -- Davi / Bruno.RodriguesLitux.Org Litux.org: 10:54:26 up 87 days, 12:10, 8 users, load average: 0.03, 0.05, 0.01 'Linus? Whose that? -- clueless newbie on #Linux'
Re: DCS and PID handling in Kannel
Citando David White <[EMAIL PROTECTED]>: > On Tue, 2003-02-18 at 07:06, Bruno Rodrigues wrote: > > > DCS is used internally in kannel and thus should be "controled" by it. > > That's why we have seperated fields to build DCS at the end. > > For example, if you set UDH and don't set coding, kannel will > > automatically (legacy behaviour) select 8 bit text and adapt your text > > data to it. > > Which is severely broken. Consider EMS messages, which have (e.g.) a > bitmap in the header and 7-bit text in the remaining space in the user > data field. Interpretation of user data is solely a function of DCS, > that's why it's there. It was broken, that's why it's called legacy, but you can force coding=1 and send your 7 bit ems. > > Using coding, mclass, mwi and alt-dcs, every dcs combination can be > > done, if smsc modules supports it of course. EMI2 and AT2 surelly > > supports it. > > > > I can make a table in userguide with it's combinations to describe it. > > > > You will discover that the coding scheme cannot be completely > reconstructed from the data Kannel sends. DCS 0xF5 should be equivalent > to DCS 0x15, but there's no guarantee a mobile phone (or some > third-party app for a smartphone) will be so smart as to recognize the > equivalence. GET 'http://.../sendsms?...&text=123&coding=2&mclass=2' 2003-02-18 10:41:36 Sent SMS ... [flags:2:2:0:0:0] [msg:3:313233] [udh:0:] 2003-02-18 10:41:35 [15] DEBUG: EMI2[Vodafone-P31579]: emi2 sending packet: <92/.../020115///81> = DCS = 0x15 GET 'http://.../sendsms?...&text=123&coding=2&mclass=2&alt-dcs=1' 2003-02-18 10:41:41 Sent SMS ... [flags:2:2:0:0:0] [msg:3:313233] [udh:0:] 2003-02-18 10:41:41 [15] DEBUG: EMI2[Vodafone-P31579]: emi2 sending packet: <93/.../0201F5///97> Trust me. You can make a 1 to 1 conversion between DCS and (mc,co,mwi,alt). I've done that code, and I've tested it several times. > I made these suggestions and sent an SMPP patch because I encountered > problems trying to get Kannel to handle MO messages correctly. One of > these problems is that it screws up DCS. Can you send me your message or a url to an archive ? I usually don't pay attention to other smsc modules as I don't use them. -- Davi / Bruno.RodriguesLitux.Org Litux.org: 10:35:18 up 87 days, 11:50, 7 users, load average: 0.03, 0.04, 0.00 '"It is easier to port a shell than a shell script." -- Larry Wall'
Re: Rotatelog for traditional Unix systems
Citando Alex Judd <[EMAIL PROTECTED]>:
> Everyone
>
> Additional comments on rotating logs for the userguide for systems that
> don't have RedHat's logrotate installed.
>
> + ACTIONS:
> + kill - HUP | ps -ef | grep -i production | awk '{print $2}' :
> /var/log/kannel/access.log, /var/log/kannel/enpocket.log,
> /var/log/kannel/smsbox.log
> + NOTIFY:
> + [EMAIL PROTECTED]
kill - HUP | something ? what's this ? shouldn't it be something like
kill -HUP `something | otherthing` ?
isn't there a "pidof" command ?
and won't rotatelog support /var/log/kannel/*.log ?
--
Davi / Bruno.RodriguesLitux.Org
Litux.org: 10:29:55 up 87 days, 11:45, 7 users, load average: 0.12, 0.07, 0.01
'Turn right here. No! NO! The OTHER right!'
Re: [FYI] fixed userguide.xml now
Citando Stipe Tolj <[EMAIL PROTECTED]>: > Hi Bruno, > > forget about my previous mail. I just fixed it. See > http://www.kannel.org/cgi-bin/viewcvs.cgi/gateway/doc/userguide/userguide.xml.diff?r1=1.206&r2=1.207 > if you are interested in what the problem was ;) was me thinking about looking for that URL and seeing that we are using docbook 3.1 and there's already 4.2 and noticing that I'm using docbook-dsssl and there's a docbook-xml in debian. ;) -- Davi / Bruno.RodriguesLitux.Org Litux.org: 10:26:41 up 87 days, 11:42, 7 users, load average: 0.15, 0.07, 0.01 'Let's call it an accidental feature. --Larry Wall'
Re: Billing & Kannel SMS side
Citando "Kita B. Ndara" <[EMAIL PROTECTED]>: > > --- Stipe Tolj <[EMAIL PROTECTED]> wrote: > > "Kita B. Ndara" wrote: > > > > > > Is there any good reason why the kannel sms part > > does > > > not incorporate some kind of billing support? What > > > Ok, but in this case kannel would merely leave it up > to external commands to provide this functionality -- > just as we do for content. That is, only if the > pre-submit comamnd returns TRUE do we put the msg on > the smsc-specific queue, and after it is accepted, we > run the post-submit command. The first one is like a > balance check, the latter the real billing command. > Does this still violate the goodness of OS? Yes, because you don't want to make a such expensive call to an external system, for each message you send. If you are sending 100's msg/sec, you would need a system that would reply faster than 0,010 seconds ;) -- Davi / Bruno.RodriguesLitux.Org Litux.org: 10:15:57 up 87 days, 11:31, 7 users, load average: 0.07, 0.02, 0.00 'Manchmal stehe nachts auf und installier's mir einfach... -- H0arry @ IRC'
Re: Billing & Kannel SMS side
Citando "Arne K. Haaje" <[EMAIL PROTECTED]>: > I am thinking about adding support to the CIMD2 module for the Tarrif > field. This is in Nokias official specifications. It is a field like any > others where you can set the tarrif class. > > As it is in the official specs. I think it would be useful. Are there > any objections to me adding support for it? > > If not, would the right way be to let the user specify it in the URL for > sendsms - tarrif=12 ? UCP 4.0 5.1.2.5 XSer Type of service 0C: Billing Identifier This type of service enables Large Accounts to send additional billing information to the SMSC. Billing Identifier data element is an alphanumeric field with a variable length of at least 0 and at most 20 characters. These characters need to be part of the Visible String character set as defined in ITU-T. Each character takes two hexadecimal positions. I need a 0-20 chars parameter for UCP :) tarrif or billing is ok for me. -- Davi / Bruno.RodriguesLitux.Org Litux.org: 10:09:34 up 87 days, 11:25, 7 users, load average: 0.00, 0.04, 0.00 'Being overloaded is the sign of a true Debian maintainer. -- JHM on #Debian'
Re: T68i incorrect support of CNMI
Citando Alex Judd <[EMAIL PROTECTED]>: > Yes - it does look like it's well and truly broken. > > However... it does work fine if it's configured with sim-buffering so > perhaps we change the default settings for the T68i to be that. At least > that way it works? Yes please, just edit modems.conf and send us the patch. If you want, you can even add comment lines "# 3,1,2,3 this should work because manual says so but this stupid mobile simply rejects us". ;) fortunatly, it's a great "small mobile" to carry inside your pocket and feed your pda with gprs and bluetooth - If i have 3 timeslots available, t68 will deliver me the full 43.2kbps :)) but for calling or messaging, forget > Alex > > - Original Message - > From: "Bruno Rodrigues" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, February 14, 2003 8:42 PM > Subject: Re: T68i incorrect support of CNMI > > > > Citando Alex Judd <[EMAIL PROTECTED]>: > > > > > RE: [Fwd: Removing WTP-SAR limit 32768 B]Anyone else noticed that the > T68i > > > appears to break the rules of the CNMI command in smsc_at2.c? > > > > > > AT+CNMI=? > > > +CNMI: (3),(0,1,3),(0,2),(0),(0) > > > > Haven't I commented modems.conf with something like "# Ericsson T68 - > forget it" ? -- Davi / Bruno.RodriguesLitux.Org Litux.org: 09:55:17 up 87 days, 11:10, 7 users, load average: 0.06, 0.03, 0.00 '"World domination. Fast" (By Linus Torvalds)'
Re: Kannel wap limits ?
> I'm trying to force kannel to let a mobile download realplayer.sis file > (584.720bytes) through it. > I know that I'm crazy to try it, but I just need to know the limits of kannel > and see if we can do better than CMG ;) we definetly sould do better :) Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: DCS and PID handling in Kannel
On Tue, 2003-02-18 at 07:06, Bruno Rodrigues wrote: > PID value is passed thru from smsbox http interface to smsc connection > and kannel doesn't mind with it. > DCS is used internally in kannel and thus should be "controled" by it. > That's why we have seperated fields to build DCS at the end. > For example, if you set UDH and don't set coding, kannel will > automatically (legacy behaviour) select 8 bit text and adapt your text > data to it. Which is severely broken. Consider EMS messages, which have (e.g.) a bitmap in the header and 7-bit text in the remaining space in the user data field. Interpretation of user data is solely a function of DCS, that's why it's there. > Using coding, mclass, mwi and alt-dcs, every dcs combination can be > done, if smsc modules supports it of course. EMI2 and AT2 surelly > supports it. > > I can make a table in userguide with it's combinations to describe it. > You will discover that the coding scheme cannot be completely reconstructed from the data Kannel sends. DCS 0xF5 should be equivalent to DCS 0x15, but there's no guarantee a mobile phone (or some third-party app for a smartphone) will be so smart as to recognize the equivalence. There's also a matter of principle -- if you decide (for instance) to create a file system that has a case-insensitive namespace, is it better to force filenames to be ALL CAPS or preserve the filename given by the user? > I vote -1 for having a DCS field outside smsbox and I don't see a > requirement to split pid, but that's only MHO :) > I made these suggestions and sent an SMPP patch because I encountered problems trying to get Kannel to handle MO messages correctly. One of these problems is that it screws up DCS. The "-1" doesn't suprise me at all. It's a pity, though. David WHITE CONNECT AUSTRIA
RE: Kannel wap limits ?
Title: RE: Kannel wap limits ?
I have to fix wpt layer to do not panic if psn is going to be > 255
but this is a limit of SAR and can be overcome with ESAR.
Does 3650 support ESAR? I don't have such a phone to check it by myself
> -Original Message-
> From: Bruno Rodrigues [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 18, 2003 5:27 AM
> To: [EMAIL PROTECTED]
> Subject: Kannel wap limits ?
>
>
> Hi.
>
> I'm trying to force kannel to let a mobile download
> realplayer.sis file
> (584.720bytes) through it.
> I know that I'm crazy to try it, but I just need to know the
> limits of kannel
> and see if we can do better than CMG ;)
>
> First problem is that Nokia 3650 sends a SDU of 357.000 bytes
> and kannel simply
> refuses to send the file back.
> It's a good start relativly to CMG, because I will get a
> reply quickly (altough
> it could be a nice wap page saying something meanfull instead
> of a rude gateway
> error). CMG tries to do something and only breaks after
> something like 10 seconds.
>
> Then I've removed SDU checks from kannel >:), adding a "0 &&"
> gw/wap-appl.c line 654:
> /*
> * If the response is too large to be sent to the client,
> * suppress it and inform the client.
> */
> if (0 && octstr_len(content.body) > sdu_size && sdu_size > 0) {
>
> Now the mobile goes having fun downloading the file:
> Kannel logs starts with a:
> 2003-02-18 02:52:12 [5] DEBUG: WTP: begin_sar_result(): data
> len = 584867
>
> then a,
> 2003-02-18 02:52:14 [5] DEBUG: WTP: continue_sar_result():
> lsegm=2, nsegm=1015,
> csegm=-1
>
> until it gets to:
> 2003-02-18 02:54:24 [5] DEBUG: WTP: resp_machine 2, state
> RESULT_RESP_WAIT,
> event RcvAck.
> 2003-02-18 02:54:24 [5] DEBUG: WTP: continue_sar_result(): lsegm=254,
> nsegm=1015, csegm=251
> 2003-02-18 02:54:24 [5] DEBUG: WTP: dispath_to_wdp(): psn = 255
> 2003-02-18 02:54:24 [5] PANIC: gwlib/octstr.c:1677:
> octstr_set_bits: Assertion
> `value <= mask' failed.
>
> This means what ? are we assuming that psn is a unsigned byte ?
>
> To reach the Nokia3650 SDU, we would need to send 620
> "psn"'s, so I think
> something is broken in kannel. :(
>
>
> Any idea ?
>
>
>
>
> --
> Davi / Bruno.RodriguesLitux.Org
> Litux.org: 02:58:48 up 87 days, 4:14, 10 users, load
> average: 0.18, 0.10, 0.05
> 'OK, enough hype.
> -- Larry Wall in the perl man page'
>
RE: Kannel wap limits ?
> This means what ? are we assuming that psn is a unsigned byte ? > > To reach the Nokia3650 SDU, we would need to send 620 > "psn"'s, so I think > something is broken in kannel. :( > > > Any idea ? PSN is unsigned byte according to WAP specifications. To send larger number of packets you need ESAR feature in Kannel, but this is not yet implemented I'm afraid :-(. Damir
