atcomsystems.ca/forum Forums VOIP Phones & IP PBX VoIP & Cloud Phones, Hosted PBX, General IP Phones SIP trunks not disconnecting

all the issues seem to point back to the provider. If I make an outbound call, it disconnects fine after the call. Anyone that calls in, gets disconnected after 1 minute regardless, and outbound calls lose voice traffic on one side occasionally. Not too mention, "all circuits busy" and things like that. Its going to be a bad finger pointing contest here.

Well, its not all the providers fault. I did some searching and also some testing. Seems if I route the call to the front desk and she answers, all is well. But if I route to the AA, its always the same. No disconnect and the call times out after a minute. Looks like the MBX is not acknowledging the call.

Z-man you are comparing apples to oranges. Of course the calls handled by the front desk are released promptly. The disconnect from the MBX when the front desk hangs up 'knocks down' the call from the near end rather than depending on a disconnect signal originated from the far end. The front desk isn't waiting for a disconnect signal. Even if they are hung up on, they ARE going to hang up the call and knock it down from the 'near end'. If they were hung up on, and did not hang up the handset, they probably would hold the line 'up' for better than a minute, unless the C.O sends a disconnect signal down the line.

Most AA/VMs time out after no audio or DTMF signaling for 30-60 seconds. Or when they detect repetitive noise like the fast 'beep-beep-beep' that many/most C.O.s send out to 'off-hook-to-nowhere' phone lines. Often, the C.O. switching to the 'beep-beep-beep' is accompanied by a battery break that coincidentally appears to be a disconnect signal and the phone system releases the line.

In other words, there is nothing wrong with the MBX.

We're not talking about POTS lines here. SIP is a different animal and my bet is the programming is not correct on the MBX. I've had the same issue with the IPECS.

Toner also makes a good point, might be a router issue.

What happened on the IPECS? The issue almost appears as if the Voice Mail card on the MBX is not talking to the rest of the system on calls. Its like the VM does recogize any of the SIP packets...

OK, I understand these are SIP trunks, but if they connected to POTS ports on the MBX, they have to act like POTS lines/trunks. So what ARE they connected to on the MBX?

the SIP trunks are just routed through the customers ISP, to the customer's router, and then across the network to the MBX. Pretty much a standard setup.

If I remember correctly, they would hit one channel, then roll to the next, getting an AA greeting each time. It's been a while and it was on an in-house test system. That's why I asked who the provider is, perhaps we can compare a setup.

I've had some carriers we could not make work period because they didn't do an approved authentication...they had some proprietary method that would probably require code rewrite to interface with.

Well, and update. I originally thought it might be an equipment issue, as things seemed to work okay as long as you by passed the auto attendant. After some extensive troubleshooting on my and Vertical's part, the guys had Vertical noticed some odd things with how the SIP provider was sending packets. We did find this out until they had me run Wireshark and capture some packets, which I forwarded to them for analysis. We then called the SIP provider and told them what we saw and how it wouldn't work. They finally got there tech people on it (pain) and made some changes. Now everything appears to functioning normally. Still a few quality issues with long distance, but thats going to have to handled by the provider. I have to say Vertical tech support was crucial to resolving this issue. I would not have been able to do it without them.