46 Labs will be proactively reaching out to all enterprise customers individually for scheduling the November 2026 Upgrade.
Table of Contents
- November 2026
- September 2026
- July 2026
- June 2026
- May 2026
- April 2026
- March 2026
- January 2026
- December 2025
- October 2025
- September 2025
- April 2025
- February 2025
November 2026
Original User-Agent pass-through for connections
Category: New Feature
PeerEdge area: SIP signaling
UI Path: Not applicable. 46 Labs Support turns on this feature for a connection.
Description: PeerEdge Orchestrator can now keep the original User-Agent header of calls that arrive on a connection. Before this release, PeerEdge Orchestrator always replaced the User-Agent with its own value. With pass-through on, in-dialog requests also keep the original User-Agent. If the caller sends no User-Agent, PeerEdge Orchestrator adds none. Pass-through is off by default.
Customer impact: When pass-through is on, the far end of the call sees the User-Agent of the device that placed the call.
Action required: No action is required. To turn on pass-through for a connection, open a ticket with 46 Labs Support.
Enhancements
TLS connections use port 5061 only
Category: Enhancement
PeerEdge area: SIP signaling and Microsoft Teams
UI Path: Not applicable. This is SIP signaling behavior with no portal setting.
Description: PeerEdge Orchestrator now accepts TLS SIP connections on port 5061 only. Before this release, a configuration setting selected port 5061 or port 5062 for TLS. Microsoft Teams Direct Routing signaling moved to a newer signaling software version, and it also uses port 5061 for TLS.
Customer impact: TLS connections to port 5061 do not change. After the upgrade, a device that sends TLS SIP to port 5062 cannot connect.
Action required: If a device or SBC sends TLS SIP to port 5062, change it to port 5061 before the upgrade. If you do not know which port your devices use, open a ticket with 46 Labs Support.
Bug Fixes
Calls rejected with SIP 500 and no CDR
Category: Bug Fix
PeerEdge area: Call routing
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: Some calls were rejected with SIP 500, and PeerEdge Orchestrator did not write a CDR for them. The cause was a large routing response that arrived in two parts in the wrong order. PeerEdge Orchestrator now waits a short time for the missing part. If the part does not arrive, it tries another routing server. If no routing server is left, it writes a CDR.
Customer impact: Fewer calls fail with SIP 500. A call that still fails has a CDR in CDR Search.
Action required: No action is required.
Negative call durations in CDRs
Category: Bug Fix
PeerEdge area: CDRs and reporting
UI Path: Reporting → CDR Search
Description: A repeated 200 OK response replaced the stored answer time of a call. When the repeated 200 OK arrived after the BYE, the CDR showed a negative duration. PeerEdge Orchestrator now keeps the first answer time.
Customer impact: The Duration column in CDR Search shows the correct value for these calls.
Action required: No action is required.
Release cause when an outbound TCP or TLS call cannot be sent
Category: Bug Fix
PeerEdge area: SIP signaling
UI Path: Home → SIP Reason
Description: PeerEdge Orchestrator now opens outbound TCP and TLS connections without a wait for each connection. If an outbound INVITE cannot be sent, the caller gets SIP 408 Request Timeout with the reason "Cannot create outbound socket".
Customer impact: When a TCP or TLS destination cannot be reached, the call fails with a SIP 408 and a reason that tells you why.
Action required: No action is required.
September 2026
Enhancements
Faster number upload and export for large number lists
Category: Enhancement
PeerEdge area: Numbering
UI Path: Numbering → Number, Numbering → Upload Status
Description: Number uploads and exports were slow for accounts with very large number lists. PeerEdge Orchestrator now uses indexed lookups for numbers, forwarding, manipulation rules, and emergency addresses.
Customer impact: Large number uploads and exports complete in less time.
Action required: No action is required.
Bug Fixes
Large number exports did not complete
Category: Bug Fix
PeerEdge area: Numbering
UI Path: Numbering → Number
Description: An export of a large set of numbers failed. The export now runs as a queued job and completes.
Customer impact: You can export large number lists.
Action required: No action is required.
July 2026
Bug Fixes
Wrong Forwarded status in the Number list
Category: Bug Fix
PeerEdge area: Numbering
UI Path: Numbering → Number
Description: A forwarding change made outside the enterprise portal did not always update the Number list. Examples are a change by 46 Labs Support, through the API, or by a bulk upload. The Number list then showed the wrong Forwarded status. Each addition, change, removal, and upload of a forwarding now updates the Forwarded status. A replace upload clears the status of numbers that lost their forwarding.
Customer impact: The Forwarded status in the Number list matches the forwarding in use.
Action required: No action is required.
June 2026
Bug Fixes
Microsoft Teams keepalive retries failed
Category: Bug Fix
PeerEdge area: Microsoft Teams
UI Path: Not applicable. This is Microsoft Teams Direct Routing behavior with no portal setting.
Description: When a keepalive OPTIONS request to Microsoft Teams got an error, PeerEdge Orchestrator closed the connection and tried again. The second try did not always use the same local address, so it failed. The second try now uses the same local address over a new connection.
Customer impact: After a connection error, the keepalive retry succeeds, so Microsoft Teams can keep the Direct Routing trunk active.
Action required: No action is required.
May 2026
Enhancements
Scanner traffic blocked at the enterprise portal web server
Category: Enhancement
PeerEdge area: Security
UI Path: Not applicable. This applies to the enterprise portal web server.
Description: The enterprise portal web server now closes requests from automated scanners before they reach the portal application. This applies to known probe paths, known scanner tools, and blocked IP addresses.
Customer impact: Normal portal use does not change. Less unwanted traffic reaches the enterprise portal.
Action required: No action is required.
April 2026
Bug Fixes
Stale TLS connections to Microsoft Teams
Category: Bug Fix
PeerEdge area: Microsoft Teams
UI Path: Not applicable. This is Microsoft Teams Direct Routing behavior with no portal setting.
Description: When a keepalive OPTIONS request to Microsoft Teams failed on a stale TLS connection, the request stayed failed. PeerEdge Orchestrator now closes that connection and tries once more on a new connection.
Customer impact: Microsoft Teams keeps the Direct Routing trunk available after a stale connection.
Action required: No action is required.
Microsoft Teams rejected calls with SIP 400 Bad Request
Category: Bug Fix
PeerEdge area: Microsoft Teams
UI Path: Not applicable. This is Microsoft Teams Direct Routing behavior with no portal setting.
Description: Outbound P-Asserted-Identity and Remote-Party-ID headers had no space between the quoted display name and the address. Microsoft Teams rejected these calls with SIP 400 Bad Request. PeerEdge Orchestrator now adds the space.
Customer impact: Microsoft Teams accepts these calls.
Action required: No action is required.
Wrong caller number when a display name contains a comma
Category: Bug Fix
PeerEdge area: SIP signaling
UI Path: Not applicable. This is SIP signaling behavior with no portal setting.
Description: PeerEdge Orchestrator read a P-Asserted-Identity display name with a comma, for example "LAST,FIRST", as two identities. It then sometimes used the wrong caller number. It now ignores commas in quoted display names.
Customer impact: Calls keep the correct caller number.
Action required: No action is required.
Wrong "not confirmed" release cause
Category: Bug Fix
PeerEdge area: CDRs and reporting
UI Path: Home → SIP Reason
Description: Since September 2025, PeerEdge Orchestrator releases an answered call that never gets an acknowledgement, with a "not confirmed" release cause. That cause also went to other calls, for example calls that the caller cancelled. PeerEdge Orchestrator now uses the cause only for calls whose release cause is otherwise normal clearing.
Customer impact: The release cause of a cancelled call shows the real cause.
Action required: No action is required.
Vendor release cause on calls that PeerEdge Orchestrator blocked
Category: Bug Fix
PeerEdge area: CDRs and reporting
UI Path: Home → SIP Reason
Description: For calls that PeerEdge Orchestrator blocked, the CDR showed a vendor failure, for example VENDOR_603. These blocks are the spam filter and response-code blocking. The CDR now keeps the block cause.
Customer impact: You can tell calls that PeerEdge Orchestrator blocked from calls that a vendor rejected.
Action required: No action is required.
March 2026
Ringback on Microsoft Teams transfers to listed numbers
Category: New Feature
PeerEdge area: Microsoft Teams
UI Path: Not applicable. 46 Labs Support adds the numbers to the ringback list.
Description: When a Microsoft Teams user transfers a call to a number on the ringback list, the caller now hears ringback until the transfer completes. Before this release, the caller heard the standard Microsoft Teams hold treatment. Ringback starts with the transfer and stops when the transfer target answers.
Customer impact: Callers hear ringback, not hold treatment, while a transfer to a listed number rings.
Action required: No action is required. To add a transfer target to the ringback list, open a ticket with 46 Labs Support.
Bug Fixes
Static noise on Microsoft Teams calls
Category: Bug Fix
PeerEdge area: Microsoft Teams
UI Path: Not applicable. This is Microsoft Teams Direct Routing behavior with no portal setting.
Description: Some Microsoft Teams calls had static noise during ringback. PeerEdge Orchestrator now accepts media on Microsoft Teams calls only from the expected source.
Customer impact: Microsoft Teams calls do not have this static noise.
Action required: No action is required.
Transfer targets saw the number of the Microsoft Teams user
Category: Bug Fix
PeerEdge area: Microsoft Teams
UI Path: Not applicable. This is Microsoft Teams Direct Routing behavior with no portal setting.
Description: After a Microsoft Teams user transferred a call from the public network, the transfer target saw the number of the Teams user. On transfers, PeerEdge Orchestrator now keeps the original caller number in the From, P-Asserted-Identity, and Remote-Party-ID headers.
Customer impact: The transfer target sees the number of the original caller.
Action required: No action is required.
Caller ID clean-up and E.164 format
Category: Bug Fix
PeerEdge area: SIP signaling
UI Path: Not applicable. This is SIP signaling behavior with no portal setting.
Description: Caller IDs shorter than 7 characters kept characters that are not digits. The test for a leading plus sign (E.164 format) sometimes ran on the wrong value. PeerEdge Orchestrator now reduces every caller ID to digits after the plus sign test. A CDR shows an empty caller ID as "unknown".
Customer impact: Caller IDs reach the far end as digits only, and the E.164 format is detected correctly.
Action required: No action is required.
January 2026
Bug Fixes
Maximum call duration of a connection not enforced
Category: Bug Fix
PeerEdge area: Call routing
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: From September 2025, PeerEdge Orchestrator limited every answered call to a fixed 4 hours and ignored the maximum call duration of the connections. Each in-dialog acknowledgement also started the timer again. PeerEdge Orchestrator now applies the shorter maximum call duration of the two connections of a call. It sets the limit once, when the call is set up.
Customer impact: Calls end at the maximum call duration that is set for the connection.
Action required: No action is required.
December 2025
Enhancements
Diversion headers kept as received
Category: Enhancement
PeerEdge area: SIP signaling
UI Path: Not applicable. This is SIP signaling behavior with no portal setting.
Description: PeerEdge Orchestrator now keeps each Diversion header of a call as received and changes only the host part to its own address. Before this release, it rebuilt only one Diversion header and did not rewrite calls with more than one.
Customer impact: The far end receives the full diversion history of a forwarded call.
Action required: No action is required.
INFO in the Allow header
Category: Enhancement
PeerEdge area: SIP signaling
UI Path: Not applicable. This is SIP signaling behavior with no portal setting.
Description: The Allow header that PeerEdge Orchestrator sends now lists INFO.
Customer impact: Devices can send in-dialog INFO requests, for example for DTMF.
Action required: No action is required.
Bug Fixes
Wrong TCP port after a call was answered
Category: Bug Fix
PeerEdge area: SIP signaling
UI Path: Not applicable. This is SIP signaling behavior with no portal setting.
Description: When a customer device answered a call over TCP, PeerEdge Orchestrator sometimes read the TCP port from the wrong Record-Route header. Later in-dialog requests then sometimes went to the wrong port. PeerEdge Orchestrator now reads the correct header.
Customer impact: In-dialog requests, for example BYE, reach the correct port of TCP devices.
Action required: No action is required.
Wrong number taken from trusted Diversion headers
Category: Bug Fix
PeerEdge area: Call routing
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: On connections that trust the Diversion header, a call with more than one Diversion header used the number from the first header. PeerEdge Orchestrator now uses the number from the last header as the caller identity.
Customer impact: Calls with several Diversion headers get the correct caller identity.
Action required: No action is required.
Forward on failure to an inbound route went to the original number
Category: Bug Fix
PeerEdge area: Call routing
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: When a number was set to forward on failure to an inbound route, PeerEdge Orchestrator routed the call to the original dialed number again. It now routes the call to the forward-to number.
Customer impact: Forward on failure reaches the forward-to number.
Action required: No action is required.
October 2025
Diversion header on forwarded number calls
Category: New Feature
PeerEdge area: Call routing
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: When a number forwarding rule forwards a call, the outbound INVITE now carries a Diversion header with the original dialed number and the reason "unconditional". Before this release, the forwarded call had no record of the original dialed number.
Customer impact: The forward-to destination can see which number the caller dialed. The CDR also stores that number.
Action required: No action is required.
Bug Fixes
SIP 408 timeouts replaced by SIP 500
Category: Bug Fix
PeerEdge area: SIP signaling
UI Path: Not applicable. This is SIP signaling behavior with no portal setting.
Description: Each SIP 408 response made PeerEdge Orchestrator retry the call on another internal server. When no server was left, the caller got SIP 500 "No TS Available". A SIP 408 from the call path now goes back to the caller.
Customer impact: Callers get the real SIP 408 timeout, not a SIP 500.
Action required: No action is required.
Calls continued with no audio after a media setup failure
Category: Bug Fix
PeerEdge area: Media
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: After a media setup failure, a call continued with no working audio. PeerEdge Orchestrator now rejects a new call with SIP 503 Service Unavailable. It releases an established call after a failed media update.
Customer impact: Calls do not stay connected with no audio.
Action required: No action is required.
September 2025
Enhancements
Protection against REGISTER floods
Category: Enhancement
PeerEdge area: Security
UI Path: Not applicable. This is SIP signaling behavior with no portal setting.
Description: PeerEdge Orchestrator now accepts at most 6 REGISTER requests per second from each user and domain in the From header. It drops the extra requests. This also applies to Microsoft Teams Direct Routing connections.
Customer impact: Normal device registration does not change. A device that floods REGISTER requests cannot overload registration.
Action required: No action is required. If a device sends more than 6 REGISTER requests per second, correct its registration settings.
Bug Fixes
Answered calls with no acknowledgement stayed up
Category: Bug Fix
PeerEdge area: Call routing
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: A call that was answered but never acknowledged sometimes stayed up. PeerEdge Orchestrator now waits 16 seconds for the acknowledgement. Then it releases the call with a "not confirmed" release cause.
Customer impact: Calls that never complete setup do not stay up.
Action required: No action is required.
Late responses changed the SIP code of answered calls
Category: Bug Fix
PeerEdge area: CDRs and reporting
UI Path: Reporting → CDR Search
Description: A late SIP 408 timeout from a route that lost sometimes replaced the SIP code of an answered call in the CDR. Response manipulation rules also acted on that late response. PeerEdge Orchestrator now records and changes only the response of the active route.
Customer impact: The SIP code column in CDR Search shows the correct value for answered calls.
Action required: No action is required.
Account missing on CDRs of loop-blocked calls
Category: Bug Fix
PeerEdge area: CDRs and reporting
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: The CDR of a call that loop detection rejected sometimes had the connection but no account. The CDR now has the account.
Customer impact: CDRs of loop-blocked calls show the account of the call.
Action required: No action is required.
Request-URI host and port rules wrote the wrong values
Category: Bug Fix
PeerEdge area: SIP signaling
UI Path: Not applicable. This is SIP signaling behavior with no portal setting.
Description: A Request-URI rule that replaced the host, or the host and port, wrote the matched values instead of the new values. PeerEdge Orchestrator now writes the replacement host and port from the rule.
Customer impact: Request-URI host and port rules work as set.
Action required: No action is required.
Default ports in the Request-URI
Category: Bug Fix
PeerEdge area: SIP signaling
UI Path: Not applicable. This is SIP signaling behavior with no portal setting.
Description: On TLS calls, the outbound Request-URI kept the port ":5061". PeerEdge Orchestrator now leaves out the default port of each transport, 5061 for TLS and 5060 for UDP and TCP. It still shows other ports.
Customer impact: Devices that reject an explicit default port accept these calls.
Action required: No action is required.
April 2025
Bug Fixes
Trunk value carried over between calls
Category: Bug Fix
PeerEdge area: Security
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: A trunk value from an earlier call sometimes went into the trunk authentication of the next call. PeerEdge Orchestrator now clears the value at the start of each call.
Customer impact: Each call is authenticated with its own trunk values.
Action required: No action is required.
Early audio passed when early media was off
Category: Bug Fix
PeerEdge area: Media
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: With early media off, PeerEdge Orchestrator changed only 183 responses to plain ringing. A 180 response with media still passed early audio. PeerEdge Orchestrator now changes every ringing response with media to a plain 180 Ringing.
Customer impact: When early media is off, callers do not hear early audio.
Action required: No action is required.
February 2025
Ring timeout per connection
Category: New Feature
PeerEdge area: Call routing
UI Path: Not applicable. 46 Labs Support sets the ring timeout of a connection.
Description: The ring timeout of the connection that sends a call now limits how long the call rings. Before this release, a call rang for a fixed 240 seconds. If the connection has no ring timeout, the limit is still 240 seconds.
Customer impact: Unanswered calls stop ringing at the ring timeout of the connection.
Action required: No action is required. To change the ring timeout of a connection, open a ticket with 46 Labs Support.
ICE setting for Microsoft Teams connections
Category: New Feature
PeerEdge area: Microsoft Teams
UI Path: Not applicable. 46 Labs Support changes the ICE setting of a connection.
Description: Interactive Connectivity Establishment (ICE) is a method that Microsoft Teams uses to set up media. PeerEdge Orchestrator always used ICE on Microsoft Teams calls. Each connection now has an ICE setting. When ICE is off, PeerEdge Orchestrator removes ICE from the media offer of the Teams call. Existing connections keep ICE on.
Customer impact: If a Microsoft Teams call has media setup problems, 46 Labs Support can turn off ICE for that connection.
Action required: No action is required. To turn off ICE for a connection, open a ticket with 46 Labs Support.
Bug Fixes
Calls cancelled at the moment of answer
Category: Bug Fix
PeerEdge area: CDRs and reporting
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: When the caller hung up at the same moment as the far end answered, the answer time went missing and the CDR showed a cancel. PeerEdge Orchestrator now records the answer time of every answer and releases the answered call at once.
Customer impact: The CDR of these calls shows the answer and a normal clearing.
Action required: No action is required.
Webex calls got Microsoft Teams media handling
Category: Bug Fix
PeerEdge area: Media
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: Webex calls got the media handling that is only for Microsoft Teams. Webex calls now get their own handling. If a Webex re-INVITE offers ICE, PeerEdge Orchestrator keeps it. If not, PeerEdge Orchestrator removes ICE.
Customer impact: Webex calls, for example a move into a conference, set up media correctly.
Action required: No action is required.
CDRs of calls to forwarded numbers
Category: Bug Fix
PeerEdge area: CDRs and reporting
UI Path: Not applicable. This is call routing behavior with no portal setting.
Description: The CDR of a call that a number forwarded to another connection showed the direction and type of the wrong connection. The CDR now shows the direction and type of the correct connection.
Customer impact: CDRs of forwarded calls show the correct connection details.
Action required: No action is required.
Caller number missing on failed inbound calls
Category: Bug Fix
PeerEdge area: CDRs and reporting
UI Path: Reporting → CDR Search
Description: An inbound call that failed with "not found" had no caller number in its CDR. PeerEdge Orchestrator now saves the caller number.
Customer impact: The ANI column in CDR Search shows the caller number of these calls.
Action required: No action is required.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article