What is the "Optimized Kernel Mechanism" you reffer to?
Jan> From: [email protected]> To: [email protected]> 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>
[email protected]>
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_______________________________________________
Freeswitch-dev mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org
