SIP Staying Off-Hook, Help?!?

I’m having a very real problem with SIP channels not hanging up at one particular site… they have the exact same hardware/config that we use everywhere, nobody is experiencing problems like them, and I can’t find what’s causing the problem.

This appears to be a station-side problem, but does not matter if the extension is local or remote. I’m getting open channels with all extensions.

Here’s what I’ve done
Replaced entire chassis, hard drive, etc.
Originally TB 2.2, then did fresh build of 2.2.1
Replaced router
Moved from Cable to T1

I’ve provided sample logs/conf below, and if you look specifically at the ‘sip show history’ xxxxxxxx, I think that’s where the problem lies (notice the 487 and continuing ACK)… I just don’t know what to do about it.

Any ideas?!?

  • J

asterisk*CLI> show channels
Channel              Location             State   Application(Data)
0 active channels
0 active calls

asterisk*CLI> sip show channels
Peer User/ANR Call ID Seq (Tx/Rx) Form Hold Last Message 210 5586207a065 00102/00000 unkn No Tx ACK 210 37c9511e353 00102/00000 unkn No Tx ACK 210 350a8e3e45e 00102/00000 unkn No Tx ACK 230 31b027ba0ac 00102/00000 unkn No Tx ACK
4 active SIP channels

asterisk*CLI> sip show history 37c9511e353
  * SIP Call
1. TxReqRel        INVITE / 102 INVITE
2. SchedDestroy    32000 ms
3. Rx              SIP/2.0 / 102 INVITE /100 Trying
4. CancelDestroy
5. TxReqRel        CANCEL / 102 CANCEL
6. SchedDestroy    32000 ms
7. Rx              SIP/2.0 / 102 INVITE /180 Ringing
8. CancelDestroy
9. Rx              SIP/2.0 / 102 CANCEL /200 OK
10. Rx              SIP/2.0 / 102 INVITE /487 Request Terminated
11. TxReq           ACK / 102 ACK




[email protected]
callerid=device <210>

[email protected]
callerid=device <230>

It may help to know that the inbound routing is nothing out of the ordinary either…

1.) Inbound call comes in with DID from Vitelity
2.) Call is pushed to an IVR where a greeting is heard
3.) The only option is transferring to a single queue
4.) A join message is played, CID is prefixed, and caller position is announced
5.) Caller speaks with agent (all calls recorded, set per extension) or leaves message in voice mail (rare)

I’ve already tried

1.) Changing proxies with Vitelity (
2.) Changing recording from per-agent to per-queue

They have a mix of Aastra 480iCT and Grandstream GXP-2000’s,

  • J

what router???
what switch’s if any…

If the SIP channel is not releasing there are two things which cause that
RTP stream
frame loss

Does the channel ever hangup on it’s own.

If you do a script call (call file /wake up call) does it hang up?

And the most important question is Can YOU reproduce the error?

We’re using the Linksys RV042 at this site… we’ve already replaced it with another (same model) and know it’s not a hardware issue with the router itself. Also, we use this same router & config at a great many other sites as well, so I’m similarly confident in the programming as well. This was the first thing I did.

I’ve done atleast two completely fresh drives for them as stated above, with the most recent being 1.2.18. I’ve just scheduled with them to upgrade them to 1.2.20 tomorrow morning (I know about 1.2.21, but we’ll see).

The channel does NOT hang up on its own, the only way is through a restart of Asterisk or a reboot.

I should also say that this is NOT happening on all calls either, infact they are an extremely high call volume center. But when channels do stay offhook, it’s across all extensions… that is 210, 211, 212, etc. all report sip channels as ACK at idle (regardless local or remote).

As far as reproducing the problem, I’ve not yet been able to find a way to reproduce the problem…

…end of last week I put on NV’s Reminder 3.0 on the system which also uses scripted .call files, and it’s been working excellent (thanx Ward). So yes, call files seem to be handled correctly.

All I can think of is that it’s some kind of hardware problem, but I’ve replaced all the hardware I can think of (including power & network cables).

The most I got from Digium’s forums is that the SIP protocol has no real disconnect (like IAX), and that it’s a known bug in 1.2.x and early 1.4.x Asterisk… and that it has been fixed, and to upgrade Asterisk (which is what I’m doing tomorrow).

I really appreciate it,

  • J