Summary
- Delovaya Svyaz Ltd., the Russian limited company registered on 5 May 2015, is active and has current financial and communications-resource signals. Its legal identity, AS47968 registration and globally visible route all align around Alexey Khramtsov and the Saint Petersburg address on Kronverkskaya Street. That is strong evidence of a continuing small telecom business, but not of a city access network.
- AS47968 originated one IPv4 prefix,
83.69.255.0/24, to every one of the 327 IPv4 peers sampled by RIPE RIS on 10 July 2026. Current paths ended through Arelion's AS1299, Citytelecom's AS29076 and Transroute's AS50509, with additional evidence consistent with PITER-IX route-server propagation. There was no IPv6 announcement. - The 256-address block is not Delovaya's independent allocation. RIPE records it as
Filanco-AS47968-Rent, a provider-aggregatable sub-allocation maintained by Citytelecom. Three routing adjacencies can improve logical reach, but public data does not show three separate fibres, buildings, power feeds or carrier entrances. - The current
tel4biz.ruservice site presents nationwide IP telephony, virtual numbers, a virtual PBX and corporate-phone support. Its legal footer and contact page identify Alexey Khramtsov as an individual entrepreneur, not Delovaya Svyaz Ltd.; its operator-partnership page expressly says the group is not a communications operator. The site's resilience page claims five servers in separate data centres, two internet channels per server and automatic failover, but names no facilities, carriers, capacities, test results or recovery times. - The regional-ISP and local-field-repair premise is therefore unproved. A still-live Delovaya-branded site claims office internet across Russia and two independent customer circuits, but its sitemap and footer point to 2016-17 material and provide no current service map, owned route, customer count or access technology. The defensible impact surface is business voice and a compact internet edge; the network evidence grade is Weak for a regional access provider and Medium for a live small routing and telephony operation.
The route is real; the last mile is not demonstrated
There are two tempting ways to misread Delovaya Svyaz. The first is to see a microenterprise, an old website and a single /24, then dismiss the network as paperwork. The second is to see three upstream names, an internet-exchange signal and a nationwide internet offer, then imagine a regional fibre operator. Neither interpretation survives a close look.
The company is real and current. Russia's Federal Tax Service company search returns limited liability company Delovaya Svyaz, tax number 7813220816 and registration number 1157847159579, formed on 5 May 2015 in Saint Petersburg with Alexey Romanovich Khramtsov as general director. The RIPE organisation and autonomous-system records name Delovaya Svyaz Ltd., identify Alexey Hramtsov as the administrative and technical contact, and give the same Kronverkskaya Street address. The transliteration differs by one letter, but the address, telephone number and later tel4biz maintainer align the records.
The operating signal is stronger than a registration. RIPEstat's routing status marked AS47968 announced on 10 July 2026. It counted one IPv4 prefix containing 256 addresses, no IPv6 prefix, and complete visibility across the 327 IPv4 peers in that aligned sample. The announced-prefix response identified 83.69.255.0/24. This is public reachability attributed to Delovaya's routing policy, not a dormant ASN.
What the route does not disclose is equally important. BGP says that other networks know a path toward 256 addresses. It does not identify a subscriber, a building, a cabinet, a pole, a radio, an optical line terminal, a customer-premises device or a service truck. A route can support servers, a voice platform, management systems, interconnection addresses, enterprise circuits, customer NAT pools or a mix. The current public record does not allocate those uses.
The old Delovaya site makes broad access claims. Its internet page says Delovaya internet is available on every Saint Petersburg street, in Moscow and across Russia; it advertises fibre, speeds from 5Mbps to more than 100Mbps, round-the-clock support and two independent internet channels. Yet the site's sitemap carries 2017 modification dates and its footer reads 2016-17. There is no address-level availability result, map, network diagram, construction notice, pole agreement, tower list or contemporary tariff document.
Those omissions do not prove the old offer was false. It could have been delivered through wholesale access partners, building operators or other carriers, which is common in business telecoms. They do prevent the offer from establishing Delovaya-owned access plant in 2026. "We can connect this office" and "we own the route to this office" are different statements. The first can be fulfilled by procurement and support; the second requires evidence of physical control.
This distinction changes the article's centre of gravity. The tangible Delovaya infrastructure is a live border route and a claimed distributed voice-computing platform. The local access layer remains an unverified supplier boundary. Field repair may be necessary somewhere in the chain, but the evidence does not show that Delovaya owns the field or employs the crew.
One name now sits across two contracting identities
The corporate boundary is unusually visible because the two public sites name different legal operators. The old dela.bz site carries Delovaya branding, uses the telephone number found in the RIPE contact record and ends with a copyright notice for the limited company. Its privacy document also names the limited company as the personal-data operator. That is direct evidence that the Delovaya legal entity used the brand and public website.
The current Business Telephony homepage tells a different legal story. It markets smart IP telephony, virtual numbers and hosted phone systems across Russia, but the footer identifies ИП Храмцов А.Р.: Alexey Khramtsov operating as an individual entrepreneur. The current contact page repeats that identity, publishes the sole proprietor's registration and tax numbers, and gives a legal address in Udmurtia. At the same time, it says the organisation is located in Saint Petersburg and supplies services throughout Russia.
The continuity is substantial. The same owner-director name appears in Delovaya's company records, the RIPE contact and the sole-proprietor site. The RIPE organisation's abuse address uses [email protected]; the AS record is maintained by tel4biz-mnt. The company-history page describes a family telecom business dating to 2003, says a Business Telephony company was formed in 2014, and recounts earlier computer support, IP-telephony integration, office cabling and subcontracting work.
Continuity of control is not the same as clarity of contract. The current site does not say that Delovaya Svyaz Ltd. supplies its services, licenses the platform to the sole proprietor, owns the servers, invoices the customers or employs the support staff. It does not explain whether the limited company now exists mainly as a licensed network-resource holder while the sole proprietor sells the applications. Public corporate records show both identities around the same person, but do not publish their operating agreement.
One page makes a last-mile inference especially unsafe. The current partnership offer to communications operators says Business Telephony will sell equipment, integrate phone systems and provide first-line customer support while the operator supplies communications service. It then states plainly: "We are not a communications operator." In context, "we" refers to the current Business Telephony group or sole-proprietor offer, not necessarily to Delovaya Svyaz Ltd. as a separate licensed company. Even so, it describes a business model built around integration and support for other operators' customers rather than owning every underlying circuit.
The limited company remains more than an abandoned shell. Companium's current company record, which republishes Russian official-company information, lists it active, with 2025 accounts, a telephone-services main activity and Khramtsov as sole owner and director. T-Bank's counterparty page also lists the company active and shows two communications-license records. These are meaningful operating indicators, but they still do not identify which legal person signs a current customer contract found through tel4biz.ru.
For customers, this boundary determines who can restore what. The seller of a virtual PBX can change call routing, server configuration and user settings. The holder of AS47968 can change BGP announcements and border policy. A wholesale carrier can repair the customer circuit. A data-centre operator controls power and physical access. If those roles sit in different legal entities, an incident crosses several ticket queues even when one person ultimately controls two of them.
The current /24 is rented capacity, not an address estate
The route's ownership chain begins one level above Delovaya. RIPE's record for 83.69.255.0/24 calls it Filanco-AS47968-Rent. Its status is SUB-ALLOCATED PA, meaning provider-aggregatable space sub-allocated from a larger provider-controlled holding. Citytelecom's maintainer controls the record, and the listed network contacts are Filanco and Citytelecom roles. A separate route object authorises AS47968 to originate the prefix and is also maintained by Citytelecom.
This is not a defect. A small operator can route a provider-assigned block globally and use it productively for years. RIPE's routing history shows the current /24 broadly visible from 25 August 2021 through the research cut-off. It replaced earlier space, including 92.255.67.0/24, which AS47968 had originated for several years. The history establishes continuity of routing while showing that the address supply can change.
The provider-aggregatable status creates a dependency that an independently allocated block would not have in the same form. Delovaya needs Citytelecom or the relevant address holder to maintain a valid sub-allocation, route object and filtering relationship. If the commercial arrangement ends, Delovaya may need to renumber services or obtain permission for a different route. A customer whose firewall, SIP peer or access list hard-codes addresses inside the /24 could then face work even without a fibre fault.
The address count must also be kept in proportion. A /24 contains 256 numerical IPv4 addresses before operational reservations and private design choices. It can support a meaningful small network, especially where virtual hosts, carrier-grade translation or shared applications concentrate many users behind few public addresses. It is not a measure of customer count, voice channels, calls per second, server capacity or internet bandwidth.
There is no current IPv6 announcement. RIPE's routing-status sample saw zero IPv6 prefixes, and the current prefix inventory contains only IPv4. That does not prove every Delovaya or Business Telephony service lacks IPv6: services can be hosted in another network, and private systems can use other address arrangements. It does show that AS47968 itself offers no broadly visible IPv6 origin at the cut-off.
Route-origin security is another narrow weakness. RIPEstat's RPKI check returned unknown, with no validating Route Origin Authorisation. The route was not invalid and was visible everywhere in the sample. "Unknown" means relying networks had no cryptographic origin statement with which to validate AS47968 for this prefix. The existing route object can still support conventional filters, but it is not a substitute for RPKI origin validation.
The installed-versus-usable ladder is therefore short but clear. Delovaya has an assigned ASN, permission to originate a rented /24, a live BGP announcement and broad global propagation. Public evidence stops before responsive service inventory, traffic, line rate, headroom, customer availability and recovery performance. The visible 256 addresses are administrative and routing capacity. Usable capacity begins only when servers, voice trunks, customer circuits, power and staff all work together.
Three upstream names prove logical multihoming, not physical diversity
The current route has more than one public way out. RIPE's BGP-state view contained hundreds of collector paths on 10 July. Many ended AS50509 AS47968, others ended AS29076 AS47968, and others ended AS1299 AS47968. Those adjacent ASNs are Transroute, Citytelecom and Arelion. This is strong evidence that AS47968's one prefix was being propagated through three independently numbered networks.
Each supplier adds a different external reach. Arelion describes AS1299 as its global backbone. Citytelecom operates the network that maintains Delovaya's current address block. Transroute markets IP transit in Saint Petersburg and Moscow, with regional delivery through partners. The route paths are therefore consistent with two Russian carrier relationships and one global backbone relationship.
Logical multihoming is valuable. A policy fault or session loss at one adjacent network need not remove the route if another still accepts and propagates it. Delovaya can influence outbound traffic by local preference and inbound traffic through advertisements and communities. Arelion can provide a path that does not depend on Citytelecom's own global transit selection; Transroute can add another policy domain; exchange peering can shorten some routes.
It is still impossible to count three physical recovery paths from three ASNs. Arelion service may arrive through a local access circuit owned by another carrier. Transroute says it reaches some cities through partners. Citytelecom both supplies the address block and appears as an adjacent route. Two or all three services could terminate in one building, on one router, through one patch panel, on one local transport provider or across one shared entrance.
The route table cannot see cross-connects, fibres or power distribution. It will happily display three independent AS numbers when their handoffs share the same rack and fail with the same breaker. It can also display one adjacent ASN when that provider has supplied two physically separate circuits. Administrative diversity and physical diversity answer different questions.
The AS record itself illustrates why current observations matter more than static policy. Delovaya's RIPE WHOIS response declares import and export policy with AS31323 and AS31500 and was last modified in March 2022. Those are not the three dominant adjacent networks in the July 2026 BGP view. Static policy can be incomplete, use route-server relationships or simply lag operation. A current path proves propagation at one moment; a policy line records declared intent.
What would establish physical diversity is a dated handoff description: facility, carrier, port, router, entrance and transport owner for each path. It need not expose sensitive rack details. A statement that Arelion and Transroute enter separate sites, while Citytelecom terminates on a separately powered border, would be testable. A failover result showing packet loss, convergence time and remaining throughput would be stronger still. None is public.
PITER-IX adds reach, but its route server is not a fourth transit circuit
PITER-IX is visible around AS47968 without providing a simple entity card. One July route path ended directly at AS47968 from an exchange entity and carried communities beginning with PITER-IX's AS50817, including a community containing 47968. PITER-IX's technical documentation explains that entities establish BGP sessions with two route servers in each geography and that the exchange supports route-server policy, rapid failure detection and blackholing. Because an exchange route server normally does not insert itself into the public AS path, another entity can appear immediately adjacent to AS47968 even though the route was distributed through the server.
This is useful peering evidence, not proof of a dedicated bilateral cable to every apparent neighbour. A route server lets one connection exchange routes with many networks. Data packets then pass across the exchange fabric between the entities; the route server handles reachability information, not ordinary user traffic. A list of direct-looking AS paths can consequently exaggerate the number of physical contracts if it is read without exchange context.
The exchange's network description says its Saint Petersburg fabric spans six data centres and offers 1G, 10G, 40G and 100G ports. Its entities page says hundreds of organisations use its services. Those figures describe what PITER-IX can offer. They do not disclose which Saint Petersburg facility AS47968 uses, whether Delovaya connects locally or remotely, its port speed, committed traffic, second port or cross-connect route.
Peering is also not the same as full transit. An exchange entity receives routes that other entities choose to announce. It still needs a path to destinations not covered by those peers. The three observed transit-like adjacencies perform that broader role; PITER-IX can reduce latency and paid-transit use for participating networks and content sources. If all services share one exchange-facing port or one transport circuit, however, logical variety can disappear with one interface.
There is no AS47968 network profile in the current PeeringDB API. Absence from PeeringDB does not negate the BGP and exchange-community evidence. Participation records can be private, stale or maintained elsewhere. It removes a convenient source for checking facility, exchange, port and policy claims, leaving physical location and capacity unresolved.
The correct resilience conclusion is measured. Delovaya is not a single-upstream stub in the current public route view. Its /24 reaches the wider internet through several policy domains and an exchange environment. That is better control-plane diversity than many micro-networks show. The public evidence does not demonstrate that a cut, equipment-room outage or power failure would leave any of those alternatives physically available.
The five-server voice platform is the more plausible operating core
Business Telephony describes infrastructure that matches the current product more closely than a metropolitan access network. Its infrastructure page says all software runs on a cluster of five high-performance servers. It claims the servers are in different modern data centres, one in Germany; that every server has two internet channels; that another server automatically takes over when one fails; and that configurations are copied across the system with version control.
The architecture is plausible for hosted voice. A virtual PBX needs call-control software, customer configuration, databases, recordings or statistics, monitoring and connections toward telephone carriers. Multiple servers can distribute those roles or maintain standby copies. Geographic separation can reduce exposure to one facility. Replicated configuration can accelerate recovery from a failed machine or a harmful change.
The page is a marketing description, not a capacity or recovery report. It names no data centre, server location beyond one country, hosting supplier, telephony carrier, hypervisor, database replication method or quorum design. It gives no processor capacity, concurrent-call limit, storage volume, port speed, normal utilisation, recovery point, recovery time or date of the last failover test. "Five servers" can mean five physical machines, five rented virtual servers or five logical instances; the page does not say.
Two channels per server likewise do not guarantee independent access. Both can come from one carrier, one meet-me room or one facility edge. A server can have two network interfaces connected to the same switch. Two external carriers can share long-haul fibre. The claim becomes meaningful only with the local and upstream ownership of each channel, separate paths and a test showing sessions survive one loss.
The cluster claim also raises an application-state question. Moving a virtual PBX is not only a matter of announcing an IP address from another machine. Call registrations, active sessions, number routing, media paths, recordings, billing records and customer settings must remain consistent. A standby can accept new calls while dropping active ones; that is failover, but not seamless continuity. The site gives no measured call impact.
Current DNS reinforces the separation between public web presence and AS47968. On 10 July, Google Public DNS returned 87.236.16.146 for tel4biz.ru; the Delovaya domain returned the same address. RIPE's network view for that address places it in 87.236.16.0/24, originated by Beget's AS198610, not AS47968. Both websites can therefore remain online while Delovaya's own route or voice edge fails.
That does not locate the phone service. Public web hosting may be deliberately independent from the production voice platform. The five servers could use AS47968 addresses, provider addresses or both. No public service endpoint or name ties the application to a specific address inside 83.69.255.0/24. Website reachability is evidence of a live sales and contact surface, not a test of Delovaya's BGP origin or call processing.
The physical bill behind the evidenced business therefore looks more like a compact hosted platform than a city fibre build: data-centre or hosting charges, server capacity, storage, voice trunks, internet transit, address rental, monitoring and specialist support. Local access for a customer still matters, but the current partnership page places that function with communications operators rather than claiming it as Business Telephony plant.
The old internet offer is a hypothesis, not a network map
The Delovaya-branded site cannot simply be ignored. It remains online and contains detailed offers that go beyond voice. The homepage says the company connects and supports corporate telephony, internet and video surveillance. The internet page offers office service throughout Russia, promises rapid connection, describes fibre and markets two independent internet channels. It lists Saint Petersburg prices by speed tier.
Some language is specific enough to reveal the intended model. The site asks a prospective customer to submit an address so the company can check whether connection is possible. That is consistent with an aggregator or integrator obtaining service from whichever carrier reaches the building. It is less consistent with a provider that already knows its own fixed footprint and publishes an on-net map, although an owner-operator can also use manual availability checks.
The nationwide scope is another clue. A microenterprise can sell business circuits across a country by reselling or coordinating partners; it cannot plausibly dispatch an owned local crew from one city to every Russian address. The old site does not name access partners, explain on-net versus off-net pricing or identify who owns the customer demarcation. The two-channel offer similarly does not say whether the circuits use separate carriers or simply separate accounts.
The site's age limits current inference. Footer dates stop in 2017, the sitemap's visible modification dates are in 2017, and some pages use speed and pricing language characteristic of that period. A page can remain technically reachable long after the offer, partners and legal terms have changed. The current Business Telephony site has a 2026 footer and a different legal seller, but it does not repeat the broad internet-access promise as its main product.
The historical service claim still matters for interpreting AS47968. Delovaya may have used the ASN and address space to support business internet customers, voice infrastructure or both. Routing history shows genuine operation from 2016 under its present registration and a transition between provider-assigned prefixes. That is compatible with a small operator or reseller managing its own edge while buying the physical tails.
It does not establish installed access capacity. There is no published route-mile figure, fibre strand count, tower inventory, building list, microwave frequency, access-switch count, customer modem estate or subscriber number. No current procurement or construction record found in the public material connects Delovaya to a pole, duct or municipal route. The word fibre on a tariff page identifies the requested service technology, not necessarily the asset owner.
For a prospective business customer, the right question is not whether Delovaya can quote an internet circuit. It is which carrier owns the last mile at the specific address, whether the second circuit uses a different entrance and transport owner, and who has repair authority. A brokered dual-carrier design can be highly resilient. Two resold circuits over one incumbent cable can fail together. The seller name on the invoice does not answer the physical question.
A three-person company can promise 24/7 support only through concentration or partners
The labour signal is current but should be handled carefully. B2B.House's company record, drawing on Russian public-company data, reports average headcount falling from twelve in 2023 to eight in 2024 and three in 2025. It also reports 2025 revenue of 5.714 million roubles, down from 7.35 million in 2024 and 12.68 million in 2023. These are secondary presentations of official filings, not an audited explanation of operational roles.
Three employees do not mean only three people can touch the service. The current contracting identity is a sole proprietor; contractors, data-centre remote hands, software vendors and upstream network-operation centres may provide work outside Delovaya's payroll. The legal company and the Business Telephony brand may share labour. A reseller can escalate physical work to the access carrier. Public headcount cannot count those arrangements.
The number does define a concentration question. The current contact page says technical support is available around the clock, while sales operates on weekdays from 09:00 to 19:00. Continuous coverage requires either shifts, an on-call rotation, automation with escalation, outsourced first-line support or support shared across legal identities. With a three-person average payroll in the limited company, 24/7 human coverage cannot be assumed to sit entirely inside Delovaya.
The company's history emphasizes specialist knowledge: Asterisk, legacy PBXs, fraud monitoring, carrier equipment, office cabling and CRM integration. That breadth is valuable when one engineer understands an unusual customer configuration. It is also key-person exposure. A fault at 03:00 may need the one person who knows the routing policy or a customer's old PBX, while another person handles carrier escalation. The public pages give no rota, response target or named operations team.
Revenue puts the physical-asset hypothesis in context without disproving it. Five to thirteen million roubles of ordinary annual revenue, apart from a sharp 2022 spike shown by the aggregator, is compatible with a small service and integration business. It does not look like evidence of a large owned metro-fibre estate with construction, pole rent, vehicles and a broad field force. Assets can be leased, depreciated, held elsewhere or operated with contractors, so financial scale cannot settle ownership. It reinforces the need for direct plant evidence rather than assumption.
Support labour is part of usable capacity. A server cluster with automatic failover still needs someone to diagnose a partial fault, update carrier routes, restore customer configuration and decide when to move traffic. A multihomed edge still needs filtering, session monitoring and coordination with three upstreams. A resold access circuit still needs an accurate ticket, ownership handoff and customer communication. Small teams can do these tasks well; they have less room for simultaneous incidents, sickness or a specialist's absence.
The missing service-level details are practical: acknowledgement time, dispatch or escalation time, restoration objective, priority classes, after-hours authority and service credits. The current site promises an operative response but does not publish the contract behind the promise. For a customer whose sales depend on a virtual number, support availability is not a soft benefit. It is part of the infrastructure.
Six failure paths replace the generic image of a cut cable
The commissioned premise imagined access cuts, tower power, upstream loss, congestion and field repair. Delovaya's evidence supports a different and more layered failure set.
1. One upstream disappears while two remain
If AS1299, AS29076 or AS50509 loses its BGP session, the other adjacencies can continue to advertise 83.69.255.0/24. That is the strongest resilience property visible in public data. Recovery still depends on policy. Delovaya must withdraw or de-preference the failed path, the surviving providers must accept the route, and return traffic must converge correctly.
Survival is not the same as performance. If the three paths normally share traffic, one remaining circuit may congest during a failure. The route collectors expose path availability, not port speed or utilisation. No public figure shows peak traffic, headroom or whether one path alone can carry all voice and internet demand.
2. A shared facility or local tail removes all upstreams
Three AS numbers can terminate on one border router. One power fault, line-card failure, cross-connect accident, meet-me-room incident or common transport cut can then remove every session. PITER-IX may add many logical peers through the same port. The public sources name no facility and no second Delovaya site, so common-facility exposure remains unrefuted.
This is where field repair exists, but probably as carrier or data-centre labour. Remote hands may replace an optic or patch lead. Citytelecom, Transroute, Arelion's access partner or an exchange operator may repair transport. Delovaya's own staff may restore configuration. The recovery chain spans owners rather than one local trench crew.
3. Citytelecom changes the rented address arrangement
The current /24 is provider-aggregatable space maintained by Citytelecom. A routing or commercial problem can therefore affect both an upstream path and the address authority. If Delovaya must move to a new block, it may need to renumber servers, firewall rules, SIP allowlists, monitoring and customer integrations. The earlier prefix changes show that renumbering is not hypothetical as a class of work, although no current change is announced.
RPKI's unknown status adds a narrower risk. Networks that prefer validated routes may treat the announcement less favourably than a valid one. An incorrect future ROA could make the route invalid. Resource records, route filters and BGP sessions must change in the right order to avoid turning a planned migration into an outage.
4. The voice cluster fails above the network layer
All upstream paths can remain healthy while call processing fails. A software release, database inconsistency, storage fault, exhausted file system, certificate expiry, fraud-control error or carrier-trunk problem can stop calls without withdrawing the /24. Automatic server takeover helps only if the standby has correct state and the fault is not replicated.
Customers can experience partial failures: incoming calls work but outgoing calls fail; one city code breaks; recordings stop; the virtual PBX portal becomes unavailable; media flows one way; or new registrations fail while existing calls continue. A route monitor would report green throughout. Recovery needs application telemetry and telephony expertise, not a fibre splice.
5. The customer's access circuit or power fails
Hosted telephony still reaches a desk or software client over someone else's internet connection. A local broadband cut, office power outage, failed router, damaged Ethernet cable or misconfigured firewall can isolate one customer while Delovaya's platform remains healthy. Virtual-number forwarding to mobile networks may provide a workaround, but only if configured before the event and if the telephone carrier remains available.
The old Delovaya internet offer claims two independent customer channels. Without carrier and path disclosure, independence remains a design request. Both circuits can enter the same basement, use the same local operator or depend on the same building power. The customer must verify the physical demarcation rather than rely on two service names.
6. The small support chain is busy or unavailable
An incident can be technically recoverable and operationally delayed. A three-person limited-company payroll, an undisclosed relationship with the sole proprietor, multiple upstreams and nationwide customers create many ownership boundaries. The first person answering must decide whether the fault belongs to the PBX, AS47968, a data centre, a voice carrier, an access ISP or the customer.
Good monitoring shortens diagnosis, and the site claims continuous automated observation. It does not publish an incident channel, escalation matrix, spare policy or restoration performance. During two simultaneous faults, the scarce resource may be qualified attention rather than bandwidth.
Who is affected is narrower than a regional-ISP label suggests
No public evidence supports a count of Delovaya broadband subscribers, homes passed, connected buildings or downstream autonomous systems. RIPE's neighbour view found no downstream AS on the right side of AS47968's paths. Commercial address inventories identify a small ISP-like block, but they do not distinguish company servers from customers. An impact estimate based on 256 addresses would be meaningless.
The current product pages identify a more credible affected group: businesses using virtual Moscow, Saint Petersburg, Rostov-on-Don or toll-free numbers; customers using a hosted PBX, call recording, CRM integration or office-phone support; and operators whose subscribers receive first-line help through Business Telephony. The pages do not publish a customer count or show which services are current contracts, so even this group cannot be quantified.
A route outage would affect any endpoint that depends exclusively on 83.69.255.0/24. Because the websites are hosted in Beget's network, they may remain reachable and continue accepting enquiries while the Delovaya route is down. If the voice cluster also uses third-party addresses, some phone services could survive. If it depends on the /24, calls or management could fail. Public DNS does not settle the production path.
A data-centre or application failure can have the opposite shape. AS47968 remains globally visible, yet customer calls fail because the PBX, database or carrier trunk is unavailable. A customer-access failure affects one office while the platform and route remain healthy. An incident report must therefore test at least four layers: customer access, voice application, carrier interconnection and BGP reachability.
The legal identity matters during impact as well. A customer may contact the sole proprietor shown on the current site, while the failed route is registered to Delovaya Svyaz Ltd. and the address block is maintained by Citytelecom. That does not make recovery impossible; the control may be coordinated by the same owner. It makes contractual responsibility and escalation evidence important.
There is no basis for saying a Saint Petersburg district, public service or residential community would lose broadband if AS47968 failed. The old site claims broad office-internet availability but supplies no current customer or route. The responsible impact statement is conditional: a small set of business communications and network endpoints may depend on this stack, while the number and location of users remain undisclosed.
Capacity must be measured in calls, bits and recovery, not addresses
The public figures invite category errors. One /24 is an address quantity. Five servers are a machine count. Three upstream ASNs are a routing-policy count. None is a usable-capacity number.
For the internet edge, useful measures would include the line rate of each path, committed information rate, normal peak load, packet loss, latency and spare capacity after the largest circuit fails. A 10Gbps port with a 1Gbps commercial commitment does not provide 10Gbps of recoverable service. Three 1Gbps handoffs on one 1Gbps local transport do not create 3Gbps of external capacity.
For voice, capacity is closer to concurrent calls, calls per second, media bandwidth, number-porting throughput, recording input/output and database transaction rate. Codecs consume different bandwidth. Encryption and transcoding consume processor time. Call recording consumes storage and write performance. A five-server cluster can be ample or tiny depending on virtual-machine size, software design and customer demand.
The old internet page advertises customer speeds while the current phone site advertises very low per-minute prices and unlimited lines. Both are commercial offers, not evidence of installed headroom. "Unlimited" lines can mean no arbitrary account cap while every physical and software component still has finite capacity. The current pages do not publish a fair-use limit, trunk capacity or congestion performance.
Recovery capacity is the decisive figure. If one server fails, can the remaining four carry the peak load without dropping calls? If the largest upstream fails, can the others carry every route and packet? If one data centre is isolated, do number routing and state move to another site without manual carrier action? If a customer has two access circuits, can the backup accept the same voice policy and public addresses?
The company claims automatic server takeover and duplicated internet channels. Those are design claims at the right layer. A dated exercise would convert them into operating evidence: disable one server, record active-call loss, measure recovery time, show state consistency and report load on the survivors. Disable one upstream, measure BGP convergence and packet loss. Test the customer failover under normal busy-hour demand. No such result is public.
This is why the one /24 should neither be mocked nor celebrated. It is enough address space for a compact voice and network service, and its complete route visibility is technically meaningful. It is not enough information to judge service scale, customer density or resilience.
Current licenses and accounts support activity, but not the commissioned asset
The limited company's legal record supports a continuing communications role. Its main registered activity is telephone service. Current counterparty databases drawing on official records show two communications-license entries. One is described as data transmission for voice. The company filed 2025 accounts rather than disappearing after the old website stopped changing.
The license presentation is not perfectly consistent. T-Bank lists both licenses as current while its change log says activity under one license was suspended in January 2025. B2B.House shows two active entries and notes two earlier license records expiring in March 2026. Without a directly retrievable regulator extract that states service, territory and status in one current view, the safe conclusion is that communications licensing exists, not that every historic service authority remains unchanged.
A communications license is permission, not plant. It does not show an installed fibre route, an active customer circuit or sufficient staff. A telephone-services activity code similarly describes what the company may do and reports as its primary business. The current route, accounts and public service pages are needed to move beyond permission.
Together, those signals support Medium evidence for a live small routing and telephony operation. The company is active, has recent revenue, holds network resources, announces a prefix and remains associated with current sales and support channels through its owner. They do not support the planned picture of a conventional regional ISP whose local bill is dominated by poles, towers, customer drops and field crews.
The category question is therefore substantive, not cosmetic. A cloud-voice and telecom-integration service with a multihomed edge belongs closer to hosted communications or cloud service than to a last-mile regional ISP. Russia and Saint Petersburg are the evidenced geographic anchors, not an unqualified global operating region. Nationwide sales coverage is a market claim; "Global" is not a physical network location.
The evidence needed for a stronger claim is practical and finite
Delovaya could establish a regional-access role with a modest set of current disclosures. An address-level service checker that identifies on-net and partner-delivered buildings would separate owned reach from brokerage. A current access map could show fibre, fixed wireless or carrier resale without exposing exact security-sensitive routes. Customer contracts or tariffs could name the access owner and demarcation.
A plant statement would identify route miles, owned or leased fibres, access switches, towers, poles, building entrances and customer-premises equipment. It should distinguish installed cable from lit strands and customer-available capacity. A map of two logical routes is less useful than confirmation that they avoid common ducts, crossings, facilities and power.
The upstream case is already stronger. It needs physical completion: facility and port for AS1299, AS29076, AS50509 and PITER-IX; local transport owner for each; border-router and power separation; normal and failover capacity; and a current RPKI origin authorisation. Naming one second site would materially change the failure analysis if routes can continue there when the first site is dark.
The five-server claim needs application evidence. Facility names can remain partly confidential, but metropolitan area, independent power domain, hosting form and tested recovery time would be enough to judge whether "different data centres" removes a common point. The company could publish aggregate uptime, incident count, longest interruption and failover test results without identifying customers.
The labour boundary can be resolved through commitments rather than an organisation chart. State which legal entity provides support, whether 24/7 means staffed or on-call, acknowledgement and restoration targets, carrier escalation procedure, remote-hands coverage and where critical spares are held. If external partners provide the physical repair, name the role and contractual target rather than implying an in-house crew.
Finally, the brand needs a current contracting statement. A customer should be able to tell whether Delovaya Svyaz Ltd., Alexey Khramtsov as sole proprietor or another member of the Business Telephony group supplies each service. The statement should say which party holds the communications license, number assignment, platform, AS47968 route and support obligation. This is ordinary service clarity, not a request for private corporate detail.
Until those facts appear, the current route is the strongest operating evidence and the old access claim remains historical marketing. The gap is not filled by assuming failure. It is preserved as uncertainty.
Delovaya's real dependency is coordination across layers
Delovaya Svyaz is more technically substantial than its tiny public footprint first suggests. It has an active legal company, a long-running ASN, a globally visible IPv4 origin, three current upstream paths and exchange evidence. Its owner is still publicly selling business telephony. A five-server, multi-data-centre platform is claimed behind that offer. These facts justify continued attention.
They tell a different story from the commissioned title. No current source establishes a Delovaya last-mile network. The old site says internet can be connected widely; the current site says Business Telephony is not the operator and helps other operators' customers. The /24 is rented from a Citytelecom-maintained pool. The public websites run in Beget's network. Physical access, voice carriers, data centres and support may all sit with different providers.
That structure can be resilient. An integrator can buy better local access than it could build, use three routing partners, distribute applications across data centres and keep its public site outside its own ASN. It can also create a recovery chain in which every layer is waiting for another owner. The customer sees one phone number; the fault can sit in an office router, wholesale circuit, border session, address record, server, voice trunk or carrier database.
The visible route reduces one uncertainty: AS47968 was operating on 10 July 2026. Complete IPv4 visibility and three major adjacent ASNs are not design fantasies. The remaining uncertainty is physical and contractual. No route collector can show that the three paths avoid one building or that a technician can reach the failed handoff in an hour. No old tariff can show that Delovaya owns a fibre in today's street.
The most accurate description is therefore a live, small telephony and routing operation with meaningful logical connectivity and weak evidence for regional access. Its resilience bill is likely concentrated in transit, rented addressing, hosting, voice interconnection and specialist labour. Field repair matters when a carrier tail or data-centre handoff breaks, but public evidence assigns that work to the wider supplier chain, not to a verified Delovaya crew. The network exists. The local network in the planned premise has not been shown.