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

P.S.
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
192.168.1.21 210 5586207a065 00102/00000 unkn No Tx ACK
192.168.1.21 210 37c9511e353 00102/00000 unkn No Tx ACK
192.168.1.21 210 350a8e3e45e 00102/00000 unkn No Tx ACK
67.188.24.233 230 31b027ba0ac 00102/00000 unkn No Tx ACK
4 active SIP channels


asterisk*CLI> sip show history 37c9511e353
asterisk*CLI>
  * 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

/etc/asterisk/sip_nat.conf

nat=yes
externip=64.81.30.178
localnet=192.168.1.0/255.255.255.0
qualify=yes


/etc/asterisk/sip_additional.conf

[210]
type=friend
secret=xxxxxxx
record_out=Always
record_in=Always
qualify=no
port=5060
nat=no
[email protected]
host=dynamic
dtmfmode=rfc2833
dial=SIP/210
context=from-internal
canreinvite=no
callerid=device <210>

[230]
type=friend
secret=xxxxxxx
record_out=Always
record_in=Always
qualify=yes
port=5060
nat=yes
[email protected]
host=dynamic
dtmfmode=rfc2833
dial=SIP/230
context=from-internal
canreinvite=no
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

OK
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