[Asterisk-Dev] ztcfg-dude?

[Mark Abene]

E&M with SIG_FEATB works fine, but isn't what I want.  Modern E&M is 4-wire
supervision over digital, whereas I'm after old-style SF supervision with
2600Hz.
So, I have some new results based on my more recent experiments with this...
SF trunk supervision does in fact work, and I discovered this by trying 
"signalling=sf" in zapata.conf.  This resulted in SF supervision (which I have
set to 2600Hz in /etc/zaptel.conf), with DTMF signalling.  Of course I want
MF signalling, not DTMF, so it was a simple matter of patching 
channels/chan_zap.c for SIG_SF to use MF instead.  This was instead of tracking
down why SIG_SF_FEATB is messed up.  What it amounts to, is that the chan_zap.c
source is missing SIG_SF and SIG_SF_FEATB tests in several of the switch/cases,
most notably in the ss_thread function.  I've patched said function to solve
this problem nicely.  I'll of course submit my patches once everything is 
working properly.  I hesitate because there's one remaining problem I've yet
to track down: the answer supervision wink makes the call hang up!  This is
obviously wrong behavior.  For example, we have the follow conversation at
present:

nearend: 2600Hz seize wink
farend: 2600Hz ack wink, ready for digits
nearend: sends KP+nnnnnnn...+ST
farend: ringback tone begins
farend: destination answers
farend: signals answer supervision with 2600Hz wink
nearend: hears wink and... HANGS UP!

The answer supervision is *supposed* to signal that the remote destination
went off hook and answered the call, and billing should begin on the local
side.  Instead, the nearend hears the initial answer wink and kills the whole
call.  I'm currently trying to track down where this broken-ness occurs in
asterisk.  Also, it would be very desirable to control whether or not a routing
code ("extension") should return answer supervision at all, e.g. if it's a
non-billable test number there shouldn't be any answer supervision, but I
don't see any obvious way at present to configure this.

Also, suffice to say, the zttool display of SF trunks' busy/idle channel
status is completely broken, which was initially misleading.  SF supervision
works regardless.  Zttool should be fixed at some point, I'll look into this
after I've solved more pressing problems.

I'm going to CC this message to Jim Dixon.

Regards,
-Mark



On Mon, Jan 16, 2006 at 06:31:28PM -0500, alex at pilosoft.com wrote:
> On Sun, 15 Jan 2006, Mark Abene wrote:
> 
> > Would anyone happen to know who the original author of zaptel's
> > "ztcfg-dude.c" is?  Is anyone still maintaining this code?  I'm most
> > interested in the "sf" part (which is really the only thing that sets it
> > apart from ztcfg) for an educational model I'm working on in order to
> > demonstrate SF (2600Hz) analog trunk supervision.  In setting the
> > following, for example, in zaptel.conf (instead of e&m, for two local
> > spans)...
> If it has dude in the name, it is 'Jim Dixon'.  (jim at lambdatel dot com)
> 
> 2600hz *represent*! (chuckle)
> 
> > ...and setting the signalling type in zapata.conf to "sf_featb", I
> > observe a seriously confused zttool display; idle channels show up as
> > weird patterns of "1011 1011" for TxA-TxD and RxA-RxD, when they should
> > show up as all "0"  status (as they properly do with e&m and featb
> > signalling).  And, unfortunately, the trunks are completely useless in
> > this configuration.  Running asterisk with
> Not being around back then, I don't remember if it *should* be 0s or not.
> 
> > debugging and in verbose mode shows that local and remote zap channels
> > are picked up and then immediately hung up again when trying to
> > originate a call. Monitor the channel with ZapBarge and you will hear a
> > quick double wink of 2600Hz, then nothing, then the originator is
> > disconnected.  MF pulsing is NEVER initiated, and the call ends.  I've
> > also tried using different frequencies for the forward and reverse
> > supervision (e.g. 2400Hz and 2600Hz), no difference. I've tried playing
> > with the transmit gain (raising, lowering), no difference. One thing
> > that puzzles me is the silence and the winking when monitoring a zap
> > channel.  This obviously isn't classic SF supervision, where you have
> > "tone on when idle, tone off when seized", which I would have preferred,
> > but rather an attempt at "SF wink-start trunk supervision", which I'm
> > guessing is either broken outright, or else chan_zap.so just has no idea
> > what's going on at this point in its code maturity.
> I'm not positive, but I think what you should be doing is e&m signaling in
> zaptel and featb signaling in asterisk.
> 
> -alex
> 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> Asterisk-Dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>