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>
