Asterisk DECT channel driver

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/linux-dect@lists.osmocom.org/.

Patrick McHardy kaber at trash.net
Fri Oct 15 03:36:40 UTC 2010


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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ast.diff
URL: <http://lists.osmocom.org/pipermail/linux-dect/attachments/20101015/c90e3374/attachment.ksh>


More information about the linux-dect mailing list