Number routing and SBC
Your number terminates in the carrier’s data centre; the call lands on the PBX you choose, by rule
VoIP Router is a routing service that terminates your Türk Telekom lines in the carrier’s Istanbul and Ankara data centres instead of at your own building, and delivers each call to the platform of your choice according to the rules you write. No cabling, ports or hardware investment; the call is tied to a rule, not to a building.
The service has been running since 2020. We can deliver calls to your own PBX, a cloud PBX, a contact centre platform or a cloud system abroad; where the two ends do not speak the same language (codec, SIP version, DTMF signalling) we do the translation. Your number is never ported; when you change platform, only the routing rule changes.
Platforms we deliver calls to
Genesys Cloud
Amazon Connect
Twilio
3CX
Alotech
Asterisk
Microsoft Teams
Enterprise SIP trunk
Cloud platforms abroad
Who it is for
No phone system should end at a single point of failure
If your 444 number is tied to the PBX in your office, whatever happens to that office happens to your phone. Roadworks cut the line, the power goes, a port fails; your customer hears a busy tone.
Organisations moving to a cloud contact centre
Numbers stay fixed on the carrier side and routing is switched to the new platform. No number porting during the migration; the old and new platform can run side by side for a while.
Multinational companies
Mapping Turkish numbers onto a cloud contact centre hosted abroad: deployments where the carrier, the global provider and the integrator sit at the same table.
Multi-city operations
Ankara, Istanbul and Izmir numbers are defined on one interconnect. A call that goes unanswered in Izmir lands seamlessly in the Istanbul or Ankara office.
Capabilities
More than routing: translation, redundancy, diagnostics
Taking a number from one place and handing it to another is easy. The real work is stepping in where the two ends cannot agree technically and doing the translation.
Rule-based distribution
Calls are routed by number, time of day, caller or the destination’s answer state. An unanswered call fails over to another city or platform.
Codec and protocol conversion
Where the two ends use different audio codecs or SIP versions, we convert: between G.711, G.729 and whatever format the far system expects.
DTMF compatibility
Whether keypresses travel as RFC 2833 events or in-band audio can differ at the two ends. Most “IVR does not detect keys” problems come from here; we translate between the two.
SBC layer
As a session border controller we sit between the two networks: managing the call flow, hiding topology, terminating encrypted calls with TLS and SRTP, and reconciling signing and authentication differences.
Data attached to the call
A value entered in the IVR or pulled from the CRM, such as a national ID number, is attached to the call, converted into the structure the far PBX understands and delivered. The customer does not give the same information twice.
Packet-level diagnostics
When a call does not behave as expected, the SIP messages, SDP negotiation and RTP stream are examined from capture. Which side asked for what, at which step, is measured rather than guessed.
How it works
Four steps from the carrier to your PBX
The routing layer sits between where the number arrives and where the call lands; both sides have a backup.
- The number terminates at the carrierTürk Telekom 444 and geographic numbers arrive at the routing layer over NGN SIP; numbers from other domestic and foreign carriers arrive over SIP.
- The rule is appliedThe call is distributed by number, time and destination state; where needed, codec, DTMF and header conversion is done and data is attached to the call.
- Two data centresThe routing layer runs separately in Istanbul and Ankara with configuration kept in sync. If one has a problem, calls flow through the other.
- The call is deliveredOver a private link or the internet, the call lands on your own PBX, a cloud PBX, a contact centre platform or, with format conversion, a cloud system abroad.
Topology
The whole path in one diagram
Carrier side, routing layer and delivery points.
Routing layer
Number at the carrier, rule with us, call on your PBX
Numbers from Türk Telekom and other carriers are gathered in one routing layer. From there the call is delivered by rule to your local PBX, a cloud PBX or a contact centre platform; numbers from different carriers and countries are managed in one pool.
- Carrier side: NGN SIP and SIP interconnects
- Delivery side: private link or the internet
- Rule-based distribution
- Protocol conversion
- Adding data to the call
- Failover on no answer
In the field
We have brought very different systems together on the same number
A few of the projects we have run. Customer names that can be shared as references, and architecture details, are given in a meeting.
Hybrid SBC for Genesys Cloud
For an organisation moving to a cloud contact centre, two SBCs were set up in Istanbul and Ankara; Ankara is not a passive standby but takes calls and places outbound calls actively in round-robin. No manual intervention is needed during an outage.
Turkish numbers into Amazon Connect
In a cloud contact centre project hosted abroad, Turkish numbers were mapped onto the platform through a global provider; carrier, provider and integrator at the same table.
Redundant path through Twilio for a high-volume 444
For a transport company placing 16-24 thousand outbound call attempts a day, termination to Twilio over TLS and SRTP through the SBC; dial order and monitoring were corrected so every call connects on the first attempt.
Keypresses the IVR could not detect
The carrier sent keypresses as RFC 2833 events, the far system rejected them and asked for in-band, then could not decode the in-band tones. SIP/SDP and RTP packets were examined and a translation put in between; the fault was with neither the carrier nor the customer.
Why us
We also know the system where the call lands
Many companies route numbers. Our difference is speaking the carrier’s language on one side and the PBX’s language on the other.
We are a 3CX Silver Partner, we deploy cloud contact centre platforms and enterprise PBXs, and we build our own products on top of this infrastructure. No interpreter is needed in between. The service is priced per concurrent inbound and outbound call (channel); it is treated as equivalent to a Türk Telekom SIP trunk service and requires no additional hardware investment.
Included in the service
- Redundant routing layer in Istanbul and Ankara
- Rule-based distribution and failover on no answer
- Codec, DTMF and SIP header conversion
- Encrypted termination with TLS / SRTP
- Packet-level diagnostics and 24/7 monitoring
Out of scope
- Carrier line and number charges
- The licence of the PBX or platform where the call lands
- The internet or point-to-point link on the customer side
Works with
Related products
VoIP Router is the entrance to your call infrastructure; it delivers calls to all of the following.
Contact Center Solutions
Voyce, Alotech and 3CX: compare the platforms where a call can land.
Cloud PBX
An enterprise PBX running in the cloud with no hardware to buy; fed through VoIP Router.
Frequently asked
Questions asked before deciding
For a question not covered here, write to us; we will add the answer.
Do we have to port our number?
No. Your numbers stay fixed on the carrier side; the only thing that changes is where the call is routed. Even if you change contact centre platform, your numbers stay in the routing layer and we switch the rule to the new platform.
Do we have to replace our current PBX?
No. You can start with your existing PBX. Bringing the line to your location needs no cabling, port or hardware investment either.
Which platforms can you deliver calls to?
Nine targets we have delivered to in the field: Genesys Cloud, Amazon Connect, Twilio, 3CX (we are a Silver Partner), Alotech, Asterisk-based PBXs, Microsoft Teams, local PBXs over an enterprise SIP trunk, and cloud systems abroad with format conversion.
If there is an outage on your side, do our calls drop?
The routing layer runs separately in Istanbul and Ankara with configuration kept in sync. If one data centre has a problem, calls flow through the other; your number is not moved and nothing happens on the carrier side. If required, the second data centre is used actively rather than as a passive standby.
Can we manage numbers in different cities from one place?
Yes. Your Ankara, Istanbul and Izmir numbers are defined on one interconnect; a call unanswered in Izmir lands in the Istanbul or Ankara office. Numbers from different carriers and countries are also gathered in one pool and distributed by rule.
Our IVR does not detect keypresses. Can you fix it?
Most of these problems come from DTMF mismatch: one end sends keypresses as RFC 2833 events, the other expects them in-band. We solved exactly this case in the field by examining SIP/SDP content and RTP packets; a translation is set up in between.
Can you send customer data along with the call?
Yes. A value entered in the IVR or pulled from the CRM, such as a national ID number, is attached to the call, converted to the structure the receiving PBX understands and delivered. The customer does not give the same information a second time.
How is the service priced?
Per concurrent inbound and outbound call (channel), as a monthly channel fee. It is treated as equivalent to a Türk Telekom SIP trunk service. The channel count can be increased during the year as your volume grows.
Let’s talk through your routing scenario
Which numbers come from where, where the call should land, which platform it will talk to: we work these out in one meeting and prepare a quote with channel count and a redundancy plan.
Or reach us directly: +90 (216) 912 00 79[email protected]