2026 Updates - Communications Service Provider (CSP) Platform

46 Labs will be proactively reaching out to all Communication Service Providers individually for scheduling the July (Not August) 2026 Upgrade. 

August 2026 (coming soon)

Auth0 Authentication

Background

The PeerEdge Orchestrator has transitioned from locally managed usernames and passwords to Auth0 Universal Login. The Subscriber, Agent, and Relationship portals now authenticate users through their configured Auth0 organizations.

This centralizes authentication in Auth0 while allowing PeerEdge Orchestrator to continue enforcing portal permissions, relationship access, and other application-level authorization controls.

Platform Updates

The PeerEdge Orchestrator now use the Auth0 v2 client library. User sessions are renewed using refresh tokens stored in browser memory instead of hidden browser frames. This approach provides more reliable session renewal in browsers that block third-party cookies or restrict cross-site tracking.

The PeerEdge API now:

• Validates Auth0-issued access tokens before allowing access to protected resources.
• Prevents an access token associated with a signed-out session from being reused for the remainder of the token’s original lifetime.
• No longer performs local password authentication through the legacy direct-login and portal-login API operations.
• Directs password reset and password change requests through Auth0 instead of processing them through PeerEdge.
• Supports Relationship Portal users associated with multiple carriers by loading the first available relationship when no relationship has been explicitly selected.
• Continues to honor the selected relationship whenever the portal includes a relationship identifier in the request.

Benefits of Auth0

The transition to Auth0 provides several security and usability benefits:

• Centralized identity management: Authentication policies and user identities can be managed consistently through Auth0.
• Reduced password-handling risk: PeerEdge no longer needs to directly authenticate or manage users’ local passwords.
• Improved browser compatibility: Refresh-token-based session renewal avoids dependence on hidden frames and third-party cookies.
• Standards-based authentication: Auth0 uses established OAuth 2.0 and OpenID Connect protocols for issuing and validating tokens.
• Organization-based access: Auth0 organizations provide a structured way to associate users with the appropriate PeerEdge portal environment.
• Improved sign-out protection: Access tokens from signed-out sessions are prevented from being reused, even if they have not yet reached their normal expiration time.
• Extensible security controls: Auth0 can support capabilities such as multifactor authentication, enterprise identity-provider integration, password policies, and anomaly detection when those features are configured.
• Consistent account recovery: Password resets and password changes are handled through a common Auth0-hosted workflow rather than separate portal-specific processes.

This update modernizes PeerEdge authentication, improves session reliability, and separates identity verification from application-level authorization and carrier access.

Expected Operator (PeerEdge user) Experience

Operators are directed through the Auth0 Universal Login experience when signing in. Session renewal occurs without storing the Auth0 refresh token in browser local storage.

When an unauthenticated user attempts to login to the PeerEdge Orchestrator, the user will be presented with the Auth0 enabled login page.  If the Operator's username that is configured in the PeerEdge Orchestrator is a Google or Microsoft account then click on the appropriate button.  Otherwise enter the Operator's username (email address) and password and click the Continue button. 

The screenshots below illustrate the Continue with Microsoft sign-in process. 

Step 1.  Enter your Microsoft Entra ID in the Sign in box and click Next

Step 2. If presented with the Approve sign in prompt then enter the code provided in the Microsoft Authenticator app to login.

Step 3.  If the Stay signed in? dialog box is presented. Click Yes or No as appropriate.  

The below screenshots explain the username (email address) and password login process.

Step 1. Enter your PeerEdge Orchestrator username (email address) and password and click the Continue button.

Step 2 (first time login). If you have not associated your PeerEdge Orchestrator account with an authenticator app (e.g. Microsoft, Google, Okta, etc.) you will be presented with the following screen.  Open your preferred authenticator app and use the app's scan code feature to add the account to the authenticator app.

Then enter the displayed code to login.

Step 2 If you have already associated your PeerEdge Orchestrator account with your preferred authenticator app then the below screen will appear.  Provide the code from the authenticator app and click the Continue button to login to the PeerEdge Orchestrator.  Optionally you can check the "Remember this device for 30 days" to potentially reduce the number of times you need to login.

WARNING:  By design, the implementation of Auth0 prevents the use an Operator's (PeerEdge user) JSON Web Token (JWT) for use in API scripts or automation. Any existing API scripts using an Operator's JWT will NOT work after this upgrade.  These API scripts will need to be updated to use a Secure Personal API Token for authenication. 

Secure Personal API Tokens

API Token Background

Personal API tokens allow an authorized PeerEdge Orchestrator user to call supported APIs from scripts, automation, or continuous integration systems. Because a token has the access of the user who created it, token creation and storage require additional safeguards.

API Token Platform Update

API token creation is now protected by an emailed six-digit verification code. The verification code expires after five minutes and is invalidated after five incorrect attempts.

The feature includes the following controls:

• API Tokens must be enabled for the service provider's account.
• Token management is restricted by the portal's administrative access rules.
• Subscriber portal users cannot create a token while impersonating another user.
• Token creation and verification-code requests are rate limited.
• Token creation and revocation are recorded in the General Logs audit history.
• The account's main user is notified when a token is created.
• Expiration notifications are sent before a token expires.
• The complete token is displayed once. PeerEdge stores a cryptographic digest instead of the complete token.
• Available expiration periods are 1, 7, 30, or 90 days.

To Generate an API Token

1. Open API Tokens:
   • In the subscriber portal, go to Settings > General > Other (The example shown below).
   • In the agent portal, select API Tokens from the navigation menu.
   • In the relationship portal, open Settings > API Tokens.
2. Select Generate Token.
3. Enter a token name and select an expiration period.
4. Select Send Verification Code.
   
5. Enter the six-digit code sent to the email address associated with the current operator.
   
   
   
6. Select Generate.
7. Copy the token when it is displayed. The complete token cannot be displayed again. Check the I Have Stored This Token Securely checkbox and then click the Done button.

To Revoke an API Token

1. Open API Tokens.
2. Locate the token.
3. Select the revoke action.
4. Confirm the request.

The token stops working immediately after it is revoked.

July 2026

The July 2026 update includes expanded STIR/SHAKEN policy and CDR data, Inline Documentation, and reliability improvements and more for PeerEdge platform services.

Global STIR/SHAKEN and SPID Filtering

STIR/SHAKEN Background

STIR/SHAKEN Identity headers identify the certificate used to sign a call. A Service Provider Code (SPID) can be derived from supported certificate subject formats and used as part of call-treatment policy.

A SPID is a unique code assigned to a telecommunications service provider. In a STIR/SHAKEN certificate, the SPID will appear as the Service Provider Code (SPC) within the certificate’s Subject field. It identifies the service provider authorized to use the certificate to digitally sign calls. In North America, the identifier is typically an Operating Company Number (OCN) or equivalent provider code. The SPID/SPC identifies the signing provider; it does not identify the individual caller, establish ownership of a particular telephone number, or determine the call’s A, B, or C attestation level.

STIR/SHAKEN Platform Update

PeerEdge now supports global and trunk-group STIR/SHAKEN SPID blocklists. Global policy and trunk-group policy are synchronized to the Traffic Switches and evaluated during call processing.

This update includes:

• Global SPID blocklist enablement.
• Global and trunk-group SPID filter records.
• Separate inbound and outbound SPID filter treatment.
• Support for four digit SPIDs consisting of three digits followed by a uppercase letter*.
• Support for additional certificate Common Name formats observed in deployed certificates.
• Certificate retrieval from the URL in the Identity header.
• Certificate validation and cached certificate metadata.
• Configurable SIP response codes and reason phrases associated with SPID filter records.

When a call is blocked by a SPID filter, the CDR identifies whether the global, inbound, or outbound filter produced the result.

* Although all modern and new SPIDs are three digits followed by a uppercase letter, Legacy SPIDs can be 4 digits (1234), 3 uppercase letters  and 2 digits (ABC12), or 4 uppercase letters + 2 digits (ABCD12).  The PeerEdge supports these additional SPID shapes for compatibility. 

Global SPID blocking

Global SPID blocking occurs before identifying any egress trunk group. 

Configuring Global SPID Blocking

To enable Global SPID Blocking click the enable checkbox in the Global SPID Blocking page accessible from the Tools menu and then click the Enable button in the Enable SPID Block pop-up dialog box.

To add a SPID to the Global list, click the + Add to SPID Filter button. Enter the SPID, Reply code and Reply Reason and click the Add SPID Filter button.

To delete a SPID from the Global SPID Blocking list, click the horizonal ellipsis to the right of the SPID, select Delete and the click the Delete SPID Filter button.

Trunk Group STIR/SHAKEN and SPID Filtering enhancements

Trunk-group-level SPID blocking occurs at different points depending on where it is configured.

Ingress (Termination Customer or Origination Vendor)  Trunk Group 

The SPID check occurs after PeerEdge determines the available egress routes, but before it begins processing or sending the call to an egress trunk group.

If the SPID matches the ingress trunk group’s blocklist, PeerEdge rejects the call immediately using the configured SIP response code and reason.

Egress (Termination Vendor or Origination Customer) Trunk Group

The SPID check occurs after PeerEdge selects a specific egress trunk group, but before it sends the call to that trunk.

If the SPID matches the egress trunk group’s blocklist, PeerEdge blocks the call using the configured SIP response code and reason.

In summary:

Ingress SPID blocking: After route selection, before egress processing.

Egress SPID blocking: After selecting an egress trunk group, before sending the call to it.

SPID blocking impact on CDRs

When SPID blocking occurs, the failed-call CDR records both the blocking location and the STIR/SHAKEN identity details.

Blocking result fields

stir_status

    Global block: GL_SPID_FILTER

    Ingress trunk-group block: IN_SPID_FILTER

    Egress trunk-group block: OUT_SPID_FILTER

release_cause_internal: SS_SPID_FILTER

sip_code: The SIP response code configured on the matching SPID filter.

sip_reason: The SIP reason configured on the matching SPID filter.

Identity and certificate fields

These are populated from the received Identity header and its signing certificate when available:

stir_spid: The SPID that matched the blocklist.

stir_cert_cn: Signing certificate Common Name.

stir_cert_org: Signing certificate organization, if present.

stir_x5u: Signing certificate URL.

stir_attest: Attestation level.

stir_orig_id: PASSporT origination identifier.

stir_orig_tn: Originating telephone number from the PASSporT.

stir_dest_tn: Destination telephone number from the PASSporT.

stir_iat: PASSporT issued-at timestamp.

Trunk-group identification

For a global or ingress trunk-group block, orig_trunk_group_id is populated, but term_trunk_group_id is normally empty because PeerEdge has not begun processing an egress trunk-group candidate.

For an egress trunk-group block, both orig_trunk_group_id and term_trunk_group_id are populated. The terminating ID identifies the egress trunk group whose SPID policy blocked the call.

Certificate fields can be empty when the corresponding value is unavailable, but stir_spid must be present for an SPID filter match to occur.

Configuring Trunk Group level SPID Blocking

To enable SPID Blocking for a Trunk Group, go to the Trunk Group's Stir/Shaken tab, click on the Enable SPID Blocking and click the Save button.

Previously to enable SPID Blocking Stir/Shaken Certificate Verification also had to be enabled this is no longer a requirement for SPID Blocking.

To add a SPID to the SPID Filter list, enter the SPID, Reply Code and Reply Reason and click the Add SPID Filter button.

Previously a Subject Filter Regex used instead a a SPID.  During the update all configured regex filters will be converted to SPIDs (assuming the SPID shape was included in the regex). 

To delete a SPID from the SPID Filter list, click the horizonal ellipsis to the right of the SPID, select Delete and the click the Delete SPID Filter button.

Expanded STIR/SHAKEN and CDR Information

STIR/SHAKEN CDR Information

PeerEdge CDRs now include additional information about STIR/SHAKEN processing:

• stir_cert_cn — certificate Common Name.
• stir_cert_org — certificate organization.
• stir_spid — Service Provider Code derived from the certificate.
• stir_status — the result of signing, verification, certificate validation, attestation policy, or SPID filtering.
• stir_x5u — the certificate URL supplied in the Identity header.

Calls signed by the local PeerEdge platform are attributed with the Common Name, organization, and SPID from the configured signing certificate. The SIGNED_OK status distinguishes calls signed locally from calls that completed other STIR/SHAKEN processing successfully.

The CDR Diagnostics export includes the STIR/SHAKEN certificate organization for environments where the STIR/SHAKEN export columns are enabled.

Inline Documentation

PeerEdge operators can now access product documentation directly from the Subscriber Portal's Documentation Home page under the Help menu or at the https://<platform-url>/docs route. The documentation includes operational guidance for relationships, trunk groups, routing, reporting, tools, settings, STIR/SHAKEN, E911, FAQs, and common terminology.

Authentication is not required to access /docs. Operators who are signed in can return to the PeerEdge dashboard.

The documentation is currently about 80% complete.  If you believe that there are inaccuracies with the documentation or would like to see the documentation cover additional topics then please send an email to docs@46labs.com.

Database Synchronization Update

PeerEdge database synchronization tasks now run as four independent schedules:

• Main platform and trunk configuration — every minute.
• Routing rules and miscellaneous data — every minute.
• ANI, DNIS, prefix, LRN, and related lists — every 15 minutes.
• Hourly synchronization tasks — at the top of each hour.

Separating these schedules prevents a problem in one synchronization role from stopping the other roles from running. Service start limits were also changed so that the scheduler continues attempting synchronization after repeated failures.

This is an operational reliability change; it does not add a new PeerEdge Orchestrator configuration screen.

General Improvements and Bug Fixes for July 2026

• Connection fee has been added to the following reports:
  • Destination Performance Report
  • Hourly Destination Performance Report
  • LATA OCN Report
  • Relationship Percentage Report
• Auth0 carrier selection fix — Relationship portal authentication now selects the first available carrier when a carrier identifier has not yet been supplied, preventing the initial portal request from failing for users associated with multiple carriers.
• API Tokens visibility fixes — The agent route and relationship settings tab now follow the account-level API Tokens setting. Relationship portal token status labels were also corrected.
• STIR/SHAKEN signed-call status fix — Calls signed by the local PeerEdge platform now retain the SIGNED_OK CDR status instead of being reported with the generic OK status.
• STIR/SHAKEN certificate parsing improvements — Certificate processing now recognizes additional real-world Common Name formats when deriving the SPID.
• STIR/SHAKEN signed-call attribution — Locally signed calls now include the signing certificate Common Name, organization, and SPID in CDR data.
• CDR upload compatibility fix — CDR upload accepts records with more fields than the configured database mapping requires.
• Failed CDR formatting fix — Failed flat-file CDR records no longer receive an extra empty trailing field.
• Unrated CDR alert fix — CDR pruning no longer rolls back the monitoring alert created when unrated calls prevent pruning.
• Database synchronization recovery — Synchronization timers continue firing after repeated failures, and separate task schedules reduce the effect of an individual synchronization failure.
• PeerEdge configuration lookup fix — The API reads the first valid PeerEdge IP-location configuration file instead of combining duplicate files exposed through legacy compatibility links.
• Routing simulation response fix — Routing simulation accepts the successful HTTP response text without depending on capitalization.
• Portal security logging improvement — Portal web-server access logging no longer includes request credentials.
• Portal rendering and configuration fixes — Shared styling, production environment injection, and development route-location handling were corrected following the portal consolidation.
• Monitoring installation fixes — Zabbix agent installation and old configuration cleanup were corrected for PeerEdge package deployment.

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 Mid-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 spam blocking rules (if needed) in all termination and origination route plans.
If you would like a current list of spam blocking rules configured in your PeerEdge route plans, please email kelly.evans@46labs.com with the subject line: “spam 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.  If you need to change either the SIP Code or the SIP Reason Phrase for existing rules, then the rules will need to be deleted, re-added and re-positioned.

The new default SIP Code and SIP Reason Phrase for a Spam Filter's Block Traffic 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.

PeerEdge Orchestrator 603+ FAQs

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.

Important: Revenue in reports such as the Relationship Report and Hourly Performance Report includes the Call Connection Fee. It is calculated across all CDRs in the selected time range as:   SUM(revenue + COALESCE(fee_connect, 0))

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 (e.g each 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 in rate decks associated 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.