[Asterisk-Dev] ztcfg-dude?

alex at pilosoft.com alex at pilosoft.com
Mon Jan 16 16:31:28 MST 2006


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




More information about the asterisk-dev mailing list