A Strategic Alliance announcement, PAIC and TCXC

August, 2022- TelecomsXchange (TCXC) is a Platform as a Service provider (PaaS), offering a turn-key solution to digitize and automate carrier transactions from buyer interconnection to supplier settlement. With on-going development, TCXC has been working closely with communications service providers officially since 2013 on monitoring and evaluating current exchange processes, creating and improving them to ensure a more reliable digital exchange between carriers and providers.    

TCXC and PAiChain have been collaborating for more than 4 years in various telecommunication projects and have now entered a new strategic partnership with a common goal of strengthening their Communication Platforms as a Service (CPaaS) offer. By taking advantage of PAiChain’s vast product portfolio and TCXC’s industry experience in carriers digital transformation, this alliance ensures high quality and fast delivery of various telco solutions.

We believe that this partnership will bridge customer facing CPaaS and the core wholesale network and produce a fully automated and tightly integrated turn-key solution that carriers need for years to come. In other words, expanding the definition of CPaaS to also cover wholesale customer & supplier onboarding, interconnection, settlement and support.

TCXC and PAiChain have teamed up to work on a shared objective:

  • Close the gap for carrier’s digital transformation with a single carrier-grade solution for offering partners an intuitive self-service prepaid-postpaid legacy and API interconnect, billing and routing for voice, messaging, and numbers using a single wallet.
  • Consolidating its carrier-grade Extended Products portfolio under a single and comprehensive prepaid and postpaid CPaaS offer tightly integrated with TCXC’s AAA (Authentication, Authorization and Accounting), structured in a business model adaptable for big and small communication service providers alike.
  • Expanding the current SMS-based services collaboration to include:
    • USSD
    • SS7
    • Geolocation
  • Integrating blockchain solutions into the existing telecom ecosystem, enabling services such as roaming fraud prevention and subscriber identity as a service.
  • Strengthening our commercial strategy, being actively engaged in identifying innovative opportunities for CPaaS needs to the benefit of their current and continuously expanding customer base.
  • Unlock new 5G monetization opportunities.
  • Strengthening our SLAs through the merging support operations and tools.

Through this strategic alliance,  both companies will strive to work towards constant platform innovation, keeping ahead of market tendencies, and expanding our product portfolio’s reach.

August 25, 2022 by announcement Carrier Digital Platform CPaaS IoT Low-Code Development SS7/SIGTRAN

TCXC Platform now runs in AWS

TCXC PaaS AWS

TelecomsXChange (TCXC) is excited to announce that the TCXC Platform legacy code is now updated, tested, and optimized to run in Amazon Web Services (AWS) ☁️. Thanks to our diligent and experienced development team and partners 🚀, we now have a Full-stack telecom wholesale digital transformation platform that is light-years ahead of the game that runs on the world’s most popular cloud infrastructure.

We are committed to providing you with industry-leading features to make carriers work easier, more streamlined, and more efficient.⁣

Here is a quick list of the components which have been optimized to work with AWS:

Diagram for SMPP Setup with Go Arch ON AWS
Diagram for SMPP Setup with Go Arch

✅TCXC SMPP Load Balancer (None TLS)

The TCXC SMPP Load Balancer is written in Go Lang and it’s responsible for handling the high load of SMPP traffic and distributing them across as many SMPP Upstream Proxies. The reason for building this component is to overcome the single-threading limitation of upstream proxy since it was originally written in nodejs. The load balancer can load balance SMPP traffic to as many upstream proxies on the same or remote server(s) as needed

Compliance: This component is SMPP v3.4 and 5.0 compliant

Estimated R&D time spent to date: 635 days.

✅TCXC SMPP Load Balancer (TLS version)

The TCXC SMPP Load Balancer (TLS) is written in Go Lang and it’s responsible for handling SMPP traffic coming over TLS and distributing them across many SMPP Upstream Proxies. The TLS load balancer can load balance SMPP traffic to as many upstream proxies on the same or remote server(s) as needed. As shown the the above figure, the TLS Load Balancer usually runs on a different port from none TLS load balancer.

Compliance: This component is SMPP v3.4 and 5.0 compliant

Estimated R&D time spent to date: 635 days.

✅TCXC SMPP Upstream Async Proxy

The TCXC SMPP Upstream proxy is written in NodeJS using Asynchronous programming, which is single-threaded. main responsibility is to perform Authorization and Accounting using TCXC Redis Async and MySQL DB operations and dispatch the traffic over to TCXC Bind Balancer for Message Termination (MT). You can run as many upstream proxies as needed on a single EC2 or multiple EC2s.

Compliance: This component is SMPP v3.4 and 5.0 compliant

Estimated R&D time spent to date: 900+ days.

✅TCXC SMPP Bind Balancer

The TCXC SMPP Bind Balancer (BB) is SMPP v3.4 and v.5.0 compliant written in Go Lang and it’s responsible for forwarding all submitted messages from upstream async proxy and controlling bind sessions, handling enquire_links, it also plays a critical role in Delivery Receipts (DR) routing to the right upstream instance using the origin TCP socket not basing its DR routing on Bind ID.

Compliance: This component is SMPP v3.4 and 5.0 compliant

Estimated R&D time spent to date: 450 days.

✅TCXC SMPP Proxy Async (Legacy)

SMPP proxy (async) is written in NodeJS, it was the original SMPP signaling for the SMS exchange functionality on the TCXC platform, it’s responsible for handling all SMPP operations and it’s pre-integrated with TCXC AAA, this component has known scalability limitations, it is recommended to migrate to Go Arch if your traffic exceeds 1000+ Transactions per second.

Compliance: This component is SMPP v3.4 and 5.0 compliant

Estimated R&D time spent to date: 1000+ days.

✅TCXC SIP Stack

TCXC SIP Stack is a combination of customized SIP Proxy and RADIUS RFC3261-compliant Session Initiation Protocol (SIP) B2BUA which represents an advanced SIP back-to-back user agent designed to be used with [RFC2865] compliant RADIUS billing engines.

✅TCXC AAA (Authentication, Authorization, Accounting)

✅TCXC SIP/SMPP Watchdog

✅TCXC Redis Async

This component works with Redis Server, it is an essential part of SMPP Go Arch, it helps with performing a large number of SMPP AAA lookups per second without hitting table locking bottlenecks in MySQL DB.

✅TCXC Carrier Digital Portal & Market Place

TCXC Carrier Digital portal is an intuitive Graphical User Interface (GUI) for buyers and sellers, it enables them to perform self-service SIP and SMPP interconnects, buy and sell communication services (Voice, SMS, Numbers) in realtime and communicate with each other transparently. It can be configured to work as a digital portal for a single service provider to automate their VoIP and SMS service offering for partners or set up as a marketplace. Additionally, it can be used for automatic API enablement for numbers, prices, testing, and trouble tickets.

✅TCXC Programmable API

Programmable Exchange, refers to communications service providers (CSPs) utilizing application programming interfaces (APIs) to automate the core actions for telecom wholesale buying and selling operations. Such as interconnection, carrier relations, market opportunity research, ticket escalation, communications, traffic routing control, ratings and reviews, and financial settlements for Voice, SMS, and Virtual Numbers. Learn more about Programmable Exchange.

Thanks for reading and please comment if you have any questions or feedback!

You may directly contact our support team here for further details on specific components.

June 25, 2022 by announcement

OpenMSISDN

Open Source E164 to E212 mapping dataset

OpenMSISDN Mapper is a detailed and high-quality e164 & e212 mapping database. it is essential for accurate billing, reporting, and routing purposes for voice and SMS traffic to have an accurate list.

It is surprisingly difficult for communications providers and developers to find a good quality e.164 to e.212 mapping database, this data set has been created and updated manually using over 10 different data sources. data is provided in the hope that it will be useful but WITHOUT ANY WARRANTY.

You can just open and use the raw json file OpenMSISDNMapper.json with your fav text editor and/or convert it to any file format you want e.g. SQL or CSV and use it as you wish, you may also create a quick RESTful API server from the json file to use it from your application.

This API allows you to integrate and interact with OpenMSISDN Mapper data set

The data is provided in standard JSON responses and uses HTTP Status Codes to help determine results.

Create The API

  • git clone https://github.com/ajamous/OpenMSISDNMapper.git
  • cd OpenMSISDNMapper
  • Install required packages
npm install -g
  • Run the API server
json-server --watch OpenMSISDNMapper.json

Using The API

  1. Now you can open http://localhost:8080/lookup to list all records
  2. Lookup a specific country E.164 & E.212 data http://localhost:8080/lookup?Country=EGYPT
  3. Lookup a specific prefix_e164 data http://localhost:8080/lookup?prefix_e164=20
  4. Lookup a specific MCCMNC data http://localhost:8080/lookup?mccmnc_e212=60203
  5. Lookup a secondary MCCMNC data http://localhost:8080/lookup?mccmnc_secondary=1234
[
  {
    "prefix_e164": 202,
    "Country": "EGYPT",
    "Network Description": "Fixed - Cairo",
    "mccmnc_e212": 0,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20,
    "Country": "EGYPT",
    "Network Description": "Fixed - Roc",
    "mccmnc_e212": 0,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 2011,
    "Country": "EGYPT",
    "Network Description": "Mobile - Etisalat",
    "mccmnc_e212": 60203,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20110,
    "Country": "EGYPT",
    "Network Description": "Mobile - Etisalat",
    "mccmnc_e212": 60203,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20111,
    "Country": "EGYPT",
    "Network Description": "Mobile - Etisalat",
    "mccmnc_e212": 60203,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20112,
    "Country": "EGYPT",
    "Network Description": "Mobile - Etisalat",
    "mccmnc_e212": 60203,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20114,
    "Country": "EGYPT",
    "Network Description": "Mobile - Etisalat",
    "mccmnc_e212": 60203,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20115,
    "Country": "EGYPT",
    "Network Description": "Mobile - Etisalat",
    "mccmnc_e212": 60203,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20117,
    "Country": "EGYPT",
    "Network Description": "Mobile - Etisalat",
    "mccmnc_e212": 60203,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 2012,
    "Country": "EGYPT",
    "Network Description": "Mobile - Orange",
    "mccmnc_e212": 60201,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20120,
    "Country": "EGYPT",
    "Network Description": "Mobile - Orange",
    "mccmnc_e212": 60201,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20122,
    "Country": "EGYPT",
    "Network Description": "Mobile - Orange",
    "mccmnc_e212": 60201,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20127,
    "Country": "EGYPT",
    "Network Description": "Mobile - Orange",
    "mccmnc_e212": 60201,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20128,
    "Country": "EGYPT",
    "Network Description": "Mobile - Orange",
    "mccmnc_e212": 60201,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 201,
    "Country": "EGYPT",
    "Network Description": "Mobile - Roc",
    "mccmnc_e212": 6020,
    "mccmnc_secondary": " 602 602999"
  },
  {
    "prefix_e164": 2010,
    "Country": "EGYPT",
    "Network Description": "Mobile - Vodafone",
    "mccmnc_e212": 60202,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20100,
    "Country": "EGYPT",
    "Network Description": "Mobile - Vodafone",
    "mccmnc_e212": 60202,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20101,
    "Country": "EGYPT",
    "Network Description": "Mobile - Vodafone",
    "mccmnc_e212": 60202,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20106,
    "Country": "EGYPT",
    "Network Description": "Mobile - Vodafone",
    "mccmnc_e212": 60202,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 20109,
    "Country": "EGYPT",
    "Network Description": "Mobile - Vodafone",
    "mccmnc_e212": 60202,
    "mccmnc_secondary": ""
  },
  {
    "prefix_e164": 2015,
    "Country": "EGYPT",
    "Network Description": "Mobile - We",
    "mccmnc_e212": 60204,
    "mccmnc_secondary": ""
  }
]

Getting Help

Help is provided by the community as soon as possible, you can open an issue here.

Warranty

OpenMSISDN Mapper data is provided in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

Contribution

To keep this list error-free and useful for everyone, We expect community members to create pull requests to contribute back improvements to the data set. Once a pull request is opened, project authors will run a verification using HLR to verify the updated data is correct before it’s merged to the master branch.

Submit your first contribution

1- Clone project git clone https://github.com/ajamous/OpenMSISDNMapper/ .

2- Create a new branch by issuing the command: git checkout -b new_branch

3- Create a new remote for the upstream repo with the command: git remote add upstream https://github.com/ajamous/OpenMSISDNMapper/

4- Switch to the new branch git checkout -b new_branch

5- edit  OpenMSISDNMapper.json using your preferred text editor

6- Committing your changes git commit -S -m "Dial Code Improvmenth"

7- push your changes git push -u origin new_branch

Once you push the changes to your repo, the Compare & pull request button will appear in GitHub. Click it and next Open a pull request by clicking the Create pull request button

June 14, 2022 by announcement

TCXC Adds Subspace support to its Carrier Digital Platform

Subspace TelecomsXChange

Introduction

Modern telco carriers interconnect over SIP protocol for voice and SMPP protocol for SMS using the public internet, it is common that each carrier has their session border controllers (SBCs) or Short Message Service Center (SMSC) at different geographical locations. Let’s start with voice, For example, if you send a call to Bharti Airtel to India, likely you’re pointing your traffic to their SBC in the UK, so all traffic is being proxied through the United Kingdom then sent back to their gateways in India for final termination. For topology hiding it is also common that your RTP/Media will be proxied as well and the. sent over the public internet to India

What is subspace

Subspace is a dedicated, secure network for delivering tomorrow’s internet today. From mission-critical real-time applications to in-network applications, Subspace helps companies create the best possible real-time experiences. Subspace offers the world’s best connectivity for real-time applications.

Ashton Kutcher on Subspace

The Public Network Challenges

As we know the public internet was designed for reliability and did not promise certain quality for real-time applications like voice, video, say you’re interconnecting to a Mobile Network Operator (MNO) Session border controller (SBC) over IP located in the UK for transit to route calls to India for example. if anything happens in the public internet between the UK and India the call quality will be degraded, or dropped. If internet routing is managed by the MNO manually, all calls to India will suffer from degraded quality until this route is fixed. Handling the global network connectivity problems in realtime is not an easy task and dropping for a few minutes or even seconds can result in users to immediately switch from your service.

Subspace as a Solution

To be proactive and solve this challenge, with a few clicks, UK MNO can send the media traffic to Airtel India via Subspace’s network by adding an entry in Subspace portal or API that will automatically provide them with a unique IP:Port that redirects to their SIP network in india.

After pointing via Subspace the traffic will be accelerated using best routes, solving any internet backbone, middle mile or last mile issues.

Subspace SIP Teleport’s proprietary algorithms ensure that your real-time application has the ability to deliver consistent voice, free of stutters, jitters, or lag, under even the most challenging network conditions, with up to 80% reduction in packet loss.

“Every millisecond counts for real-time applications. What if your users could interact with your application without network-induced lag, jitter, disconnects, and screen freezes?” Subspace.com

Adding native support for Subspace in the TCXC Stack

For the telecom wholesale industry & peering Contact Centers to benefit from the value that Subspace provides, we had to do this ! Let me explain, there is a limitation by design that can lead to causing subspace use case become not applicable for wholesale carrier traffic scenario due to authentication and authorization reasons. For example when initiating a call via Subspace network using SIP Teleport, the src IP where the call will be coming from is the subspace IP (CIDR 129.203.31.1/24), this is usually fine if the customer is using SIP registration method, however in wholesale (carrier to carrier) this means that the originators using SIP peering for authentication won’t be able to authenticate successfully by default, TCXC Authentication, Authorization, Accounting (AAA) will rejects the SIP request and send SIP error 403 to the customer.

To solve this problem, TCXC parses from SIP Teleport by subspace the real-IP that the call is coming from, so we have to challenge the special SIP header `X-Subspace-Forwarded-For` during authenticating, authorizing and accounting for this work properly.

To achieve this, we had to add support for the subspace special SIP header that SIP teleport uses to communicate the real IP address that the call came from in five components:

B2bua

Authentication

Authorization

Accounting

Web UI

In TCXC web portal we added a new checkbox for carriers that use subspace SIP Teleport to send their traffic via TCXC Network, once checked if the call is coming from subspace IP network and SIP header is set, the IPv4 authentication will use the value of the header as remote ip. If the box is unchecked the incoming call will use the regular authentication logic.

Currently this new feature is in BETA, we welcome all existing and future TCXC CSP members to take it for a test drive.

For Call centers, CPaaS providers that want to re-route to TCXC via subspace simply set your subspace network IP in outbound SIP proxy settings.

November 18, 2021 by announcement Call Center Carrier Digital Platform Cloud Routing CPaaS Market Place Programmable API Programmable Exchange SMS Exchange SMS Market Place subspace VoIP Market Place VoIP Software VoIP Tutorials

Block unwanted SIP traffic efficiently

Block unwanted SIP traffic

Blocking SIP traffic manually is a reactive procedure, in the absence of smart tools, being pro-active is nearly impossible, it is common if you’re only reacting to a SIP attack then the damage of different types is already done.

The Challenge of blocking SIP traffic

It is no secret that attackers are pretty smart programmers, commonly attackers use sophisticated tools that scan virtually any network and perform the SIP attacks automatically.

in this context, the same attacker IP address is usually seen by several servers and networks, once these tools identify a vulnerability it’ll start attacking you immediately.

When manually blocking unwanted SIP traffic, our internal data shows that we are more likely to perform SIP blocking after an alert is triggered, for example, alarms start triggering on your resources for Disk space, CPU, Memory utilization while the legit traffic has not increased.

Another operational challenge is when a SIP provider has many nodes that they manually manage, blocking an IP address one node means you have to re-deploy the same rules across the board. Management by hand is a time-consuming process whereas software-defined Automation is fast

Case Study

Recently while working with a vendor and had the sngrep tool open, we noticed many hits coming from unknown IPs, all the attempts were rejected by TCXC‘s `Authentication, Authorizations ` module, however, those attempts still consumed Disk space, CPU, and memory as they kept coming.

We went ahead and blocked the unwanted IP address manually in IP tables and repeated the same across our servers, that’s when we thought it would be a good opportunity to verify and test if this attacker’s IP was already detected by APIBan’s SIP honeypots, an open-source project that we recently heard about at Tadhack 2021.

Continue reading…
November 13, 2021 by Block SIP Traffic Knowledge Programmable API SIP DNS SRV Softswitch Tadhack voip exchange VoIP Market Place
%d bloggers like this: