[Freeswitch-dev] FreeSwitch + ISDN + analog phone adapters - status

[Hans Petter Selasky]

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