**>From: J�rgen Thomsen <[EMAIL PROTECTED]> **>To: devel <[email protected]> **>Subject: Re: Kannel is suffering **>Date: Sat, 12 Feb 2005 01:23:24 +0100 **>In-Reply-To: <[EMAIL PROTECTED]> **> **>Stipe Tolj, **> **>>So, how about giving a concret example on how you would do certain issues? **>Don't BS me. I have provided several patches to Kannel, and I did submit a working patch **>for a feature related to this issue, but about 2? hour after my submission, you flatly **>turned it down. Not much time for deeper contemplation there. **> **>And, please, don't drag the discussion here down to whether that small patch is good or **>not. More important issues are at stake. They go way beyond the rejection of a single **>patch ie. should Kannel be a 'lowest common denominator' software or should it be a **>framework to handle several protocols as 'abstracted' as possible but with provisions **>for handling all aspects of a specific protocol. **> **>In my view the latter is a much more useful and challenging point of view.
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? 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? See ya... d.c.
