[asterisk-users] Delaying SIP disconnect after incoming call hangs up?

[Steve Totaro]

On Tue, Jun 10, 2008 at 5:28 PM, Dave Platt <dplatt at radagast.org> wrote:
> I'm looking for a way to delay the disconnection of a call to
> a SIP extension (or pad it with silence) for a few seconds, after
> an incoming call to that extension hangs up.
>
> Rationale:  I have an Asterisk PBX (current 1.4.20 codebase), with
> a Leadtek BVP8051S ATA hooked to an analog phone which has a
> built-in answering machine.  Incoming SIP connections to the
> appropriate extension are dialed to this SIP ATA, the phone rings,
> and the answering machine picks up... all as it should be.
>
> However, when the caller hangs up, the ATA immediately starts
> generating a fast-busy disconnect/congestion beeping.  The
> answering machine doesn't recognize this as a hang-up situation
> (it expects to hear the line go silent) and it keeps recording beeps
> until its message-length timer expires and it hangs up the line
> to the ATA.
>
> Unfortunately, I can't change the answering machine's behavior,
> and I don't think it's possible to change the Leadtek BAP8051S to
> just go silent.
>
> So, what I'm hoping, is that there is some way within Asterisk to
> change the PBX behavior when the incoming call disconnects, so that
> it can defer sending the disconnect event to the SIP extension
> for 10 or 15 seconds... enough "quiet time" for the answering machine
> to recognize end-of-call and hang up.  I think that either sending
> nothing (no RTP stream) to the SIP extension, or sending "silence"
> or "comfort noise" frames, would work fine.
>
> I've looked through the documentation and through a fair bit of
> the source code, and haven't found anything which actually works.
> I tried adding an "h" hangup rule to the dialplan for this
> extension, with a Wait(10) action, but this seemed to have no effect.
> Either the "h" rule isn't working, or the disconnect frame has already
> been processed and a SIP BYE has been sent.
>
> I've only been able to figure out one approach which *may* work...
> use an "h" hangup rule for the extension, which runs a DeadAGI()
> script, which contacts the SIP ATA via its http administrative
> interface and reboots the ATA (which immediately drops the line).
> This may very well work, but is about as elegant as a bag-full
> of wet tree sloths, and I'd like to do a better job than this.
>
> Is there any provision in Asterisk for being able to "catch" the
> hangup/disconnect of the far end of a connection, and either wait
> (with no activity) for a fixed period of time, or do the equivalent
> of a Play() to send the contents of an audio file to the remaining
> extension (the target of the Dial() in the extension dialplan)?
>
> Currently, the SIP extension in question is behind a NAT, and
> I've set "canreinvite=no", so I believe that all of the SIP and
> RTP traffic is going through Asterisk.  It seems to me that it
> *ought* to be possible for Asterisk to catch the end-of-
> connection situation and react in some way other than immediately
> disconnecting the receiving SIP peer, but I'm not sure that any
> such capability has been implemented.
>
> I realize that the outside-the-box answer to this would be "Why
> use an answering machine?  Use the PBX voicemail!" but that's
> not entirely desirable in this situation.  Since the phone /
> answering machine is analog, it has no "message waiting" light
> available to let us know that a call has come in, and we'd also
> lose the ability to "jump onto" a call which is in the process
> of being recorded.  My wife is comfortable with how the existing
> answering machine system works, and I'd rather present her with an
> IP-based solution which doesn't change the behavior she's used to...
> she's not the most technophilic person around.
>
> Thanks in advance for any ideas you can throw my way!
>

Your ATA is to blame.  It is generating the noise you describe.  Maybe
there is a setting on the ATA to address this.

Idea, try an Grandstream 286 ATA.  I know people bash Granstream and I
have in the past as to their phones, but their ATAs are pretty good.

Thanks,
Steve T