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
-------------------------------------------------------------------
Index: doc/userguide/userguide.xml
===================================================================
--- doc/userguide/userguide.xml (revision 5090)
+++ doc/userguide/userguide.xml (working copy)
@@ -3639,6 +3639,15 @@
Defaults to 3.
</entry></row>
+ <row><entry><literal>max-sms-octets</literal></entry>
+ <entry><literal>number</literal></entry>
+ <entry valign="bottom">
+ If interface version is SMPP v3.4 or higher, and a value larger then
+ 254 is set for this config directive, then large messages will be
transported in
+ one PDU via the <literal>submit_sm.message_payload</literal> field
instead of
+ several PDUs using the <literal>submit_sm.short_message</literal>
field.
+ </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)
@@ -117,6 +117,7 @@
#define SMPP_DEFAULT_WAITACK 60
#define SMPP_DEFAULT_SHUTDOWN_TIMEOUT 30
#define SMPP_DEFAULT_PORT 2775
+#define SMPP_MAX_SHORT_MESSAGE 254
/*
@@ -996,6 +997,16 @@
pdu->u.submit_sm.sm_length = octstr_len(pdu->u.submit_sm.short_message);
/*
+ * Sanity check of .short_message, in case 'max-sms-octets' was set to a
+ * larger value, then we may need to move the payload to .message_payload.
+ */
+ if (pdu->u.submit_sm.sm_length > SMPP_MAX_SHORT_MESSAGE && smpp->version >
0x33) {
+ 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
* Note: we always send in UTC and just define "Time Difference" as 00 and
@@ -2478,6 +2489,10 @@
/* convert decimal to BCD */
version = ((version / 10) << 4) + (version % 10);
+ /* check if 'max-sms-octets' is allowed based on SMPP version used. */
+ if (conn->max_sms_octets > MAX_SMS_OCTETS && version <
SMPP_DEFAULT_VERSION)
+ panic(0, "SMPP: Configuration can't set 'max-sms-octets' 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;
