inbound callers being incorrectly connected to other callers

[andrewgroup]

We have a client with version 4.2.0.3911 (Win32)

 

The complaint is that inbound callers from their Windstream SIP trunk on a 6MB dedicated trunk that are delivered to a main receptionist desk, and then being transferred to a hunt group of a couple extensions are inadvertently being connected to other inbound callers. We are using Snom 320 handsets, and I will check that the option JOIN in TRANSFER in the advanced behaviour settings is not set, on all phones, and I'm confident they are not. The main receptionist is not....

 

Assuming that to be the case, how could or would you be able to connect to inbound callers together either my accident on the phone in the way you are transferring calls, or could the PBX or phone handsets be doing this with a programming error.

 

blind transfers, attended transfers, ringbacks etc.... and how might we construct the call trees so that users cannot make these mistakes.?

 

 

Let me add to my investigations, How does the PEER to PEER call completion setting in a SNOM phone affect PBX? Shouldn't this be off, allowing only the PBX to handle call txfers or does this not matter?

 

 

 

Any thoughts, Thanks

[Vodia PBX]

It could happen on the IP layer already. For example we have seen cases where there was a simple IP address conflict. If you are not using DHCP, I would check this (over and over).

 

But higher probability has that the router might have a limited number of UDP NAT associations available and the last "steals" an older one, so that traffic gets forwarded to the wrong client. If the problems occur only when talking outside of the LAN this might be a hint that the problem is in this area.

[andrewgroup]

In this case, the PBX has a public IP address and no router. We are checking with Windstream to determine what UDP ports they support on their SIP trunks. The PBX is using the default values, 49152-64512, or a 15K block, how many ports does a call consume?

 

I also mentioned the Snom Phone Peer-Peer call completion, does this have no affect on the PBX?

 

The PBX actually has two public facing IP's the first serves the SIP trunk, and the second serves remote Snom Phones in remote locations behind firewalls of their own. The 3rd Nic is a 50 local snom phones on the LAN....

 

I assume the remote phones will use their full range of UPD ports, as most firewalls will pass that upper range.

 

Assuming this is not a Router UDP issue from the ITSP, would it seem then that something on the LOCAL lan is interfering with the UPD Port Range?

 

If the default block of 15,000 ports is by far enough ports, I can chop off the top half as a test, and wireshark for UPD activity in that range. Would that seem a likely course of action?

 

Comments welcome.

[Vodia PBX]

In this case, the PBX has a public IP address and no router. We are checking with Windstream to determine what UDP ports they support on their SIP trunks. The PBX is using the default values, 49152-64512, or a 15K block, how many ports does a call consume?

 

Each call takes two ports towards the service provider (RTP and RTCP). 15K should be more than enough.

 

I also mentioned the Snom Phone Peer-Peer call completion, does this have no affect on the PBX?

 

No, the PBX keeps it strictly B2BUA.

 

The PBX actually has two public facing IP's the first serves the SIP trunk, and the second serves remote Snom Phones in remote locations behind firewalls of their own. The 3rd Nic is a 50 local snom phones on the LAN....

 

That could be a source for trouble. Is there any reason for this? This will only work if the OS routing tables have special entries for the ITSP and the default route goes over the interface that is used by the phones. "route print" would be interesting here (changing the IP addresses in the response to obscure the original one is perfectly okay here!).

 

I assume the remote phones will use their full range of UPD ports, as most firewalls will pass that upper range.

 

Yes, that should be no problem unless someone actively messes with it.

 

Assuming this is not a Router UDP issue from the ITSP, would it seem then that something on the LOCAL lan is interfering with the UPD Port Range?

 

I would think that the service provider has no problem with the UDP, otherwise other customers would scream very quickly. The local LAN should also be no problem as this happens only when the ITSP is involved.

 

If the default block of 15,000 ports is by far enough ports, I can chop off the top half as a test, and wireshark for UPD activity in that range. Would that seem a likely course of action?

 

15000 ports is definitevely enough, no need to search in this area.

[andrewgroup]

According to a senior engineer at Windstream / Nuvox the following are the supported ranges for SIP trunks. We've made the adjustment on the PBX to match the second range given for UPD 49152-53247 and we hope this addresses the issues. This now points out the need to verify this information with all SIP providers and to match accordingly. Cheers

 

Perhaps we could have other users post the same information in SIP Provider Forums. I'll report this so that it can be easily found.

[andrewgroup]

The Interface on the Windstream SIP trunk does not have a default route. Instead we have a persistent route for the the Registration/Proxy IP address to go out what would normally be the default route on that interface. The other WAN facing IP is a static IP in a business comcast address and has the only default route.

 

We have IP access allows for the remote offices public facing IP addresses and internal IP ranges where remote phones are registered. I do not see a range for the ITSP SIP trunk, but problems there would be a total outage.

 

What logging might capture the error?

 

Thanks

[Vodia PBX]

The Interface on the Windstream SIP trunk does not have a default route. Instead we have a persistent route for the the Registration/Proxy IP address to go out what would normally be the default route on that interface. The other WAN facing IP is a static IP in a business comcast address and has the only default route.

 

We have IP access allows for the remote offices public facing IP addresses and internal IP ranges where remote phones are registered. I do not see a range for the ITSP SIP trunk, but problems there would be a total outage.

 

The persistent route seems to be the right approach for this. It is interesting, because this is a way to ensure that (no matter what is going on with the other public IP interface) you can ensure that the quality of service on the ITSP trunk is good.

 

If the problem was fixed by choosing a different RTP port range then that's a solution to me.

[andrewgroup]

Agreed - we are now tracking down where in the call tree structures calls are being disconnected. I'm seeing a lot of 404 not found in the SIP traces on the LAN side of the PBX include 486 and 487.. Leaving this for tommorrow. Thanks

[andrewgroup]

We've had no reported cross connects since aligning the SIP ports with the usable port ranges used by Windstream. however, the call count is down from it's peak and we have an unresolved issue created on another post related to forwarding calls from one hunt group to another with an Autoattendant in the middle. Hopefully they are two distinct issues. Thanks.