Davy Chan wrote:
Ok. Let's break down the current situation.
- SMPP and EMI both have extra parameters or options that can be passed back and forth between the SMSC Servers and the SMSC clients. - The extra parameters are proprietary to the SMPP or EMI specifications and cannot be abstracted to be used by other SMSC client implementation. - Kannel development Standard Operation Procedure is to keep SMSC specific features and capabilities out of the abstract representation of an SMS as declared by the SMS Msg structure. - Several people have expressed interest in exposing the SMSC specific capabilities so as to extract or inject pertinent information (like user_message_reference and network_error_code from SMPP). - How to provide the capability without breaking SOP?
good summary aggregation here Davy.
My proposed solution: Overload the billing info (binfo) with the SMSC specific content.
- For an MO or DLR SMS, have each SMSC client deal with the packaging of the info into a hexadecimal string. Then, have the application depending on the info decode it. The optional parameter TLV (SMPP) or XSer TTLLDD (EMI) can be converted to their hexadecimal equivalent and forwarded to the application using the %B escape code. - For MT SMS, an application can embed the hexadecimal representatiion of the TLV or TTLLDD into the binfo. The SMSC client code will extract out the info and put it into the proprietary formats before submitting the SMS to the SMSC.
For those of us that do not need to have the extra stuff in the binfo, have a configuration directive in the "group = smsc" that "overload_binfo = false" to indicate to the SMSC client code not to handle the extra stuff.
Opinions?
yep, we do this here at Wapme too (with binfo field overloading).
Actually it is a solution. But, in my personaly opinion it could be done "somehow" better. (where I still don't know explicetly how). But the proposed way is already in use here, and actually it "works".
This means we have one "magic" field (binfo) (or then even rename it appropriately) that transports all the optional parameter values from application layer side to smsc module.
Any more suggestions towards this?
Stipe
mailto:stolj_{at}_wapme.de ------------------------------------------------------------------- Wapme Systems AG
Vogelsanger Weg 80 40470 D�sseldorf, NRW, Germany
phone: +49.211.74845.0 fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de http://www.wapme-systems.de/ -------------------------------------------------------------------
