******************************************************* I patched the code to add a wink when seizing a trunk from sitting on an idle trunk. It sounds much more realistic. The extra line of code is: zt_set_hook(i->subs[SUB_REAL].zfd, ZT_WINK); In the old days, the far end of the trunk would "kerchunk" when seized with 2600 when sitting on an unconnected "goody" trunk. My system now does this with the following patch to chan_zap.c : ======= old patched ========== case SIG_SF: /* Check for callerid, digits, etc */ chan = zt_new(i, AST_STATE_RING, 0, SUB_REAL, 0, 0); if (chan && ast_pthread_create(&threadid, &attr, ss_thread, chan)) { ast_log(LOG_WARNING, "Unable to start simple switch thread on channel %d\n", i->channel); res = tone_zone_play_tone(i->subs[SUB_REAL].zfd, ZT_TONE_CONGESTION); if (res < 0) ast_log(LOG_WARNING, "Unable to play congestion tone on channel %d\n", i->channel); ast_hangup(chan); } else if (!chan) { ast_log(LOG_WARNING, "Cannot allocate new structure on channel %d\n", i->channel); } break; default: ast_log(LOG_WARNING, "Don't know how to handle ring/answer with signalling %s on channel %d\n", sig2str(i->sig), i->channel); res = tone_zone_play_tone(i->subs[SUB_REAL].zfd, ZT_TONE_CONGESTION); if (res < 0) ast_log(LOG_WARNING, "Unable to play congestion tone on channel %d\n", i->channel); return -1; } break; ========New patched============= case SIG_SF: /* Check for callerid, digits, etc */ zt_set_hook(i->subs[SUB_REAL].zfd, ZT_WINK); chan = zt_new(i, AST_STATE_RING, 0, SUB_REAL, 0, 0); if (chan && ast_pthread_create(&threadid, &attr, ss_thread, chan)) { ast_log(LOG_WARNING, "Unable to start simple switch thread on channel %d\n", i->channel); res = tone_zone_play_tone(i->subs[SUB_REAL].zfd, ZT_TONE_CONGESTION); if (res < 0) ast_log(LOG_WARNING, "Unable to play congestion tone on channel %d\n", i->channel); ast_hangup(chan); } else if (!chan) { ast_log(LOG_WARNING, "Cannot allocate new structure on channel %d\n", i->channel); } break; default: ast_log(LOG_WARNING, "Don't know how to handle ring/answer with signalling %s on channel %d\n", sig2str(i->sig), i->channel); res = tone_zone_play_tone(i->subs[SUB_REAL].zfd, ZT_TONE_CONGESTION); if (res < 0) ast_log(LOG_WARNING, "Unable to play congestion tone on channel %d\n", i->channel); return -1; } break; ******************************************************* I made one additional modification to Phiber's patches. I changed the patched zaptel.c code: ================================= if r { /* if something happened */ if (r != ms->rd.lastdetect) { if ((r == 1) && (ms->toneflags & ZT_REVERSE_RXTONE)) { ms->wink_timer = ms->rxwinktime * ZT_CHUNKSIZE; ms->transition_counter = 0; } ms->rd.lastdetect = r; } } ================================== to this: ================================== if r { /* if something happened */ if (r != ms->rd.lastdetect) { if ( ( r ) && (ms->toneflags & ZT_REVERSE_RXTONE)) { ms->wink_timer = ms->rxwinktime * ZT_CHUNKSIZE; ms->transition_counter = 0; } ms->rd.lastdetect = r; } } =================================== Having the original "if" statement test for "1" rather than any non-zero value was how Phiber "goodied" the trunk - made it possible to box another call without have to dial back in. It did this by inhibiting hangups on the trunks when steady 2600 was present. It required the REMOVAL of 2600 to hangup and then attach an MF receiver. A side effect of this "goody" arrangement is that forward supervision was also affected. If a blue box user hung up on a call from his own end, the far end call would not disconnect until the far end went on-hook. This caused lots of problems when dialing a recording or line that would not hang up on its own. The trunk would get stuck and the next user to seize the trunk would be connected to whatever the previous user had dialed (a conference bridge, for example). Changing the "if" statement to test for any non-zero value, restores proper supervision and also makes blowing off a call in the forward direction more consistent, since the change makes the trunks sensitive to STEADY 2600 again. If using my changes to zapata.conf to eliminate the warbling (documented in another thread), the calls are still "goodied" as the near end is still insensitive to 2600 supervision. This solved the few last remaining problems I was having. I can now remove all the protection timers to hang up the far end I had in place to protect the trunks. Whistling off a call is much more consistent from all call states. ***************************************************** Phiber, you yourself gave me the idea when you mentioned to me that if you cranked the Zaptel gain way up, the warbling turned into a 2600 tone. This suggested that the IIR notch filter implementation in zaptel.c was not dealing with continuous high-level tones very well. Not being well versed in DSP filters, the easiest thought was to reduce the transmit gain on Zaptel trunk group 2 (the far end, channels 25-48) and see if that helped. I lowered the TX gain in Group 2 in 1 dBm increments. The warbling got softer, but sounded the same until I got to -20.0 dBm. Suddenly the warbling vanished and was replaced by only a soft buzzing. The TX gain adjustments only affect the level of the 2600 tone, so normal call audio gain is unaffected. Then, I wondered if changing the level would affect call completion, especially handshaking and supervision. The answer is "no". In a previous thread, we determined that the trunks are using immediate start dialing. I guessed that only the removal of 2600 in the forward direction had any real effect (after your patches) - that of starting the "Simple Switch" MF detection. The presence or absence of 2600 from the far end doesn't matter at all to the near end. To test this, I disabled 2600 detection in the near end by changing the signalling from "reverse" to "normal" in zaptel.conf, but only in the near end receiver. Disabling the SF receiver in this way allowed the notch filter to continue to operate. Call setup was unaffected, but this completely eliminated the spurious hangups that happened sometimes when the far end answered or when certain "no such number" announcements played. So, everything still works normally, except (as you noted) the far end wink (which is for effect and has no function in call setup, except as a "dial tone" to the blue box user) is now fairly soft. I think it sounds much more realistic. There is different (and better?) DSP notch filter code in some asterisk radio repeater code I found for Ham applications, but it is beyond my skill to port it to zaptel.c. It might be a better solution. Here are the changes I made: In zaptel.conf: Original ====== sf=1-24:2600,10,inverted,2600,0,inverted sf=25-48:2600,10,inverted,2600,0,inverted New === sf=1-24:2600,10,normal,2600,0,inverted sf=25-48:2600,15,inverted,2600,-20.0,inverted In zapata.conf: Original ====== [channels] context=default language=en jitterbuffers=24 echocancel=yes rxgain=0.0 txgain=0.0 context=nearend signalling=sf group=1 channel=>1-24 context=from-internal stripmsd=1 signalling=sf group=2 channel=>25-48 ; How long generated tones (DTMF and MF) will be played on the channel ; (in milliseconds) toneduration=68 New === [channels] context=default language=en jitterbuffers=24 echocancel=no rxgain=0.0 wink=250 context=nearend rxwink=300 signalling=sf group=1 channel=>1-24 context=from-internal rxwink=50 stripmsd=1 signalling=sf group=2 channel=>25-48 ; How long generated tones (DTMF and MF) will be played on the channel ; (in milliseconds) toneduration=68 ====================================================