Re: [PATCH] [CFT] [RFC] [WIP] Next series

Paul,

Unfortunately I'm not coder, but I can help you by testing your 
implementations against real traffic. 
I think it will be great, if coders like you will have dedicated repository 
based on cvs tree and keep your patchsets up-to-date, just like in linux 
kernel tree (-aa, -mm and so on series). Of coarse if you willing to maintain 
such a tree.
In that case, it will be easer to implement new features, test throughly and 
merge with official tree in case developers vote for it.
Just one little example, how it's difficult to request feature in official 
tree:
Two years ago, when I started using kannel hardly, I discovered, that my SMPP 
provider has DLR handling based on TLV's. I requested that feature in the 
list. Unfortunately, for some reasons developers decided to not implement 
such DLR handling. But there were few guys (one of them Nisan Bloch), who 
provided patch, but it never accepted to official tree (Many thanks to 
Alexander Malysh, who finally did the job regarding TLVs).
So, I think developers should talk about such possibility, it will easer life 
for users with non-standard (in the smpp case, there is no standard DLR 
handling. It's up to provider) features.

Please, let's discuss.
Many thanks, 

-- 
David Chkhartishvili
MagtiCom Ltd.
Tel: +995 99 182418

On Saturday 08 May 2004 16:52, Paul P Komkoff Jr wrote:
> Replying to David Chkhartishvili:
> > I also would like mention, that current radius implementetion not always
> > working properly. Sometimes we get incorrect mappings and as a result
> > clients get other clients MSISDN's. That situation is fatal when services
> > are dependent on MSIDN, for example MMS.
> > From my point of view, Paul's implementetion is more cleaner. But there
> > is also disadvantage: hard dependency to FreeRadius.
>
> I think we can overcome this.
> Interface is very simple (actually, we are storing map
> framed-ip-address->msisdn, thats all) and I think I can write module
> for any major free radius implementation floating around which allows
> modules.
>
> But this approach still have problems. Both wapboxes and radius need
> coherent access to same filesystem. In most cases it can be achieved
> only on locally mounted fs. (hp-ux is non-coherent even on local fs,
> but I need to check berkeley db sources to see are they actually
> worked around this).
>
> Another solution would be - to write some kind of network service,
> maybe - add it to bearerbox, which will relay to many wapboxes,
> probably on different machines, required msisdn information - by
> request from wapbox or even unconditionally with each datagram.
>
> I hope I will continue to work in this direction just after I will do
> some more testing on different platforms and under real-world load :)