Call not being disconnected

[craigreilly]

We have some offices in the Dominican Republic, using the tunnel and connecting to my corporate pbx. Occasionally, the network on the remote end goes down for a blip of a second and a call is dropped... So, they start their call over.
However, the first call is only dropped from their phone. 3cx hangs on to it, until the provider sends their re-invite, at the 1 hour mark to ensure the other end of the call is still there.

Anyone else experience this?

 

[leejor]

Haven't seen that happen myself but I can understand it happening. What is the re-registration time on the trunk group to that provider, is it also one hour? Since both ends assume that a call is in progress, it might not make any difference, but what would happen if the duration were shortened? You would think, however, that the party at the far (provider) end, hanging up, would trigger a call release from the provider.

With SIP, as you know, since there is no "loop" keeping the call up, once it has been connected end to end, the server relies on messaging to know when one end has dropped. If nothing is received, then it's assumed that the call is still in progress.

What causes the momentary drop, could that be resolved?

 

[craigreilly]

Our offices are in hotels. We generally get a circuit from their "guest network". Usually these are pretty good networks.
In this case, all 3 networks are not so great... go down or get saturated regularly. No battery backup, etc.

We just finished installing DSL at the first location. Its only 2mb but affordable and only 1 phone and computer. (I was able to get rid of the tunnel now too - no double NAT)

Registration is at 60 seconds... the only saving grace is the reinvite from the provider every 60 minutes. luckily these offices operate with Miami phone numbers... so I am not paying international rates unless they are calling the island. Most of the calls are to the US.

 

[leejor]

I would then question why your provider is not disconnecting, when the call, connected through them, drops. I have to assume that The called or calling party is hanging up when the call goes dead. Why does the provider not see this and drop the circuit to 3CX? Do they have a call supervision problem?

Perhaps you can replicate the disconnected call using an end-point more local. If you have access to multiple provider, try a call out over the one you know "hang" get that to stay up, then try it over another to see if the behaviour is the same. In theory a call should stay up if you placed a call to a number, the called party hung up but you didn't. If it works correctly, a disconnect should come from the provider and drop the trunk. If the call were going out over a PSTN gateway, with no supervision, then, of course, you would be reliant on CPC ,disconnect tone or worse case scenario, a silence time-out.

 

[sigma1]

leejor, you probably missed that 3CX sees that call connected from the sip endpoint (phone) to the PBX and therefore it keeps the PBX to provider live.... The provider cannot see the drop between phone and PBX but the re-invite causes the PBX to re-invite the phone and when that does not work it drops the call...

You can easily reproduce this (even with an FXO or PRI) by starting a call and then in the middle of it have a LAN drop... The call stays active within 3CX.

 

[leejor]

I understand that because the phone is cut-off, no disconnect is ever received by the PBX and the call stays up. What I question is why, when (I assume) that the far end (outside) party hangs up (after all the call whet dead), the provider does not recognise this and in turn drop the call to 3CX.

You see "hanging" trunks, in most cases, when using a PSTN gateway because disconnect has not been set-up correctly. Since this would appear to be routed out on a VoIP provider, then supervision should be provided

 

[sigma1]

Are we assuming that the remote user did hang up?
Truth to be told, the remote end did not issue a bye either... the call stayed up and was only dropped at the 60min re-invite timer.

After investigating this issue Craig, the call was to a hosted conference bridge (room)... That is why the remote end did not hang up. I pulled the trace on it... PCMU RTP to 3CX was up all along.

 

[craigreilly]

Thanks for all the replies.
Not a big deal - but was an interesting process.

 

[leejor]

After investigating this issue Craig, the call was to a hosted conference bridge (room)... That is why the remote end did not hang up.

Well, that makes sense. I had wrongly assumed that these were "normal" outbound calls to an end user, that would have hung up when the originator dropped off. A conference bridge would require that the originator initiate a disconnect.