Re: SMPP Optional Parameters implementation

Alejandro Guerrieri wrote:

> _That's_ the whole point, yes!
> 
> A few additional questions:
> 
> * Your patch allows to send and receive meta data, or only send?

it works both ways...

> * How this interact with sqlbox? I can make the changes myself if
> neccesary, but I don't want to duplicate work.

sqlbox is not a part of official kannel, so you have to write patch yourself
and post it to devel@ :) But please wait until I post the patch...

> 
> Regards,
> 
> Alejandro
> 
> On 8/3/07, Alexander Malysh <[email protected]> wrote:
>> On Freitag, 3. August 2007, Alejandro Guerrieri wrote:
>> > Wow, great news!
>> >
>> > This will ever make it into the main tree, or it will be kept as a
>> > separate patch?
>>
>> I hope it will make it into main tree. With this patch nobody will have
>> to modify kannel sources for SMPP TLVs and we will have e.g. Mblox
>> support out of the box :)
>>
>> >
>> > I think it's a great addition for everyone using SMPP, since many
>> > operators/aggregators are using optional parameters as a mean of
>> > adding functionality to their SMPP implementations. Having this as a
>> > functional part in Kannel can make it a better option for many people
>> > IMHO (having to modify the source code to connect to an
>> > operator/aggregator may not be feasible for some users).
>> >
>> > Great job, thanks! I can't wait to see it in action.
>> >
>> > Regards,
>> >
>> > Alejandro
>> >
>> > On 8/3/07, Alexander Malysh <[email protected]> wrote:
>> > > Hi,
>> > >
>> > > I already done it. Patch is in my tree should just rebase it against
>> > > kannel.org.
>> > >
>> > > In my patch we have...
>> > >
>> > >         In the config
>> > > group = smpp-tlv
>> > > name = some-name
>> > > tag = 0x1601
>> > > type = integer|nulterminated|octetstring
>> > > length = 4
>> > >
>> > > Then in the msg struct I added meta_data field that can contain any
>> > > parameters not only for smpp. meta_data is formated as follows:
>> > >         meta_data = ?group?key=value&key1=value1?smpp?some-name=ABC
>> > > then SMPP module just set all TLVs that can be found in the smpp
>> > > group of meta_data.
>> > >
>> > > With this approach it's possible to use this generic interface to put
>> > > some extra functionality into any SMSC module.
>> > >
>> > > I will rebase my patch and post it (hope todo it this weekend), just
>> > > be a bit patient.
>> > >
>> > > Alejandro Guerrieri wrote:
>> > > > Dear List,
>> > > >
>> > > > A fellow member of this list and me are planning to implement a
>> > > > generic way to send/receive TLV's (SMPP Optional Parameters) to
>> > > > Kannel. The objective of our approach will be to develop a high
>> > > > level abstraction of the TLV structure in order to allow Kannel to
>> > > > send and recognize specific TLV's just by writing special
>> > > > configuration directives on it's conf files.
>> > > >
>> > > > The idea has matured to the point of writing fictitious (as of now)
>> > > > configuration directives and communication parameters.
>> > > >
>> > > > As we see it, the configuration for optional parameters should go
>> > > > into the core group. An "allow" directive could be put in place to
>> > > > limit the functionality of specific parameters to specific smpp
>> > > > connections.
>> > > >
>> > > > For example:
>> > > >
>> > > > group = smpp-optional
>> > > > group-id = msg_ticket
>> > > > allowed-smsc-id = "smsc1;smsc2"
>> > > > tlv-tag = 0x1404
>> > > > tlv-length = 15
>> > > > tlv-type = string
>> > > >
>> > > > group = smpp-optional
>> > > > group-id = msg_custom_param
>> > > > allowed-smsc-id = "smsc1;smsc2"
>> > > > tlv-tag = 0x14FF
>> > > > tlv-length = 2
>> > > > tlv-type = integer
>> > > >
>> > > > This would define two TLV's, one called "msg_ticket" at address
>> > > > 0x1404 carrying a OctStr of 15 bytes in lenght. The second would be
>> > > > called "msg_custom_param" at address 0x14FF carrying an integer of
>> > > > 2 bytes. Both parameters only exists on the context of smpp
>> > > > connections named "smsc1" and "smsc2".
>> > > >
>> > > > To avoid clashing with other modules, the parameters would be
>> > > > "serialized" into a single parameter to be sent/received by the
>> > > > HTTP/XML and even SQLBOX interface (with minor modifications). The
>> > > > syntax would be as follows:
>> > > >
>> > > > To send:
>> > >
>> > >
http://myhost:port/cgi-bin/sendsms?....&smpp_optional=msg_ticket=xxxxxxxx
>> > >&amp;msg_custom_param=123
>> > >
>> > > > Note: the tag-value combination would have to be urlencoded of
>> > > > course.
>> > > >
>> > > > To receive:
>> > > >
>> > > > We could use any free letter (maybe "v" ?) to receive the tag-value
>> > > > pairs, also urlencoded.
>> > > >
>> > > > So if we configure post-url with "http://myhost/myapp?params=%v
>> > > >
>> > > > We would receive a post with "params" (or any name we've chosen)
>> > > > loaded with:
>> > > >
>> > > > "msg_ticket=xxxxxxx&amp;msg_custom_param=321" (It would also be
>> > > > urlencoded).
>> > > >
>> > > > Any opinions or suggestions from the core Kannel mantainers and
>> > > > fellow community members are welcome.
>> > > >
>> > > > Thank you in advance,
>> > >
>> > > --
>> > > Thanks,
>> > > Alex
>>
>>
>> --
>> Thanks,
>> Alex
>>
> 
> 

-- 
Thanks,
Alex