Applies To
Call2Teams - Customers
Overview
The service platform supports registration and is designed to be used with registrations that have an expiry time of 1 hour.
SIP registration is a method that allows a SIP device to notify an upstream phone system such as a PBX or Trunk that it is available for calling for a given user, or range of numbers.
Why do other platforms have a short expiry?
A short expiry time can be beneficial if the SIP device is on a network which sits behind a NAT gateway and/or is firewalled.
In these cases inbound traffic is only permitted after an outbound packet has created what is known as a firewall pinhole.
The platform has no need of this, all the Edge nodes are on static public IP addresses.
This means a SIP REGISTER packet coming from the platform can have a contact header formed of IP Address:Port which will not change or expire.
What issues can be caused by a short registration expiry?
Every time a registration is triggered a SIP dialog is created.
This creates load for the upstream PBX/trunk.
Although an individual SIP REGISTER packet is typically small, a dialog is required as the registration is challenged for authentication. This requires an on-going piece of state whilst the user registration completes.
Even small state and small network traffic multiplied by accounts with thousands of users can cause spikes of load.
Although the platform has the appearance of a desk phone/normal SIP device, in the background, all those registrations are typically originating from a single node for a specific account's PBX/trunk.
A legacy PBX may handle 1000 desk phones differently to 1000 registrations on the platform, as those legacy desk phones will come from distinct IP/ports.
Conversely, as the platform originates from a single IP/port, a simultaneous URI registration limit is imposed to ensure the far end is not overwhelmed.
Note: this is not a packets per second limit, but a simultaneous dialog limit.
As soon as a registration completes, the next registration is started.
This limit helps to keep the load down, and ensures that the platform does not cause an accidental denial-of-service incident on the upstream PBX/trunk.
The drawback to this feature is that for large volumes of users on very short expiry times the SIP REGISTER packets will not be processed in time. This can cause a stale registration state, that in turn can impact on calling.
Solutions
There are two options for customers to take that can help ensure that the PBX/trunk is configured in an optimum way:
Set registration Expiry to at least 1 hour
Customers can set the expiry time on their PBX/trunk to allow for a 1 hour (3600 second) expiry period.
As described above, there is no benefit to a shorter expiry period on the platform, so a larger expiry period ensures the PBX/trunk is configured to better handle load.
Larger expiry times also allow for a success margin. This is used to add a random element in to the registration renewal time, allowing a large user base to gradually spread out their registrations over the expiry time window.
Utilise non-registration / static routing
It is possible for some PBX/trunks to be configured to avoid registration altogether.
If the PBX/trunk supports such a configuration and is on a static IP then there is no technical advantage to using registration.
Both the platform and upstream PBX/trunk can be configured to recognise the IP/port configuration of one other, and so route calls accordingly.