2026 Updates - Communications Service Provider (CSP) Platform

Communications Service Providers wanting to upgrade to the latest software version of the PeerEdge Platform can open a support ticket.

March 2026

603+ Call Blocking Feature.

Background

The Federal Communications Commission's Eighth Report and Order (FCC 25-15) adopted SIP 603+ requirements to fulfill the TRACED Act’s mandate for “transparency and effective redress” for callers whose calls are blocked based on reasonable analytics. The FCC established SIP 603+ as the exclusive, uniform response code for analytics-based blocking on IP networks, ensuring callers receive immediate and standardized notification that a call was “Network Blocked.”

This requirement is intended to help callers quickly understand when a call was blocked and why, and to provide sufficient information to identify and correct erroneous blocking. The FCC notes that SIP 603+ differs from standard SIP 603 by using the reason phrase “Network Blocked” and by requiring standardized Reason header fields that indicate analytics-based blocking and provide contact information for redress.

Exemptions / Scope Notes

• Do-Not-Originate (DNO) list blocking is not subject to the SIP 603+ notification requirement (the 603+ requirement is specifically tied to analytics-based blocking).

• Blocking performed at the request of a customer without the use of analytics is also treated differently; SIP code 607 may be used for its intended purpose (subscriber-directed blocking without analytics), and the FCC declines to mandate 607 because immediate notification is required only for analytics-based blocking.
  Note: “DNC” lists are not explicitly named in FCC 25-15; if your “DNC Conversion” behavior is customer-requested and non-analytics, it may fall into the “without analytics” category described above.

SIP 603+ Implementation Requirements (Analytics-Based Blocking)

• Status line (Reason Phrase): SIP 603+ must use the reason phrase “Network Blocked” (rather than “Decline”).

• Reason header: The Reason header must include standardized/mandatory text fields indicating the block was based on analytics and providing contact information for redress.

Prohibited Codes for Analytics-Based Blocking

Voice service providers must stop using the standard version of SIP 603, as well as SIP 607 and SIP 608, for analytics-based blocking once 603+ by 25 March 2026.

Transmission and Mapping Obligations

• Transparent forwarding: Any IP provider receiving a SIP 603+ response must transmit the full header, including all mandatory text fields, back toward the origination point.

• Network interoperability: Providers must ensure SIP 603+ maps appropriately to ISUP code 21 when calls traverse between IP and TDM networks.

PeerEdge Platform Update

The March update includes the software and configuration changes required to implement the FCC’s SIP 603+ requirements for analytics-based call blocking. Relevant PeerEdge failure responses have been updated to 603 with the SIP reason phrase “Network Blocked.” (This aligns with the FCC’s description of SIP 603+ using “Network Blocked” in the SIP Reason Phrase.)

46 Labs will roll this out to all customers during individual maintenance windows in early March 2026. Specific maintenance notifications will be sent to each service provider prior to the upgrade.

Expected Impact:  

During the scheduled maintenance window, the rebooting of the Traffic Switches (TS) which typically takes a couple minutes. The TS reboot process forcibly terminates all calls, which allows the PeerEdge to generate the CDRs.  For communication service providers with multiple locations, it is standard practice to do one location at a time. We generally recommend 2:00 – 4:00 am local time for the maintenance window.

Service Provider Actions Required

1. Review and update call blocking rules (if needed) in all termination and origination route plans.
If you would like a current list of blocking rules configured in your PeerEdge route plans, please email kelly.evans@46lab.com with the subject line: “blocking rules request”.   Note: For security reasons, the list will be provided only to a user with administrator access on the PeerEdge platform.   

46 Labs recommends consulting with your legal department to determine whether any PeerEdge static or dynamic lists used in your environment are considered analytics-based call blocking under the FCC framework. Note: The SIP Code and SIP Reason Phrase for termination route plan routing rules cannot be changed in the Portal.  Theses rules will need to be deleted, re-added and re-positioned.  If you have a lot of routing rules that need to be updated please contact kelly.evans@46lab.com to discuss options on how this can be completed in bulk.

The new default SIP Code and SIP Reason Phrase for a Block perform action is 603 and Network Blocked.

2. Verify and update (if required) the 603+ redress email address.  

The 603+ redress email address can be updated from the E-Mail tab in the General Settings page.

Although The Eighth Report and Order allows for a redress email address, phone number or web site, 46 Labs has only implemented the redress email method.  If you need a redress phone number or web site, please submit a feature request.

---

Call Connection Fee

A Call Connection Fee can be applied each time a call is successfully connected, regardless of call duration. This fee is in addition to per-minute rates. Connection fees apply only to calls from Termination Customer trunk groups.

To add connection fees

1. Add or edit a Termination Customer ratedeck.

2. Enable Connection Fee (this option is visible only when Direction = Termination and Relationship = Customer).
   When enabled, the CONNECTION FEE field appears in the file column-mapping list.

3. Upload a ratedeck file that includes a connection fee for each code (for example, NPANXX).
   In the CONNECTION FEE mapping field, select the CSV column that contains the connection fee values (for example, connection_fee, as shown in the image below).

Sample US & Canada Termination Customer Ratedeck 

 Example International Termination Customer Ratedeck

The Call Connection Fee can only be used with Termination Customer trunk groups and will always have a precision of 8 digits.

To include Connection Fees in the Invoices,  check the Show Connection Fee On Invoice option in the Invoice & Banking section (step 2) of the Invoice Template used to create the Invoice.

The Call Connection Fee will be shown in the Invoice in the following sections:

Summary of Usage

Each Trunk Group

Total Connection Fee

Vendor Media IP Blocking – Behavior Change

Previously, when the PeerEdge Orchestrator received a 183 Session Progress response with SDP containing a blocked/bad media IP from a termination vendor, it would send a SIP CANCEL toward both the customer and the vendor. In practice, vendors often send a 200 OK immediately after the 183, which can cause a race condition. Per RFC 3261, a 200 OK must be processed even if a CANCEL has already been sent, which could lead to calls being established and subsequent billing disputes.

Now, when Media IP Filtering is enabled on a Termination Vendor Trunk Group, the Orchestrator evaluates the SDP in the 200 OK. If the SDP contains an IP address that matches the trunk group’s Filter Media IP list, the Orchestrator proceeds as follows:

• Processes the 200 OK and the customer’s ACK as required by RFC 3261.

• Immediately after processing the ACK, it terminates the call by sending a SIP BYE to both the customer and the vendor.

This typically results in a CDR with a 1-second or less call duration. RFC 3261 requires BYE (not CANCEL) to terminate a call after a 200 OK has been received.  The CDR will have a sip_code (RELEASE CODE in UI) of 200, a sip_reason of OK, and a reason (RELEASE CAUSE in UI) of MEDIA_IP_BLACKLIST or occasionally BLOCK_NOT_CONFIRMED.

General Improvements and Bug Fixes for February 2026:

Implemented IP-based restrictions - New middleware to restrict API access based on IP addresses.

Added rack blocker for bot attacks – Introduced a Universal Security Middleware with behavioral pattern detection for blocking malicious requests.

Fixed ex_routing_rules fallback issue – Updated fallback handling in routing rules controller.

Fixed request.params issue - Resolved Rack parsing errors by checking UTF-8 text encoding before parsing parameters.

Trunk group model fix - Minor change to TrunkGroup model.

Relaxed security parameters - Increased limits in security middleware to accommodate API needs (higher parameter length, count, special char ratio).

IP Restriction Middleware tweaks - Minor adjustments to IP restriction middleware.

IP Restriction Middleware updates - Small fixes to IP restriction logic.

Added provisioning check - Simplified IP restriction middleware, added provisioning verification.