[PATCH] Optional usage of submit_sm.message_payload for large MTs

[Stipe Tolj]

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
-------------------------------------------------------------------

[h***@ecommunicate.biz]

+1 this is a useful addition.
Thanks Stipe.

Date: Tue, 20 May 2014 17:44:04 +0200
From: Stipe Tolj <***@kannel.org>
To: "***@kannel.org" <***@kannel.org>
Subject: [PATCH] Optional usage of submit_sm.message_payload for large
MTs
Message-ID: <***@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>

[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.

Alex

Post by Stipe Tolj
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.
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>

[Kyriacos/Netsmart]

Hi All,

Currently though this can be easily handled on the application side,
outside of kannel itself, if I understood the intent correctly. Although
the suggestions below are I assume valid, is there enough use case to
need this in code?

Kyriacos

Post by 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.
Alex

Post by Stipe Tolj
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.
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>

--
Kyriacos Sakkas
Development Team
Netsmart
Tel: + 357 22 452565
Fax: + 357 22 452566
Email: ***@netsmart.com.cy
http://www.netsmart.com.cy

Taking Business to a New Level!

** Confidentiality Notice: The information contained in this email
message may be privileged, confidential and protected from disclosure.
If you are not the intended recipient, any dissemination, distribution,
or copying of this email message is strictly prohibited.
If you think that you have received this email message in error, please
email the sender at ***@netsmart.com.cy **

[Stipe Tolj]

Post by 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
-------------------------------------------------------------------

[Alexander Malysh]

Hi Stipe,

this chunk -1:

+ /* 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;

I would prefer that user set max-sms-octets in the config because this will break many installations and this is even wrong
because if user set max-sms-octets in the config you just overwrite it here and user has no chance to change it.

Alex

Post by Stipe Tolj

Post by 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.

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
-------------------------------------------------------------------
<smpp-message-payload.v2.diff>

[Stipe Tolj]

Post by Alexander Malysh
Hi Stipe,
+ /* 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;
I would prefer that user set max-sms-octets in the config because this will break many installations and this is even wrong
because if user set max-sms-octets in the config you just overwrite it here and user has no chance to change it.

ok, the last reason seems reasonable for me, I agree.

But if we don't set the max_sms_octets, then the abstraction layer will
pre-chunk any SMS into GSM PDU length sized chunks and hence in the SMPP
layer we can't send anything bigger then 140 octets that uses
.message_payload. This doesn't make sense either.

So, we would need to check IF conn->max_sms_octets != default, then we
know user has individually set an alternative value and stick to that
value, otherwise we DO set to 64K for the sake of getting the full
length supported of the PDU field.

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
-------------------------------------------------------------------

[Stipe Tolj]

ok, here we go again, with corresponding change:

+ /* If we want message_payload to be used as PDU field, and no
'max-sms-octets'
+ * is given, then we can switch to use a max-sms-octets size of 64K
to support
+ * the full size of the message_payload field. */
+ if (cfg_get_bool(&smpp->message_payload, grp,
octstr_imm("message-payload")) == 1 &&
+ cfg_get_integer(&conn->max_sms_octets, grp,
octstr_imm("max-sms-octets")) == -1)
+ conn->max_sms_octets = 65536;

in order to switch only to the 64K size IF no other value has been given
to be respected due to user configuration.

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
-------------------------------------------------------------------

[Alexander Malysh]

Hi,

+ if (cfg_get_bool(&smpp->message_payload, grp, octstr_imm("message-payload")) == 1 &&
+ cfg_get_integer(&conn->max_sms_octets, grp, octstr_imm("max-sms-octets")) == -1)
+ conn->max_sms_octets = 65536;

max-sms-octets is SMSC group option and is already set in SMSC layer for _all_ smsc modules.
I don't think we need to set 64K here because it should be set by the user explicitly because SMSCs
that I saw and that require message_payload accepted only 140 Octets.

IMHO, the user has to set both (1) use message_payload and (2) max-sms-octets depending on the
infos provided by SMSC operator.

Alex

+ /* If we want message_payload to be used as PDU field, and no 'max-sms-octets'
+ * is given, then we can switch to use a max-sms-octets size of 64K to support
+ * the full size of the message_payload field. */
+ if (cfg_get_bool(&smpp->message_payload, grp, octstr_imm("message-payload")) == 1 &&
+ cfg_get_integer(&conn->max_sms_octets, grp, octstr_imm("max-sms-octets")) == -1)
+ conn->max_sms_octets = 65536;
in order to switch only to the 64K size IF no other value has been given to be respected due to user configuration.
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.v3.diff>