Re: [Kannel-Devel] Re: [Kannel-Users] Re: Config-based Optional Parameter Functionality

On Sun, 31 Jul 2005, Alejandro Guerrieri wrote:

> Peter,
> It would be great to have such a feature. However, IMHO the configuration
> parameters are a little cumbersome and could lead to problems in the future.
>
> The first thing I'd change is the ability to choose the %X (X = Letter of
> choice). It would be way to easy for people to overload an already used
> parameter (%s, %a, you know... nobody reads the docs! ;) ). Furthermore, it
> could cause problems if future versions of Kannel use that letters for
> anything else (imagine you start using %M and then Kannel developers choose
> to use %M for anything else... it would require reconfiguration of the whole
> system).
>
> So, I'd suggest a more generic approach to variable replacement, maybe a
> two-letter or letter-number, kind of %x1, %x2... %xN, being "x" one unique
> letter specially reserved for parameter passing and 1, 2, N a number defined
> on the config.

  I'm completely with you on that; users will do things to break it.  By
  moving it outside of what is used, and being able to scale (x1...x35...xN)
  you can, like you say further down, abstract the whole SMPP structure!

> I'd also propose to include an structure for the "dictionary" you've
> mentioned. It would generalise the ID:Length combination under a generic
> word. It could even be managed as a special "group".
>
> In short my (rather heavily inspired by your insights) dream config would
> look like this:
>
> group = smpp-optional
> opt-id = 1
> parameter-id = billerr_msg
> parameter-tag = 0x1404
> parameter-length = 22
>
> group = smpp-option
> opt-id = 2
> parameter-id = secret_code
> parameter-tag = 0x1533
> parameter-length = 90
> So this setup would map to %x1 and %x2.

  I love it.  We would need to consider whether the "smpp-option" would
  apply for ALL SMPP connections; if so, if the offset does NOT exist it
  would be ignored, not warned on; If not, there would need to be a way to
  tag the SMPP-option to a specific SMSC-id.

> IMHO is more generic and more readable. The "parameter-id" could be also
> get rid of and use some consctruct as
> ....&param1=xxxx&param2=yyyy"
> to avoid clashing with the system if I'm stupid enough as to set
> parameter-id to "from", "to" or any other reserved words.

  It shouldn't be too hard to come up with a list of reserved words and,
  before starting, test the config.  Then upon any upgrades, list any new
  reserved words for breaking compatibility.

  OR even better, force people to use param1..param32..paramN in the URLs,
  but in the DEBUG log use the human readable parameters.

  I think that for human-readability, the parameter-id/name should be there;
  param1 and param2, especially in the DEBUG logs, could become difficult to
  read and debug.

> In fact, this could be used to abstract the whole SMPP structure, but
> that's another story ;)

  *laugh* it could -- that's why I like it.  It future-proofs kannel for any
  SMPP changes, standard or not, without having to recompile.  In fact, this
  method MAY be able to allow people to implement a newer SMPP version
  without Kannel upgrading the code!

  So what would it take for you and I to take the horns of this project and
  get it pushed through?  I can code, but I'll need a partner or three.

Beckman

> Regards,
> On 7/31/05, Peter Beckman <[email protected]> wrote:
>>
>> Sorry to open the can of worms again...
>>
>> Stipe proposed some way of passing optional parameters between the smsbox
>> and bearerboxes. It doesn't seem there is currently a way to pass
>> parameters (offset, length, value) back and forth between the bearerbox
>> and
>> smsbox for those pesky SMSC's that want to pass interesting information
>> outside of the normal, base SMPP spec.
>>
>> Any suggestions? Not many replied back in February, and since kannel
>> doubles in power every 6 months (Beckman's Law), maybe since then someone
>> has figured out how (or submitted a patch) to handle this. Anyone?
>>
>> Beckman
>>
>> On Wed, 2 Feb 2005, Stipe Tolj wrote:
>>
>>> Peter Beckman wrote:
>>>
>>>> Dear Kannel Developers:
>>>>
>>>> I've written about this before, but I thought I would bring it up again
>>>> because I hate patching.
>>>>
>>>> Many SMSC's are starting to use the optional SMPP parameters for
>>>> information like billing issues, carrier failures, etc. Kannel really
>>>> doesn't allow for this -- it detects the parameters, but is unable to
>>>> actually turn them into some sort of passable escape code(s) via
>>>> sms-service.
>>>>
>>>> Take for example this log dump:
>>>>
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x0427)
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read
>> as 1
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x001e)
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read
>> as 29
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1402)
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read
>> as 1
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1404)
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read
>> as 22
>>>> 2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown
>>>> TLV(0x1404,0x0016,4154265420576972656c657373205365727669636573) for PDU
>>>> type (deliver_sm) received!
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1530)
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read
>> as 3
>>>> 2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown
>>>> TLV(0x1530,0x0003,504244) for PDU type (deliver_sm) received!
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1531)
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read
>> as 90
>>>> 2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown
>>>>
>> TLV(0x1531,0x005a,4e6f2050686f6e65204e756d6265723a20537562736372696265722070686f6e65206e756d62657220776173206e6f74206d617463686
>>>>
>> 56420696e2074686520515073732073797374656d206f722041575320506f7274616c20)
>>>> for PDU type (deliver_sm) received!
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1532)
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read
>> as 6
>>>> 2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown
>>>> TLV(0x1532,0x0006,2d3230313030) for PDU type (deliver_sm) received!
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter tag (0x1533)
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: Optional parameter length read
>> as 90
>>>> 2005-01-27 16:46:56 [30186] [7] ERROR: SMPP: Unknown
>>>>
>> TLV(0x1533,0x005a,4e6f2050686f6e65204e756d6265723a20537562736372696265722070686f6e65206e756d62657220776173206e6f74206d617463686
>>>>
>> 56420696e2074686520515073732073797374656d206f722041575320506f7274616c20)
>>>> for PDU type (deliver_sm) received!
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: SMPP[mysmsc]: Got PDU:
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: SMPP PDU 0xb5c9a5e0 dump:
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: type_name: deliver_sm
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: command_id: 5 = 0x00000005
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: command_status: 0 = 0x00000000
>>>> 2005-01-27 16:46:56 [30186] [7] DEBUG: sequence_number: 877 =
>> 0x0000036d
>>>> [...]
>>>>
>>>> My dream for the config file:
>>>>
>>>> group = smsbox
>>>> smsc-id = mysmsc
>>>> [...]
>>>> optparam = 0x1404:22:N:billerr_msg
>>>> optparam = 0x1530:3:M:happy_tag
>>>> optparam = 0x1531:90:K:secret_code
>>>> optparam = 0x1532:6:J:test_msg_id
>>>> optparam = 0x1533:90:L:secret_code2
>>>>
>>>> Now the following takes place:
>>>>
>>>> When an SMS arrives, it can be passed to sms-service, using %N, %M, %K,
>>>> %J and %L (assuming those are available), so I can grab them with a PHP
>>>> script and do something with them.
>>>>
>>>> When submitting an SMS to kannel, I can set the URL to:
>>>>
>>>>
>> http://localhost:13013/cgi-bin/sendsms?user=[...]&billerr_msg=you+spent+too+much&happy_tag=fun&text_msg_id=123FFF
>>>>
>>>> And kannel will modify the PDU to include the data passed and send that
>>>> to the SMSC.
>>>
>>> now, this approach does not "handle" on how you pass the SMPP specific
>>> optional parameters in the Kannel internal msg structure to smsbox.
>>>
>>> I see (and I agree) that we may have a generic way in passing SMSC
>> specific
>>> optional parameters up to the application layer and vice versa. But it
>> should
>>> be as clean as possible and transparently configurable for all SMSC
>>> protocols.
>>>
>>> Therefore we need a sort of Dict that contains key:value pairs within
>> the msg
>>> structure. Any ideas on how we could handle this? Alex?
>>>
>>> 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/
>>> -------------------------------------------------------------------
>>>
>>
>>
>> ---------------------------------------------------------------------------
>> Peter Beckman Internet Guy
>> [email protected] http://www.purplecow.com/
>>
>> ---------------------------------------------------------------------------
>>
>
>
>
> -- 
> Alejandro Guerrieri
> Magicom
> http://www.magicom-bcn.net/
>

---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
[email protected]                             http://www.purplecow.com/
---------------------------------------------------------------------------