India Toll Compliance for Enterprise CUG and UC
Any enterprise with a presence in multiple locations typically chooses to have a private voice network that will lower the cost of intra-enterprise communications. This is done through the installation of a PBX (private branch exchange) within the enterprise.
This private intra-enterprise communications setup can be considered as a Closed User Group (CUG). A CUG contains a set of phones with private extension numbers (typically 4 to 7-digit extensions) to communicate with each other over voice and video, using VoIP (Voice over IP).
The worldwide public telephone network, on the other hand, has phones with 10 to15-digit public extensions that can be used to communicate with each other anywhere in the world.
India (and a few other countries) restrict the interaction of these two networks (private enterprise and public telephony), in such a way as to avoid toll bypass. These policies make up the ‘India toll compliance’ regulatory framework, which every communications infrastructure in India is expected to comply with.
Failed audits can shutter operations
Enterprises that fail the India toll compliance audits have to pay hefty fines and/or shutter operations. Both the financial and reputational loss is immeasurable.
Additionally, the telephony and internet service providers for that enterprise are also held accountable, and they can take penal action against the enterprise that has failed this compliance.
Many large organizations have had to re-architect their complete voice infrastructure in the aftermath of a failed toll compliance audit, with weeks of disruptions to their operations, and the consequent financial implications.
Compliance managers are increasingly being held accountable to ensure their voice infrastructure is toll compliant. Continuous tracking of the compliance risk, followed by mitigation and remediation strategies, are an essential facet of compliance management.
The complexity of the systems and solutions involved, and the multiple potential paths to a violation, have made it increasingly apparent that automated mechanisms; rather than manual tracking, is the way forward.
Toll Compliance Regulations in India
Department of Telecommunications (DoT) is a government body responsible for creating policies and granting licenses for the telecommunication services in India. Telecom Regulatory Authority of India (TRAI) is a body that is authorized to regulate these telecommunication services in India.
DoT through the Unified Access Service License (UASL), Cellular Mobile Telecommunications Service license (CMTS) and Unified License (UL) has defined the basic structure of the India toll compliance regulations.
Additionally, TRAI has mandated an Other Service Provider (OSP) registration, with financial guarantees, for any entity providing non-telecom services over telephony infrastructure. This would apply to entities like call centers, tele-medicine etc.
Applicability and Responsibility
If the answer is ‘yes’ to the questions below, then your enterprise needs to be compliant to the India toll compliance regulation
- Do you have a PSTN trunk from a telecom operator in India? (PSTN trunk can be Analog, PRI/BRI, SIP or of any protocol. The type of the trunk is not relevant)
- Is your organization operating out of multiple locations?
- Are you using VoIP (Voice over IP) in your organisation between the various locations? (either at the endpoint or between servers in the data center).
Each and every enterprise needs to ensure that it is compliant to the TRAI India toll compliance regulation. The onus of compliance is with the enterprise.
The telecom operator that supplies the PSTN trunk to the business and the ISP that supplies the data connectivity between the locations also have a responsibility to audit the enterprise periodically and ensure that the enterprise is compliant to the regulation.
Any telecom device (endpoint or server) that can conference two or more parties (or, in technical terms, mixes media) can cause a compliance violation.
Private Branch Exchanges (PBXs), Session Border Controllers (SBCs), Interactive Voice Recorders (IVRs), Voicemail systems, Conferencing servers and even Endpoints having the ability to conference must be appropriately configured to ensure that they are compliant.
Technical implications for an enterprise with CUG
The TRAI India toll compliance regulations imply certain rules and policies within the voice infrastructure of any enterprise that has a CUG. At a high level, it boils down to these policies:
- The communications infrastructure needs to have a logical partitioning between the CUG and the PSTN communication, and the two should not be mixed, so that there is no toll bypass on the PSTN network.
- A strong audit trail (system logs, call detail logs etc.) needs to be maintained for all the communication activity at each of the locations the enterprise is operating in.
The logical partitioning policy can mean different things in different scenarios. To fully comply with the TRAI India toll compliance policies these various scenarios need to be considered, and appropriate configurations put in place to ensure they are restricted.
International CUG calls to local PSTN
Consider an Enterprise setup with an international location in New York and a branch in Bangalore. The enterprise has created a closed user group (CUG) between these two locations using VoIP telephony, such that all its employees in the two locations can freely communicate with each other. Any such enterprise call; if it performs a local hop-off at the Indian termination, would violate toll compliance regulations.
An employee in New York makes a call to Bangalore over the CUG. Once the call lands in Bangalore, if the call is routed over the local PSTN trunk to a mobile or a landline number, then it is violating the India toll compliance regulations. Such a call would be masking an international call as a local call, and the international toll that would have been collected has been bypassed.
Long distance CUG calls to local PSTN
Consider an Enterprise CUG setup with two Indian branches in Mumbai and Bangalore. Even a local hop across locations within India, is a violation. An employee in Mumbai makes a call to Bangalore over the CUG
Once the call lands in Bangalore if the call is routed over the local PSTN trunk to a mobile or landline number then it is violating the India toll compliance regulations. Such a call would be masking a national long-distance call as a local call, and the long-distance toll that would have been collected has been bypassed.
Transfer / Call Forwarding to local PSTN
Transfer/ forwarding and other forms of call redirections are a significant source of toll violations. A redirected call if it terminates outside the CUG using a local PSTN trunk would effectively violate toll. Another common compliance violation (which is also used by attackers for toll fraud), is redirection through voicemail server.
An employee in Mumbai makes a call to another employee in Bangalore over the enterprise CUG. The employee in Bangalore is out-of-office and configures his desk phone extension to redirect all calls to his mobile number.
If this call is forwarded to the mobile number from a PSTN trunk connected to a gateway in Bangalore, then a long-distance call between Mumbai and Bangalore has effectively happened, but only the local Bangalore toll is paid. This would be a violation of the India toll compliance.
Conference Bridge: Internal & External
An enterprise with multiple locations can have conferencing hosted either internally within their CUG or from an external provider accessible through the CUG.
When the conference bridge is hosted internally within the CUG, then all the users in the enterprise would be able to use the conference bridge freely. If the conference bridge is accessible from the PSTN though, and a user can join the conference from his mobile phone or landline through the publicly accessible number, then there is a possibility of toll compliance violation.
A single conference having both the PSTN parties and the CUG parties violates the toll compliance regulations. This is because such a conference would be allowing parties located in different locations, to communicate by paying just the local PSTN toll.
A conference having all CUG parties or all PSTN parties does not violate toll compliance.
When the conference bridge is located externally, if all the parties of the enterprise access it through PSTN trunks located in their respective locations, then there is no violation of toll compliance. If any of the parties in the conference access the bridge directly through a CUG, or through a PSTN trunk connected in a different location, then there is a violation of toll compliance regulations.
Another popular option chosen by many enterprises, is a third party hosted conference solution. This is equivalent to the external conference bridge scenario described above, and can lead to toll violations if the routing in the enterprise is not configured appropriately. Configuring all the CUG calls to the hosted external conference bridge to route through the PSTN trunks is one option to stay compliant in such a setup.
Trunk-to-Trunk call redirection
Calls coming into the enterprise through a PSTN trunk or a private enterprise trunk, if redirected through another trunk can violate toll compliance.
- A call coming in on an enterprise private trunk between two PBXs in different locations, and getting redirected over a PSTN trunk would violate toll compliance regulations
- A call coming in on a PSTN trunk and getting redirected over an enterprise private trunk to a PBX in another location would be violating toll compliance regulations.
- A call coming in on a PSTN trunk into the enterprise at one location, and getting redirected over a PSTN trunk at another location (on the same PBX), would also be violating the toll compliance regulations
A couple of scenarios in trunk-to-trunk redirection that would not violate toll compliance
- A call coming in on an enterprise private trunk between two PBXs and being redirected over another enterprise private trunk is not causing any toll bypass, so it is allowed.
- A call being redirected over the PSTN trunks of the same location, or redirected back over the same incoming PSTN trunk would not be causing any toll bypass, and so is allowed.
- Trunk to Trunk redirection typically happens through either rerouting from the routing tables or redirections from the endpoints. The endpoint redirections like transfer and forwarding in these situations are a subset of the overall trunk-to-trunk redirection scenarios. Additionally, some vendor specific features like remote coverage or vector based routing can also result in out of enterprise network trunk-to-trunk redirection.
International Far-end PSTN (allowed)
Consider a scenario where a PSTN user in New York dials an Indian colleague through the Enterprise CUG network. Such a call would bypass the international toll on the New York side.
Such a scenario is allowed by the India toll compliance regulations. They only insist on the separation of PSTN and VoIP on the Indian side of the call. Mixing of these on the far-end, in another country, is allowed by the India toll compliance regulations.
A user on a softphone can be located anywhere, and whether he is violating the India toll compliance regulations depends on where he is located and who he is calling.
- If the user is using the softphone in the same location as the location of the PBX (either on office network or through the internet or VPN) then he is not violating the India toll compliance regulations.
- If the user is using the softphone from a different location over a VPN link, then any kind of PSTN calls he makes would be violating the India toll compliance regulations. On the other hand, if he just calls other users in the CUG, then it is not a violation.
A soft phone application using internet telephony to make a call to another enterprise endpoint is not a toll violation. The violation happens when a PSTN trunk in another location is used for such a call.
A user who frequently moves across locations would need to register to his extension from all those locations. If the user’s configuration in the system is designed for his home location, then there might be toll bypass violations happening.
For example, an employee temporarily visits his Chennai office, and registers from there. When he makes a call to a PSTN number in Bangalore, if the call is routed over the Bangalore PSTN trunks then it would be a national long-distance toll bypass. On the other hand, if the call is routed over the PSTN trunk at Chennai, then it would not be a toll compliance violation.
So, if the migratory user is configured to dynamically use the local resources of where he travels, then the system would be toll compliant. Dynamically determining the location of an endpoint at run time (typically ip-address based), will mitigate this issue.
Individuals with Special Access
A user with special privileges in the system could potentially be the cause for toll bypass scenarios. For example, while the system might be blocking trunk-to-trunk transfer, some users might have access to it through override configurations in the PBX. Often, higher-level executives or the system administrators have special access configured. Another scenario frequently observed is the access restrictions being missed out for a set of endpoints through negligence.
In addition to the logical partitioning scenarios that need to be handled as described above, the system also needs to collect a proper audit trail.
- System logs and Call Detail logs (CDR) to be collected and stored in a tamper-proof manner for a period of one year
- The Call detail logs should contain all the necessary information to track the origination and destination of the call.
- These logs need to be maintained at each site for the purposes of auditing.
The scenarios described are some of the most common that are encountered on a typical enterprise CUG using a PBX in a UC solution. The capabilities described in the scenarios need not be turned off, the configuration should be customised to ensure the system stays toll compliant.
Additionally, any changes to the system configuration need to be tracked carefully and diligently to ensure that they are not creating any toll compliance gaps.