From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale
Sent: Tuesday, February 05, 2008 6:19 AM
To: freeswitch-dev@lists.freeswitch.org
Subject: Re: [Freeswitch-dev] TDM questions: OZ, signaling on digital spans

It's a trickle-up methodology.

The low level driver interprets the voltage change
or the bits flipping or whatever and turns it into
driver specific events which in turn are changed
into openzap specific events by the zap_<whatver>.c
zap_zt.c, zap_pika.c etc.  when you apply a signaling
to a span in the mod_openzap config the signal specific
module will monitor the span for these events and decide
what they mean in reference to whatever signaling type
it represents.

 Okay, so the driver-specific events get captured and translated… Makes sense.  Curious: does this all happen at OSI layer 2?

I don't know exactly how it works.

so

voltage changes on zaptel card

zaptel specific ring event is caught by zap_zt.c

openzap ring event is queued on the channel and
event data flag is set on the span.

zap_analog.c sees the event data flag and gets the
ring event on the channel

ring event is sent up to mod_openzap who starts a channel
in freeswitch.


so implementing another sig type like e&m just requires
zap_em.c and proper interpretation of the bit shifting
events.  I belive zaptel drivers and pika
can do it but I don't know if the native sangoma can yet.

I think I get it.  Next question: on a digital span that is set up in the <analog spans> section of openzap.conf.xml – does zap_analog.c do the signal translation even though the span is technically digital?  It almost sounds like zap_analog.c is agnostic to the analog/digital nature of the span simply because it’s receiving events from the driver via openzap… Last question: if zap_analog.c is handling the translation of FXO/FXS signaling then couldn’t we almost just copy zap_analog.c to zap_em.c and then redefine the bit patterns that represent on-hook, ringing, hangup, etc.?  Or am I oversimplifying again? ;)

Yes that is more or less correct.  In fact once you took out all the analog state machine etc from zap_analog.c

zap_em.c will be rather tiny just starting calls when it gets off hook and ending them when it gets onhook.

Thanks for the explanation – I will distill this thread into it’s components and add it to the wiki when we’re done.

-MC

P.S. – the zaptel drivers do support E&M, E&M wink, etc.  I’ve used E&M with the orange splat and connected to my NEC PBX with the exact same tor2 and trunk-side T1 card.