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 <[email protected]>:

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