Hello Everyone,
I am struggling with this problem for almost two weeks now, please I need
help, could someone figure out what is wrong here?
http://dect.osmocom.org/trac/dect/ticket/6
Thanks,
Domonkos Tomcsanyi
Hi Patrick
The scenario that I find most attractive is 2, can associate with a PC
with a card pcmcia to any type of FP either an asterisk or any other
manufacturer's base seems exciting.
I'll be anxious to try any new developments that take place in the
software, if you think that the slides can be useful for the web I can
send examples to illustrate the sources, since it is a topic largely
unknown in Spain and could help. Anything that can help you be an honor
for me.
Thank you very much for your work
Heavy greetings
On Sat, 23 Oct 2010 18:29:29 +0200, Patrick McHardy wrote:
> Am 21.10.2010 12:37, schrieb Oscar Soriano Riera:
>> Hi Patrick
>>
>> I have a question about the architecture and software development
>> today.
>> I've prepared an image(Dect-labv1.0.jpg) on the 3 scenarios in which
>> I
>> work, basically would be the following:
>>
>> 1) DECT Terminals Connected to Asterisk
>> This lab works perfectly, with the latest versions that have posted
>> until today.
>>
>> 2) Connect a PC card pcmcia Dosh & Amand like a Portable Part (PP)
>> You can use a pc with a pcmcia and associate as a PP to asterisk
>> server-Dect for make calls with other users?, I have questions /
>> problems as a register from the laptop to asterix
>>
>> 3) Linking two Asterisk servers using the DECT protocol to share
>> calls
>> between PBXs
>>
>> It is possible this configuration?
>
> Both 2) and 3) certainly can be done, but are not implemented - its
> basically the same thing, in scenario 3) one of the asterisk servers
> would pose as PP. It shouldn't be that much work to add support for
> this to the asterisk dect channel plugin, I'd estimate a few hours.
Am 17.10.2010 02:30, schrieb Oscar Soriano Riera:
> Hi
> I would like to install the lasted libdect modification , but on the make
> step i see a posible problem with a pointer
>
> root@DECT:/usr/src/libdect# make
> SUBDIR include/
> SUBDIR src/
> CC src/raw.c
> src/raw.c: In function ‘dect_raw_event’:
> src/raw.c:140: error: ‘slot’ undeclared (first use in this function)
> src/raw.c:140: error: (Each undeclared identifier is reported only once
> src/raw.c:140: error: for each function it appears in.)
> src/raw.c:142: warning: passing argument 3 of ‘dh->ops->raw_ops->raw_rcv’
> makes integer from pointer without a cast
> src/raw.c:142: note: expected ‘uint8_t’ but argument is of type ‘struct
> dect_msg_buf *’
> src/raw.c:142: error: too few arguments to function
> ‘dh->ops->raw_ops->raw_rcv’
> make[1]: *** [src/raw.o] Error 1
> make: *** [src] Error 2
Fixed now in git.
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.
I'm currently trying to reverse engineer the proprietary Siemens
protocol carried in <<ESCAPE-TO-PROPRIETARY>> information elements
in order to better support the many features that Siemens implements
in a proprietary fashion instead of following the standardized
methods (see http://dect.osmocom.org/trac/dect/wiki/Siemens for more
information).
Since I only own two different kinds of telephones, it would be useful
to get some more data. What I'm currently looking for is the debug
output from the asterisk channel driver (with "dect set debug on") for
the initial pairing, location registration and a call. If people could
send me that it would be much appreciated. Please also include the
telephone type and CC the linux-dect list.
I'll also release a program to capture and decode NWK layer
dumps between telephones and non-local FPs similar to the traces at
http://dect.osmocom.org/trac/dect/wiki/Siemens#Traces in one or
two weeks, I'll post an update then.
Thanks!
Am 15.10.2010 01:48, schrieb Oscar Soriano Riera:
> Hi PAtrick
> I can see some errors in debug mode on asterisk problems with the audio:
>
> [Oct 15 01:17:05] WARNING[19906]: file.c:1396 ast_format_str_reduce:
> ignoring unknown format 'wav49'
> [Oct 15 01:17:05] WARNING[19906]: file.c:1396 ast_format_str_reduce:
> ignoring unknown format 'gsm'
> [Oct 15 01:17:05] WARNING[19906]: file.c:1396 ast_format_str_reduce:
> ignoring unknown format 'wav'
> [Oct 15 01:17:05] WARNING[19906]: file.c:1426 ast_format_str_reduce: no
> known formats found in format list (wav49|gsm|wav)
> [Oct 15 01:17:05] ERROR[19906]: app_voicemail.c:11702 load_config: Error
> processing format string, defaulting to format 'wav'
>
>
> I find in issues of Asterisk and i thing that this version is affected
>
> https://issues.asterisk.org/view.php?id=17709
>
> I download the patch and solved the problem:
>
> wget
> 'https://issues.asterisk.org/file_download.php?file_id=26764&type=bug' -O -
> | patch -p0
Yeah, its not related to the DECT channel driver, but my asterisk
version is slightly outdated. Unfortunately I can't resync easily
without loosing the history since my master tree got corrupted a
while ago due to filesystem errors. I'll probably try again to
merge my tree with a fresh SVN import, if that doesn't work I
guess I'll have to throw the history away.
BTW, please use the linux-dect list (CCed) for anything related
to my stack.