Voice quality is produced by the complete path, not by the telephone service alone. A well-designed provider platform cannot correct congestion, inconsistent latency, local packet loss, incorrect SIP handling or endpoint power-saving behaviour inside the customer environment. Network readiness should therefore be checked before a SIP trunk or cloud voice service is connected.
GeoNumbering's Master Offer lists indicative prerequisites for the customer network. They are planning inputs, not a guarantee of quality. The final design should reflect the customer's topology, expected concurrency, codec choices, access method and security architecture.
1. Measure latency and jitter on the real path
The Master Offer indicates latency consistently below 60 ms and reduced jitter as planning prerequisites. These values must be interpreted in the context of the path being tested. A local speed test does not show the behaviour between the voice site and the service edge.
Measure during representative operating periods. Record latency, jitter and packet loss in both directions where the tooling permits it. Look for variation, not only an average. A stable path with predictable performance is more useful than a short test taken when the network is quiet.
Identify where Internet access, VPN termination, firewalls, SD-WAN policies and wireless links enter the path. If more than one site will use the service, test each relevant route. A result from headquarters should not be applied automatically to a remote office.
2. Review SIP ALG and security devices
The Master Offer specifies that SIP ALG should be disabled. SIP ALG can modify signalling as it passes through a router or firewall, which may conflict with the behaviour expected by the PBX, SBC or provider.
Do not change production security controls without a reviewed plan. First identify every device that may inspect or rewrite SIP traffic. Confirm the required ports, addressing and session behaviour for the agreed configuration. Where a customer SBC or third-party platform is used, verify the requirements in the official vendor documentation.
Document the final firewall and NAT design. The purpose is to make signalling and media paths explicit, not to bypass security policy.
3. Calculate bandwidth from concurrent calls
The relevant input is concurrent calls, not the total number of users. The Master Offer provides this planning formula:
Required bandwidth = 1.2 x concurrent calls x codec bandwidth
It gives approximately 100 Kbps per call for G.711 and approximately 25 Kbps per call for G.729. These are planning values from the offer and should be verified against the final configuration.
Example: if a site plans for 20 concurrent G.711 calls, the indicative calculation is 1.2 x 20 x 100 Kbps, which equals 2,400 Kbps in the relevant direction. This is an example, not a capacity commitment. The design should also consider other traffic, access-link behaviour, VPN overhead and the network's quality-of-service policy.
The Master Offer lists Internet, IPsec VPN and MPLS as transport options available by project. The right choice depends on the customer's architecture and the agreed service scope.
4. Prepare endpoints and mobile applications
IP phones need appropriate network access and reliable power. The Master Offer refers to dedicated sockets for IP phones. Confirm VLAN design, DHCP options where needed, switch capacity, power delivery and the route to the voice service.
For mobile applications, push notifications and operating-system power-saving behaviour can affect reachability. Review application permissions and energy settings on the supported devices. The exact behaviour remains subject to the mobile platform and application documentation.
A pre-migration checklist
Before connecting the trunk or moving users, confirm:
1. Each relevant site has been tested on the actual service path. 2. Latency, jitter and packet loss have been recorded during representative periods. 3. SIP ALG is disabled and no other device rewrites signalling unexpectedly. 4. Firewall, NAT and SBC responsibilities are documented. 5. Bandwidth has been calculated from expected concurrent calls and the selected codec. 6. Internet, VPN or MPLS transport has been agreed for the project. 7. IP phones have the required switching, power and network configuration. 8. Mobile applications have the required notification and power settings. 9. The customer and provider agree on test calls, evidence and first response contacts.
These checks make the boundary between provider service and customer infrastructure visible. They also create evidence that can be used if a problem appears during testing. The aim is not to promise a perfect result. It is to remove avoidable uncertainty before voice traffic depends on the new path.
Repeat the checks after material changes. A new firewall, access provider, VPN design, codec policy or office can alter the path even when the voice platform is unchanged. Keep the measurements, configuration references and test results with the site record. This gives the provider and customer a common starting point for diagnosis and prevents an old readiness result from being applied to a different network state.