Wow, great news! This will ever make it into the main tree, or it will be kept as a separate patch?
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&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&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 > > > -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri
