What is the "Optimized Kernel Mechanism"  you reffer to?
 
Jan

> From: hselasky@c2i.net
> To: freeswitch-dev@lists.freeswitch.org
> Date: Fri, 30 Jan 2009 11:33:29 +0100
> Subject: [Freeswitch-dev] FreeSwitch + ISDN + analog phone adapters - status
>
> 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

---

See all the ways you can stay connected to friends and family