Hi,
I'm currently working on ISDN (E1/T1/BRI) support, D-channel protocol wise and
hardware wise in connection to FreeSwitch. I'm also adding support for analog
phone adapters through the same API. I promised to Mike Jerris several times
I would do something, but then the time ran away ... This week I put down
several hours integrating the ISDN support in FreeSwitch with the ISDN
support in ISDN4BSD, which should end up with a unified BSD-licensed OpenZap
code base.
If you are interested in giving some feedback you can check out the following
files:
svn --username anonsvn --password anonsvn \
checkout svn://svn.turbocat.net/i4b/trunk/openzap.hps
The files that are there are mainly for inter-process communication, and have
been constructed in a way that allows easy porting to other platforms. In
general sockets can be used for this on other UNIX compatible systems as a
fallback mechanism where the optimised kernel mechanism is not present.
The core (FreeBSD kernel module): Handles routing and broadcasting.
The client (FreeBSD library): Dumb node sending and receiving messages.
What I plan next is to implement a set of nodes, like [ISDN] controller-
Q921- and Q931- node. Nodes have pre-defined address ranges which they are
listening to. Hence I already have a DSS1 stack, splitting it up into using
message based communication should not be a very big task.
Then you have the application, like FreeSwitch being a node aswell picking up
broadcast events, which are mostly incoming calls from Q931 and making
outgoing calls.
Messages have been split into two categories: Important-frames and
Unimportant-frames. I-Frames gets to use 64 queue entries before getting
dropped. U-Frames gets to use only 32 queue entries before getting dropped.
These numbers have not been tuned yet.
Also I have thought through message timing. In bigger systems I see that it is
required to dither messages in time. On cannot simply receive 30x400 bytes on
an E1 and burst it into the system, because the message queues will overflow
pretty quickly. Instead the interrupt rate of the hardware needs to be
increased so that 400 bytes are received in "1/30 * interval" fashion. This
will generally improve the system and load-balance in time.
The generic Message Header looks like this:
/* NOTE: All fields are little endian */
struct zap_hdr {
uint8_t dwDstNode[4]; /* Destination Node */
uint8_t dwSrcNode[4]; /* Source Node */
uint8_t wCommand[2]; /* Command Number */
uint8_t wMsgNum[2]; /* Message Number */
uint8_t bReserved[4]; /* Reserved bytes */
};
If you have access to ISDN testing equipment and would like to help test the
non-EuroISDN variants of my upcoming ISDN implementation, please let me know.
I expect to have something up and running within the next month, hopefully not
running out of time this time :-)
--HPS
_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
