Re: [PATCH] Optional usage of submit_sm.message_payload for large MTs
Am 26.05.2014 18:59, schrieb Alexander Malysh:
Hi Stipe,
why this limit of 254? It's hard to explain for users what this mean, IMHO. I
think, the beast would be to have config switch to use
either short_message or message_payload. Another argument for simple switch
that some SMSCs expect message_payload even
for short message body.
adressing the concerns of Alex, please find here another variant of the
patchset which uses a simple boolean switch in the config group, i.e.:
group = smsc
smsc = smpp
...
message-payload = yes
...
to switch over to the use of submit_sm.mesage_payload instread of
.short_message. Messages up to 64K in size are then not segmented and
send as one PDU.
Comments, votes please.
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
---
Index: doc/userguide/userguide.xml
===
--- doc/userguide/userguide.xml (revision 5090)
+++ doc/userguide/userguide.xml (working copy)
@@ -3639,6 +3639,17 @@
Defaults to 3.
/entry/row
+ rowentryliteralmessage-payload/literal/entry
+ entryliteralboolean/literal/entry
+ entry valign=bottom
+ Optional, defines if we are using the
+ literalsubmit_sm.message_payload/literal field
+ for SMPP v3.4 or higher connections instead of the
+ literalsubmit_sm.short_message/literal field.
+ Which also means that no segmentation of SMS messages
+ is performed up to a size of 64K.
+ /entry/row
+
/tbody/tgroup/informaltable
/sect2
Index: gw/smsc/smsc_smpp.c
===
--- gw/smsc/smsc_smpp.c (revision 5090)
+++ gw/smsc/smsc_smpp.c (working copy)
@@ -173,6 +173,7 @@
long wait_ack;
int wait_ack_action;
int esm_class;
+int message_payload;
Load *load;
SMSCConn *conn;
} SMPP;
@@ -995,6 +996,13 @@
pdu-u.submit_sm.sm_length = octstr_len(pdu-u.submit_sm.short_message);
+/* Use .message_payload if configured to do so. */
+if (smpp-version 0x33 smpp-message_payload) {
+pdu-u.submit_sm.message_payload = pdu-u.submit_sm.short_message;
+pdu-u.submit_sm.short_message = NULL;
+pdu-u.submit_sm.sm_length = 0;
+}
+
/*
* check for validity and deferred settings
* were message value has higher priority then smsc config group value
@@ -2478,6 +2486,10 @@
/* convert decimal to BCD */
version = ((version / 10) 4) + (version % 10);
+/* check if 'message-payload' is allowed based on SMPP version used. */
+if (cfg_get_bool(ok, grp, octstr_imm(message-payload)) == 1 version
SMPP_DEFAULT_VERSION)
+panic(0, SMPP: Configuration can't set 'message-payload' if interface
version is v3.3.);
+
/* check for any specified priority value in range [0-5] */
if (cfg_get_integer(priority, grp, octstr_imm(priority)) == -1)
priority = SMPP_DEFAULT_PRIORITY;
@@ -2546,6 +2558,10 @@
smpp-ssl_client_certkey_file = cfg_get(grp,
octstr_imm(ssl-client-certkey-file));
#endif
+/* PDU allowed payload size is 64K, so change max SMS octet value */
+if (cfg_get_bool(smpp-message_payload, grp,
octstr_imm(message-payload)) == 1)
+conn-max_sms_octets = 65536;
+
conn-data = smpp;
conn-name = octstr_format(SMPP:%S:%d/%d:%S:%S,
host, port,
Index: gwlib/cfg.def
===
--- gwlib/cfg.def (revision 5077)
+++ gwlib/cfg.def (working copy)
@@ -373,6 +373,7 @@
OCTSTR(bind-addr-npi)
OCTSTR(service-type)
OCTSTR(esm-class)
+OCTSTR(message-payload)
OCTSTR(source-addr-autodetect)
OCTSTR(enquire-link-interval)
OCTSTR(max-pending-submits)
Re: [PATCH] Optional usage of submit_sm.message_payload for large MTs
Hi Stipe,
why this limit of 254? It's hard to explain for users what this mean, IMHO. I
think, the beast would be to have config switch to use
either short_message or message_payload. Another argument for simple switch
that some SMSCs expect message_payload even
for short message body.
Alex
Am 20.05.2014 um 17:44 schrieb Stipe Tolj st...@kannel.org:
Hi list,
at the moment there is no configurable way to have the SMPP client side
module rather use the submit_sm.message_payload field for SMPP v3.4+ sessions
and large MTs.
We'll always chop to the GSM 140 octet segment size and always use
submit_sm.short_message.
Since SMPP is in general independent from the underlying network layer (i.e.
GSM), we want to allow for PDUs that can transport larger messages in one PDU.
Please find attached a patchset that allows this, by using the existing
config directive 'max-sms-octets' in the 'group = smsc' scope. We can use it
for SMPP configuration to indicate what the maximum size of the message for
ONE PDU should be.
I.e. a config:
group = smsc
smsc = smpp
...
max-sms-octets = 32000
would use submit_sm.short_message for any content size = 254, and
submit_sm.message_payload for any content size 254. The message is
segmented to multiple PDUs of size 'max-sms-octets'.
Comments and votes for committing to SVN trunk are as always welcome.
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
---
smpp-message-payload.diff
RE: [PATCH] Optional usage of submit_sm.message_payload for large MTs
+1 this is a useful addition.
Thanks Stipe.
Date: Tue, 20 May 2014 17:44:04 +0200
From: Stipe Tolj st...@kannel.org
To: devel@kannel.org devel@kannel.org
Subject: [PATCH] Optional usage of submit_sm.message_payload for large
MTs
Message-ID: 537b7844.9000...@kannel.org
Content-Type: text/plain; charset=iso-8859-15; Format=flowed
Hi list,
at the moment there is no configurable way to have the SMPP client side
module rather use the submit_sm.message_payload field for SMPP v3.4+
sessions and large MTs.
We'll always chop to the GSM 140 octet segment size and always use
submit_sm.short_message.
Since SMPP is in general independent from the underlying network layer (i.e.
GSM), we want to allow for PDUs that can transport larger messages in one
PDU.
Please find attached a patchset that allows this, by using the existing
config directive 'max-sms-octets' in the 'group = smsc' scope. We can use it
for SMPP configuration to indicate what the maximum size of the message for
ONE PDU should be.
I.e. a config:
group = smsc
smsc = smpp
...
max-sms-octets = 32000
would use submit_sm.short_message for any content size = 254, and
submit_sm.message_payload for any content size 254. The message is
segmented to multiple PDUs of size 'max-sms-octets'.
Comments and votes for committing to SVN trunk are as always welcome.
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
---
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: smpp-message-payload.diff
URL:
http://www.kannel.org/pipermail/devel/attachments/20140520/90aa9550/attachm
ent-0001.ksh
