Join Us!
We will contact you shortly

AB Handshake FAQ

Frequently Asked Questions

Fraud detection
Network impact
How exactly does the Call Registry control the calls? For example - how does this work with TDM operators?
If you opt for the Control mode, the Call Registry can give commands to stop connecting a call or disconnect an active call. This is achieved via standard means of RADIUS and Diameter protocols or a custom HTTP API on any SIP equipment. The same goes for TDM networks - the call control is performed via standard accounting protocols. The Call Registry should be integrated with network equipment that can manage calls - for example, with a switch or SBC. In case of integration with an SCP or CAMEL gateway, the call can be controlled via CAMEL triggers.
How does the system deal with number portability?
Please, see the diagram of dealing with Number Portability below.

In this scenario, the number was ported from Operator 2 to Operator 3.

  • Operator 1 makes a call to Operator 3, but since the number was ported, the call is E 164 routed to Operator 2 first.
  • The Call Registry 1 sends a validation request to Call registry 2.
  • When the call reaches Operator 2, it sends the call details to its Call Registry, where B-number is ACQ checked. Then, Call Registry 2 communicates the information to Operator 1.
  • Now, Call Registry of Operator 1 directs a new validation request to Call Registry 3.
  • When Operator 3 receives the call, it also sends the call details to Call Registry 3 for validation.
  • All the information is also communicated back to the Call Registry 1, so Operator 1 understands what happened to the call on its way.

How does the system deal with Call Forwarding?
The two call legs are validated independently. If one of the networks participating in either of the call legs is not a member of the community, the call will be flagged as "unverified". It will be up to the participating operators to decide if they wish to connect such a call. Each operator will be able to see all outbound redirected calls on a separate tab in the Control Center.
Multiple call attempts for the same B-number may arrive at the same time, especially with frequently called B-numbers like VoiceMail, IVR, Customer Contact Centers, Embassies, etc. There might be no distinction possible between the call registry events generated by originating operator(s). How would AB Handshake act on these call attempts to avoid false positives in billing and unwanted call rejections?
In case of multiple simultaneous calls to the same B-number, the Call Registry on the terminating side will verify each A and B pair. The system can alert/block calls with an unverified A and B pair. There will be no false positives.
As the B-number is used for routing, the fraudster will still be able to short-stop IRSF calls and collect the money. And as the call is short-stopped, there will be no call registry item generated by the terminating operator for the handshake. So how does AB Handshake prevent short-stopping?
When the originating side switch initiates the call, it sends the A and B pair to the originating Call Registry (CR). The originating side CR will send a verification request to the terminating CR. In case of short-stopping, the terminating CR will respond with “no such call". This allows the originating CR to make a conclusion about short-stopping and end the call. It prevents short-stopping in real-time.
How does AB Handshake counter Wangiri?
a) If the Wangiri attack is initiated by a legal service provider using its own number range, the service will provide evidence that calls were originated by a participating entity. There is no CLI spoofing involved, and the exchange of handshakes will match if both operators use AB Handshake.
b) If there is CLI spoofing involved - the calls will be labeled as an unconfirmed call, and depending on the CR settings, it will either generate an alert or block the call. In either case, the call also will be blocked during the second call when the subscriber calls back. This call will normally be consistent with the short-stopping scenario and handled accordingly.
How does AB Handshake counter Robocalling, Scam Calls, Call Bombing?
It uses the same method as with Wangiri.
How does AB Handshake detect and counter Hidden Trunk fraud?
By Hidden Trunk we understand the case when the switching malware is illegally installed on the same hardware (with the same IP) as a legal switch. When such illegal malware originates a call, the terminating side can recognize this call as one sent by the legal switch. Such “hidden trunk calls" leave no traces on legal switching equipment and the AB Handshake Call Registry, too. So the terminating Call Registry will mark these calls as fraudulent ones, as “calls with unconfirmed origin" – and if the terminating provider turns the blocking option on for this type of fraud – the system will block these calls in real-time.
How does AB Handshake handle Call Stretching?
When the Call Registry at the terminating side receives the “End Call" event, it initiates validation of this event with the originating CR, which can then send a “disconnect" command to the originating switch, thus preventing the call stretching. The “End call" confirmation is performed in real-time.
How does AB Handshake handle False Answer Supervision (FAS)?
The detection process will be very similar to the Call Stretching detection, only in this case, the "Start call" event will be analyzed.
How does AB Handshake handle Interconnect Bypass (SIM-Box Fraud)?
During Interconnect Bypass, the Originating Operator and the Terminating Operator are cross-checking call details. During this check, it becomes evident that the Terminating Operator didn't receive a call with an international A-number, yet it received a call with a local A-number, that can't be confirmed either, with other call details being identical. We see these two mismatches and deduce it is an Interconnect Bypass/Sim Box.
How does AB Handshake handle PBX Hacking?
Suppose there is a legitimate call from A-number belonging to Operator 3 to B-number belonging to Operator 2. And some carrier manages to redirect this call through the PBX (with assigned number A) belonging to Operator 1. The call will come from Operator 1 with A and B pair to Operator 2 to be terminated to number B. Call Registry 2 will detect two simultaneous calls to the same B-number — one with A and B pair (coming from the device as A and B and from Call Registry 1 in verification request 8 as A and B) and another one with A,B — coming from verification request 4 from Call Registry 3. This situation is considered to be a sign of PBX hack at Operator 1 side.
In the case of PBX hacking with generated traffic - PBX belongs to originating operator 1. If it is hacked with generated (artificial traffic) the call to B-number will not reach the operator 2 it belongs to. It will be short-stopped and the Call Registry 1 will alert "short-stop".
Keep in mind that numeration is purely to guide the user through the process. In reality, steps are done instantly & asynchronously.
Can AB Handshake work together with my current FMS?
It sure can. The real-time validation process can provide valuable input data for a statistically based FMS. We are to discuss any such integration requested by the operator.
Will there be a delay in the call setup after the integration of the Call Registry?
There is no delay. Call setup and call validation processes run independently via different channels.
Does the service introduce any additional signaling load?
The solution does not change the SIP signaling load since it is out-of-band. The handshake uses a separate channel and requires less than 1000 bytes in both directions per call. There may be some additional load due to the setting up of an encrypted session if you choose this option. It depends on the encryption method.
What will happen with a call if the system components will appear to be unavailable due to network problems?
In case the system components are unavailable due to different reasons, the service will not interfere with regular calls flow. Calls will still go through, the service will mark them as “unverified”.
Does the service impact international transit carriers’ business?
The system has no effect on operation of international carriers.
What impact does the service have on the switching system? Can it reduce the capacity of the switches? What network bandwidth will be required?
There will be no impact on the performance of the switching system. Even if the service is unavailable for some reason – the call will be completed normally. Connection bandwidth of public internet is sufficient for the service. Adding AB Handshake will not affect your gateway's output.
Does this service require direct connectivity between the originating operator and the destination network? Would it be a leased line or public internet VPR, or something else?
The service is designed in such a way that it does not require any bilateral relationships between the participants on a legal or technical level. We use simple out-of-band signaling, so if the Call Registries at both networks have a reliable public internet connection - that would be enough. We carried out a topology test that showed that there is no requirement for a leased line.
What if a wholesale entity of a group is a gateway for all cross-border communication for the group's properties? Will the integration with the wholesale gateway switches be sufficient to protect all members of the group?
It’s a common position for groups of operators. There are no intermediaries between the gateway and the retail operators belonging to the same group, you have a trusted environment. It’s the easiest and logical solution to install the CR at the gateway switches rather than having a CR in each OpCo. The AB Handshake service will not affect the traffic output of the switches.
You mention the standard settings can manage 10 000 cps – how does scalability work? Is it possible to cascade?
Yes, absolutely. 10 000 cps can be handled by very simple hardware, with the price around $3 000. You can choose more powerful servers, and besides, you can cascade one-by-one if needed.
How do I know who else is using or planning to join the service?
When you are already on board - this information will be available in the Control Center interface. While you are still in the negotiation phase - we are obviously restricted by NDAs. But you can obtain this information by signing a non-binding MoU document. This will allow us to inform other participants about your interest in the solution and provide you with the current list of participants.
What integration options does the service provide for operators?
AB Handshake provides different integration options. The service allows different types of network switching equipment such as switches, SBCs, SCPs, and CAMEL gateways to communicate with the Call registry via standard protocols: RADIUS, Diameter, HTTP API, SIGTRAN. SIP operators can integrate by placing the system's SIP proxy as b2bUA.
Does the Call Registry need to be installed on a physical server, or is a cloud solution possible?
Both options are possible. If you opt for the cloud – the integration can be even faster, especially on an internal cloud. Requirements for the server are not high, so a moderate server or even Amazon cloud would suit the needs.
What configurations and modifications need to be done on the network side to integrate with the Call Registry? How do we integrate with a soft switch?
We will provide detailed technical data on request. The integration can be performed using SIP, RADIUS, Diameter, HTTP, SIGTRAN. During the integration, we will make all necessary changes on our side. We will get a message from your switch (RADIUS message, for example) and make changes in our API to work with your equipment. In case you opt for the SIP proxy option - we will provide recommendations that will ensure full redundancy in case of a temporary outage of the SIP proxy.
Can you name which switch vendors are tested to work with Call Registry?
Currently, we have deployed this system with Cataleya equipment. Nokia, Huawei, Ericsson, and other legacy equipment vendors will smoothly integrate with our system since we use standard communication protocols used by all vendors and we are currently testing it with different switches. Generally speaking - we can integrate with any equipment that works with standard accounting messages or can work through an API.
How does the system ensure the privacy of data?
Currently, international calls go from the originating operator to the terminating operator through a cloud of international carriers, and A and B numbers are transmitted in open text. The system exchanges A and B numbers only between originating and terminating operators through an encrypted out-of-band channel.
How does the system ensure the security of the Participants Database?
The Participant Database will be managed by a trusted neutral institution. Every operator who wants to protect the range they operate has to submit it to this trusted institution. The coordinating institution (after the onboarding procedure) will upload the data to the database. The operator will confirm the uploaded data. After that, an update will be distributed to all participating Call Registries. All participants will see the uploaded E.164 range and every subsequent update. The Participants Database contains only the following information: Operator ID, Operator E.164 range, Operator Call Registry IP address. It is important to stress that all call logs are only stored in the local Call Registries - the Participants Database has no access to such information.
Does the service comply with privacy rules like GDPR?
During usual calls, you send A and B numbers in SIP headers that are open text now. Every operator in the chain has access to this data. In our case – the Originating and Terminating Call Registries communicate only with each other through an encrypted channel. There is no access for any other party. We are not transmitting anything other than what you already transmit through signaling. Besides, Recital 47 of the EU GDPR specifically states that "The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned."
What type of encryption is used?
Communication between Call Registries is TLS-encrypted. Certificates are distributed by a neutral coordinating organization.
What is the pricing model?
The price list is available on-demand, as well as the conditions of the Early Adopters program. The charging unit is a validated international call attempt (no CAPEX, and there is a sliding scale for growing volumes.)
Still have a question?