We just installed a new MBX with SIP trunking. Everything is finally up and running after a bit of head-banging and troubleshooting. Now the only issue that seems to be remaining is that the SIP trunk doesn't seem to disconnect. If you make a test call into the system and then just hang up, the trunk stays online and even rolls into voice mail and records dead air for a while. Not sure if this issue is us, or the SIP provider??

Who is the carrier? A Certified SIP provider by Vertical?

Call me crazy here, but isn't SIP supposed to be a uniform signaling standard, like those with ISDN-PRI, loop-start, ground-start, etc?

You know, those pesky little rules that have been around for decades.

Should there be any difference between service providers if they are providing a uniform service? Does the FCC oversee SIP trunking standards? My own questions are starting to scare me.

Never mind. VoIP apparently has its own set of standards. I'll be glad when those of us on the front lines are afforded knowledge of the new set of standards. This is getting downright silly.

Its not a registered carrier with Vertical, but I agree with Ed. Aren't the standards supposed to be uniform?

It would be my guess that since Vertical has a list of tested carriers, variables do exist. And remember, we still fight with carriers who don't automatically provide loop disconnect. Regional carriers and even Comcast drive me up a wall at times on that one.

Every SIP provider is a little different. Sounds like you have a programming issue. Who is the provider? PM it to me if you don't want to name them.

I've seen routers cause issues like this (turn off any SIP ALG), or lack of port forwarding (5060 UDP + RTP ports pointed to PBX IP).

Alot of providers do authentication in different ways hence the problems. You might be able to make it work with trial and error but Vertical will not waste time trying to reverse engineer every provider in the field...that's why they have an approved list.

Should the carrier be providing some type of disconnect? That would make the most sense, but what types of disconnect are standard? I am trying to get ahold of the engineer for the carrier tomorrow. I have been trying to do this while I have been out of town.

Standard for Loop start is a 1/2 second loop open from the C.O. when the distant party hangs up the phone, releases their line/trunk, whatever you want to call it. Ground start, the C.O. lifts the ground as a signal (And permanent release) that the distant party hung up.

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.