Asterisk DECT channel driver

I've written an asterisk DECT channel driver as part of an entire open source DECT stack available at http://dect.osmocom.org, which is attached to this email. The patch is not meant for merging at this time, there's still quite a bit of work to by done, but its in a good enough state that some review, especially of the interactions with asterisk, would be very welcome. The channel driver implements a DECT FP (Fixed Part, aka basestation), currently supporting G.726 audio and a few supplementary features like text messages and user authentication. Telephones can register with the FP using a procedure called "access rights requests", during which an authentication key and an extension is allocated for the telephone. When the telephone is active and in range to the FP, it performs a procedure called "location registration" (probably known from GSM) to announce it is ready to receive calls. The extension is then registered in the dialplan in a special context for the Dial() application in order to support completely dynamic setups where the amount of telephones is not known in advance. It is of course also possible to manually define dialplan rules for the telephones. The telephone specific subscription data (extension, keys, capabilities, ...) are stored in the ast_db and read again on startup. This part is not particulary pretty due to the inflexibility of ast_db(), specifically it needs various keys associated with each telephone, which are stored separately and associated again through the database path (/dect/<IPEI>/...). The ast_realtime architecture unfortunately also doesn't seem to be suitable for this since it appears to be lacking a way to iterate over data or query for multiple entries. Call connection can work in two ways: - when the phone supplies an existing extension during call setup, the call is immediately connected. - otherwise the call is placed in "OVERLAP SENDING" state and for each dialed digit, an extension lookup is performed and the call is connected as soon as an existing extension is dialed. I think that should be about everything where the driver's behaviour diverges from other drivers, the remaining parts should be pretty much self-explanatory. Comments and review welcome.