Why are softphone calls not connected with another?

This article describes the behavior and their causes why softphone calls are not connected together.

Behavior:

• When Follow-Me is enabled on the softphone, the call is signaled in the client, but when the call is answered, the called party does not hear anything or the call cannot be answered (toast remains). If another attempt is made to accept the call, an error message appears.
• The softphone subscriber calls a person, but continues to hear the dial tone after the call is accepted and does not hear anything about the call being accepted.

Explanation:

The call can be signaled on port 2230, but the voice connection on ports 49152-65535 and 30000-33000 is not established.

The signaling state of incoming and outgoing calls changes after they are accepted only when the WebRTC media connection between the client and the server is successfully established. If this does not work, then the toast stops for an incoming call and an outgoing call hears the dial tone (ringback).

The reasons for the failure of the media connection can of course be manifold. In the case of XPhone the circumstances are in principle very simple, because client and server "know each other" and therefore problems concerning codec, encryption etc. in the negotiation of the SDP are virtually non-existent. I.e. connection problems can actually only fail at the exchange of UDP packets between client and server. This exchange takes place over ports 49152-65535 of the client and ports 30000-33000 of the server.

STUN packets for connection verification as well as the media data are exchanged over these ports. The connection state exists in WebRTC and depends on whether the Ice state (=Successful exchange of STUN) is connected or not. Connected state is set only when media connection is successful.

Step by step explanation:

1. An incoming call is signaled via port 2230
2. Accept" is clicked in the client
3. The client tries to perform a STUN negotiation on the dynamic ports (e.g. from client port 49234 to server port 30123) to establish an audio channel with the server.
4. If the STUN negotiation works, the ice state in WebRTC is set to Connected*.
5. Based on this it is recognized that the call is established, in the client the call is now shown as established/connected
6. *If the STUN negotiation does not work, something fails on the connection path on ports 49234 and 30123.

Causes:

Cause 1:

RTP port range for voice packets (49152-65535 UDP and 30000-33000 UDP) are blocked by firewall on.
* Hardware firewall in the server network
* Software/Windows firewall on the client.

Cause 2:

Routing is not correct
* Variant 1: Client uses a VPN tunnel over which the UDP packets are generally not routed
* Variant 2: Server has several IP addresses which are not routed among each other (often softphone clients and PBX are then in different networks)

Cause 3:

Softphone-to-softphone is not considered in routing - especially when using a VPN, this can lead to further problems.

Cause 4:

The XPhone Connect Client is not connected to the XPhone Server via a VPN. So far, VPN-less operation of the XPhone Client is not possible (as of April 2021).