Identify the current managed-voice order and demarcation
Redcentric presents SIP trunks as external connectivity for an existing phone system within a wider voice-modernisation programme. Record the contracting entity, sites, numbers, PBX or SBC, access circuits, ordered channels, support entitlement, call-flow scope and responsible teams. Keep SIP trunking separate from cloud telephony, contact-centre work, endpoint replacement and adjacent managed services.
Translate the proposal into testable boundaries: provider handoff, customer edge, number-routing owner, access owner, security owner, monitoring point and support escalation. A named technical account manager or portal does not by itself define where a fault changes ownership.
Documented service facts
Reviewed 2026-10-15. Compare SIP trunk services →
SIP authentication
Not verifiedThe reviewed current pages do not publish whether a selected service uses registration, source-address trust, certificates or another control. Obtain the order-specific handoff and preserve the identity, allowed source, challenge behavior and secret owner without exposing credentials.
Registrar, proxy and DNS
Not verifiedNo current registrar, outbound proxy, DNS record, expiry, Contact policy or target order was verified. A legacy public service definition describes provider edge session border controllers as a demarcation, but that historical design is not evidence of a current customer handoff.
Numbers and inbound delivery
DocumentedThe current modernisation page includes number migration and management, call-flow design and cutover planning within possible project scope. It does not establish inventory, portability, port timing, delivered Request-URI or identity, or primary and alternate targets for a selected order.
Access and failover
DocumentedThe legacy PDF tied standard trunk failover to Redcentric-provided circuits and required professional-services design for third-party-network failover. Treat that as a historical acceptance question only: document today's circuits, route diversity, trigger, target order, recovery and commercial coverage from the current order.
Service and number coverage
Not verifiedRedcentric presents managed communications for UK organisations, but no complete current number-type, rate-centre, portability, international-destination or service-address matrix was verified. Qualify every site, number and calling direction against the current proposal and port records.
Codecs, DTMF and RTP
Not verifiedThe reviewed current pages do not publish one codec set, packetization interval, DTMF method, RTP range, transcoding rule or QoS handoff for all orders. Preserve offer and answer SDP, RTP tuples, markings, loss, jitter and decoded results from representative authorized calls.
Fax and analogue dependencies
Not verifiedNo current T.38, audio pass-through, analogue-adapter or fax-machine compatibility statement was verified. Inventory fax, alarms, lifts, door entry, payment and monitoring devices separately, and retain the approved replacement or acceptance result for each dependency.
Signaling and media protection
Not verifiedThe current pages discuss access control, patching and service readiness at programme level but do not define TLS versions, certificate validation, mutual authentication, SRTP profiles, keying or intermediary protection for the selected trunk. Require the ordered security profile and observed negotiation.
Channels and call starts
Not verifiedNo selected simultaneous-call pool, direction sharing, calls-per-second control, burst allowance or overload response was verified. Obtain the signed order and provider acceptance method, then test only within authorization with expected SIP responses and rollback thresholds.
Emergency calling
DocumentedThe legacy PDF discusses emergency-call availability and customer responsibility for location-address changes in its historical service context. Do not generalize that language to a current order. Obtain current eligibility, location validation, callback identity, propagation, failure behavior and an approved test procedure, while keeping an independent emergency method accessible.
Pricing, SLA and contract
Not verifiedNo durable public tariff, selected availability commitment, service-credit schedule or complete commercial term was verified. Preserve the quote, service schedule, channel and number charges, porting, installation, access, support, emergency, usage, term, renewal, suspension and cancellation rules.
Support, portals and demarcation
DocumentedRedcentric publishes customer account and technical account management, fault and maintenance communications, support contacts and customer portals. Those channels do not prove current service health, restoration time or the exact PBX, SBC, circuit and provider demarcation. Record responsibility and escalation for the selected order.
SMS and MMS
Not verifiedThe reviewed SIP-trunk and modernisation material does not establish SMS or MMS on the selected voice numbers. Treat messaging as separately ordered until number eligibility, registration, consent, throughput, API or portal behavior, retention, filtering and price are documented.
Separate current scope from the legacy technical design
The current modernisation page covers discovery, number porting, call-flow configuration, cutover testing, onboarding, documentation and operational support depending on scope. The public SD032 v2.1 PDF supplies useful historical questions about edge SBCs, access, quality of service and failover, but its data-centre, circuit and topology language must not be represented as the present service without a current order.
Obtain the issued handoff and service schedule. Preserve revision, registrar or proxy, authentication, source addresses, DNS behavior, transport and ports, codec and DTMF profile, RTP range, capacity, number routes and escalation. Compare loaded PBX state with that record rather than copying legacy examples.
Treat access and failover as one accepted topology
The legacy service definition made standard failover dependent on provider-supplied circuits and treated third-party-network failover as designed professional-services work. Use that only to ask the current provider which access paths, route diversity, addresses, edge targets and support boundaries are actually ordered. Do not infer resilience from two hostnames, two circuits or a managed-service label.
Draw every new-call path from PBX or SBC through LAN, firewall, access, provider edge and PSTN breakout. Record failure detection, target order, timers, alternate inbound behavior, DNS dependencies, established-dialog limits, restoration and rollback. Exercise only approved failures and keep observed signaling, media and user outcome separate.
Control number migration, call flows and emergency location
The current material describes number migration, call-flow design and cutover planning as possible project elements. Build a signed inventory of every number, service address, route, caller identity, dependency, port authority, activation window, temporary diversion and rollback owner. A project capability does not prove a number is portable or that a requested flow is loaded.
Treat emergency calling as a separate safety acceptance. The legacy PDF's address language belongs to its historical service context. Obtain today's eligibility, registered location, callback identity, update process, propagation time, outage behavior and provider-approved test method, and keep an accessible independent emergency method until acceptance is complete.
Qualify signaling, media, capacity and security
The reviewed current pages do not publish one universal authentication, DNS, codec, DTMF, RTP, TLS, SRTP or capacity profile. Retain authorized inbound and outbound SIP transactions, SDP, media tuples, QoS markings, decoded audio, DTMF results and the exact PBX or SBC object used. A successful registration, SIP response or portal indicator does not prove number routing, answer or two-way media.
Obtain simultaneous-call entitlement, direction sharing, call-start controls and overload response before load acceptance. Verify certificate names and trust, protocol and cipher, media keying, downgrade policy and every intermediary leg when protection is ordered. Keep fax, analogue devices and messaging in separate qualification records.
Accept cutover, support, service state and rollback
Redcentric publishes customer and technical account management, fault and maintenance communications, support contacts and portal access. Before cutover, record who monitors each boundary, raises and escalates cases, authorizes emergency routing, communicates maintenance, restores the former path and declares completion. Portal and status pages are operational channels, not proof of account health or restoration performance.
Run the approved plan for numbers, inbound and outbound identity, call flows, DTMF, media, security where ordered, capacity within authorization, failures, recovery, support and rollback. Preserve redacted evidence with the signed order and configuration export. No Redcentric service, circuit, PBX, packet, media stream or call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Redcentric voice modernisation ↗
- Redcentric communications services ↗
- Redcentric customer support ↗
- Redcentric service status ↗
- Redcentric SIP Trunking Service Description SD032 v2.1 (legacy public PDF) ↗
- Redcentric Hays telephony customer case study ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.