[RFC] variable sms_split() length per SMSCConn

Hi list,

a user has pushed me to the fact that we do sms_split() on all MTs we pass along 
  bearerbox's abstraction layer to the smsc module specific send callback.

The call stack is (generally):

gw/bb_boxc.c:deliver_sms_to_queue()
gw/bb_smscconn.c:smsc2_rout()
gw/smsconn.c:smscconn_send()
gw/smsconn.c:sms_split() <---- here the splitting happens.
then conn->send_msg() is called which passes to gw/smsc/smsc_foobar.c layer

I'm not sure if we could handle a "generally do no split for 140 octets (160 
septets)" logic inside here, as the sms_split() is called with MAX_SMS_OCTETS 
(140 octets) for all types of smsc modules.

Think of a smsc_http.c type implementation that will require a binary SMS (ie. 
WAP push or whatever) to be passed in 1 HTTP call. I guess we wouldn't support 
this, since sms_split() would split the MT already in the abstraction layer.

Idea:
Add a generic config directive to 'smsc' group that defines the max. allowed 
octets per smsc type.

Side effect:
In SMPP the submit_sm.short_message is allowed to be 255 octets, and even the 
TLV submit_sm.message_payload is much higher. We currently "cut" all MTs to SMPP 
SMSC. Some SMSC may support that "long" processing in one PDU call. So we could 
allow the user here to use it with the same mechanism.

Comments? Volunteers for implementation?

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