Ensuring Myphoner Voice works as expected and provide you with the best quality call possible takes a lot of work on the backend and also relies on your internet service provider (ISP).

We make use of the latest web technologies to ensure security and quality calls, this does mean there are some specific requirements that ISP's need to allow in order to use Myphoner Voice effectively.

If you find that calls are not going through, for example, calls not connecting when using your ISP but connecting when using mobile data (this is a great troubleshooting strategy) then it means your ISP likely needs to make some changes to their network in order for you to use Myphoner Voice.

Note: We do not recommend using WIFI connection or mobile data (other than perhaps for testing) when using Myphoner Voice and rather use a direct ethernet connection. This is due to latency requirements inherent in Voice services.

Below is information you can provide to your ISP to assist them in ensuring the best connection which means great calling for you!

Below is a diagram of network components involved in delivering the service

The WebClient javascript makes an outgoing https request to signalling servers for signalling on TCP port 443 and when a call is then connected the browser will start sending media UDP packets to a dynamically allocated UDP port in the range 16384-32768 to a designated media switch handling call sound.

At the same time, the media switch will start sending UDP packets to the users IP address and port negotiated, with the sound from the remote phone.
If the user IP address is private (rfc1918) the media switch will wait for the first UDP packet to arrive and use the source IP address and port instead from this packet. This makes it possible to also support NAT network environments.

It’s important that the user firewall allows the following network packets

The WebClient uses the WebRTC API in the browser for the phone calls to work. Which uses SDP protocol to convey the information about media connection (IP addresses, codecs, encryption key, etc).

By using the SDP, the browser will try to find the best IP address and path to the media switch by employing the ICE / STUN technique. Basically trying to send a “test packet” from any of the IP addresses the user might have to a server that will reply with information of the public IP address it sees the packet coming from.

This means that if the user has a lot for network connections (Virtual

adapters/VPNs/etc.) establishing media can take extra time, which is undesired in a call situation. Typically it would result in loss of sound in the first 1-10 sec of the call, so it’s important to consider this.

When the media connection is up, the network quality has a great impact on the quality of the call itself. If network latency changes a lot (jitter) or packets are lost, the quality will degrade.

Because sound is realtime, a lost packet can not be resent before the sound in the packet has been played to the user or remote party.

We normally recommend the following network requirements for good quality calls.

This means that using WIFI connections and mobile data connections (WAN) is not recommended. They typically do not fit inside these metrics.