Cisco 7960 No ACK after 200 OK

[kraichle]

Has anyone ran into a similar problem with a Cisco 7960?

If I make a call from the 7960 phone to an external number, the call will continue for however long it's needed.

If I make an internal call with the 7960 phone to VM or another extension the call only makes it to 32 seconds, and the 3CX PBX sends a BYE. I traced it down with Wireshark and it looks like the 7960 fails to send an ACK after the PBX sends the 200 OK. The PBX continues to re-try until a timer expires I guess and then the BYE gets sent. The call appears to be setup correctly with audio both ways, but for some reason the 7960 doesn't send the last ACK.

I did some searching on the web and found a solution for the exact problem on a FreePBX site. Apparently there's a function in FreePBX that you can disable called "strict SIP processing" that fixed the problem on the FreePBX setup.

Is there such an option with 3CX?

I have a VPN link from an office internal network to a hosted server running the 3CX app for the Cisco phones. I did that cause they wouldn't register with an external IP, but that's another story.

 

[StefanW]

This option is so dangerous that I 100% advice not to use it as it will build constantly ghost calls in your pbx.
If you could share your pcap with us we can have a look (kindly only use internal calls in the pcap for privacy reasons!) and we can have a look what is happening.

 

[kraichle]

I had a suspicion that might be the case but I'm not an expert, so wanted to see what anyone else thought. I've already had that happen once. My wife set up a conf call and when done hung up, and then turned around right away and called one of the parties involved, her client naturally, to discuss the conf call. The client had not yet hung up her phone for some reason when the call waiting call came through, so she just switched over to the incoming call. The previous conf call lingered in the system for the duration of the second call. I'm guessing when the second call ended that's when the client realized she still had the orignal conf call on hold. Since my wife was the host of the conf call I would have expected the conf call be terminated when she hung up, but it didn't as long as any of the called persons were still Off Hook. It happened on the 7960 and I was able to reproduce it. After the 7960 hangs up there's no indication the conf call is still active. The reason I caught it was before we had upgraded the license to more simultaneous calls, she got the max calls error message and brought it to my attention. I doubt it's related to my current problem, but definitely don't want to be calling "Ghost Busters". We also have Fanvil X5 phones, but I haven't check to see if they do the same.

I'm going to be changing out the Comcast modem/router combo and Linksys router with DD-WRT this weekend. I've bridged the modem/router to use my own router. Others have claimed they've still had problems with the Comcast routers even in bridge mode. Besides, the modem will pay for itself in a year of not paying rental fees. I'm also upgrading our router as the latest DD-WRD build I can currently use is a 2008 build.

After I do the hardware upgrades I'll see what's still broke and get a couple captures to post.

I'm fascinated with SIP, and am trying to master it in my spare time, but there's a lot there, and I like to chase my wife around the house too.

Some guy who was probably an expert pointed out in the FreePBX forum that the "To:" tags didn't match and that's why the ACK was missing. Maybe traversing my questionable network hardware f'd up the tags, who knows.

Appreciate your help.

 

[StefanW]

Comcast routers we have seen in the past with some issues in SIP ALG and that it can not be turned off...

 

[kraichle]

I switched out the Comcast modem/router with a separate Netgear modem and router. I loaded DD-WRT on the router too. The main purpose was to better isolate guest wi-fi in the office. At the same time I thought maybe the change would fix the drop call problem, but it didn't.

I haven't been able to get a capture of the problem with the new network setup, but I attached an earlier capture which is the exact same problem. I also grabbed some internal phone SIP state logging with the new setup, which is the same problem. The attached captures are from two different phones and times, so they don't correlate. Eventually I'll get a correlation with both internal and external, but thought maybe someone will just see the problem with what I've attached.

The captures are when I make a VM call (99) and then press 9 for menu options to extend the call time. At 32 seconds it drops. From the capture you can see 3CX repeatedly sending "200 OK SDP.." attempting to get an ACK I'm assuming, but for some reason the stupid 7960 ignores it.

I remotely did the SIP Flow log via Telnet'ing in.

Appreciate any incite.

 

[kraichle]

oh, forgot to mention I changed the pcap extension to .txt and zipped it so I could upload to this site.

 

[kraichle]

OK, so I finally gave up on trying to figure out why the Cisco phones don't send an ACK. I'd need to spend another eon digging up 7960 details to figure out wtf.

I didn't want to put more hardware in the office, but felt an SBC running on a Rasberry Pi was somewhat reliable, specially when I got a backup.

The R-Pi with SBC seems to work great with the 7960 phones.

You could probably mark this solved, but I have one question on how the phones utilizing the SBC shows up in the status. At one time when I was first playing around it seemed to precede the phone model with "SBC:" on the phone uitilzing the SBC, but now it just shows as the attached image. I'm not sure if I should delete the "new" entry and everything will fall in order or do I need to do something else to correct it.

Extension 40 is going through the SBC.

 

[YiannisH_3CX]

when connecting a phone through SBC you should see the local IP of the phone Via SBC_IP.
The Fanvil in the screenshot above appears to be provisioned via STUN but there is also an SBC in that location and that is why you see the multicast message. The Cisco phones will not appear with the SBC because i am guessing you used the SBC IP as proxy to provision them at the remote site.

 

[kraichle]

Here's what I don't get, there isn't anything at the local site or pbx server site that has an IP address of 192.168.1.147. Pinging also gets no response, so why is it showing up on the list of phones. The current SBC (RPi) is at 192.168.1.79. When I first tested an SBC I set it up on a PC which is at 192.168.1.90. After I reconfigured the Cisco phone to use the SBC as an outgoing proxy it registered and showed up in the phones list as I would have expected. After I that I decided to setup the SBC on the RPi. When I reconfigured the phone to use the RPi IP address is when the strange duplicate Fanvil phone showed up under the SBC. I may have tried setting up that Fanvil phone using the SBC on PC (192.168.1.90) when I had the PC setup. Maybe that had something to do with it. I un-installed the app from the PC just to make sure it wasn't causing it, but no change.

I'm not sure why it's there. There is an option to reject it. Should I do that?

 

[YiannisH_3CX]

Perhaps the multicast message is old. If you do not reject it then the message will remain until you do.
I think it is safe to reject it since you have no need for it.