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

[Jan Berger]

What is the "Optimized Kernel Mechanism"  you reffer to?
 
Jan> From: hselasky at c2i.net> To: freeswitch-dev at 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 at lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev> http://www.freeswitch.org
_________________________________________________________________
Show them the way! Add maps and directions to your party invites. 
http://www.microsoft.com/windows/windowslive/events.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090130/d553cf0c/attachment.html