Re: [RFC] variable sms_split() length per SMSCConn

Andreas Fink schrieb:
> The known GSM SMSC's dont accept longer SMS because the GSM 
> infrastructure does not allow longer SMS than the 140 octets.
> some CDMA SMSC's might accept longer SMS and some GSM SMSc's might split 
> it on their side but so far I have not seen any really supporting it or 
> at least not with asking a fortune to the operator for a useless feature.
> 
> I don't see a real need for this.

I do. From an achitecure point of view we (kannel) is beyond the signaling 
layer. So taking it strictly, we COULD use protocols towards SMSC that allow 
long messages to be passed in one PDU, as SMPP per spec does. Or consider HTTP 
as a simple example.

I understand that most vendors leaverage the underlying signaling limits (140 
octets per GSM SMS message) to the SMSC clients, but this is actually not 
conceptualls correct.

What I want is to give the user an "option" to define the max octets we are 
allowed to pass to the SMSC. Which SHOULD BE allowed, hence we're still above 
the signaling layer.

Think of Kannel instance concatenation as another example:

client <-> smsbox(2) <-> bearerbox(2)[smsc_http] <-> smsbox(1) <-> 
bearerbox(1)[smsc_smpp] <-> SMSC

so if a client injects a large msg at the left hand side, this would result in a 
sms_split() segmentation within bearerbox(2), even while we know that smsbox(1) 
could handle the "whole message".

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