sip5060.net / en es

RSS Atom

Planet SIP

April 10, 2025

• Digium How Hotels Can Use Unified Communications to Deliver High-Quality Guest Experiences Across Every Brand Location

  If your hotel brand can’t deliver a consistent guest experience across every property, you’re losing trust—and revenue. Guests expect the same level of service whether they’re checking in at your flagship resort in Miami or your boutique property in Denver. But for most hotel groups, delivering that kind of consistency isn’t easy. Disconnected communication tools, […]

  The post How Hotels Can Use Unified Communications to Deliver High-Quality Guest Experiences Across Every Brand Location appeared first on Sangoma Technologies.

April 09, 2025

• Digium Easy UCaaS Migration and Deployment: Best Practices and Challenges

  Let’s face it: launching a UCaaS (Unified Communications as a Service) system from scratch is daunting. This type of cloud phone system incorporates many different types of communication/collaboration services to help your business succeed, including voice, video, messaging, meetings, presence, and team-based collaboration. And while the hallmark of a UCaaS environment is its ability to bring […]

  The post Easy UCaaS Migration and Deployment: Best Practices and Challenges appeared first on Sangoma Technologies.

April 08, 2025

• Digium What is UCaaS? A Complete Guide to Unified Communications as a Service

  Technology has changed how we work—and fast. Teams are spread across offices, homes, and time zones. Customers expect fast responses at any time of day. Meanwhile, businesses are juggling a mess of apps, devices, and phone systems that don’t talk to each other, slow everyone down, and cost too much to maintain. That’s why more […]

  The post What is UCaaS? A Complete Guide to Unified Communications as a Service appeared first on Sangoma Technologies.

• WebRTC Hacks REMINDER: Livestream this Thursday April 10: Open AI WebRTC Q&A with Sean DuBois
  

  Thursday, April 10 at 17:00 UTC / 11:00 AM EDT / 8:00 AM PDT OpenAI is utilizing WebRTC for its Realtime API! Join Chad Hart, Editor of webrtcHacks, for an analysis of WebRTC trends in GitHub,  OpenAI is utilizing WebRTC for its Realtime API! Join webrtcHacks editor Chad Hart for a Q&A with OpenAI’s WebRTC […]

  The post REMINDER: Livestream this Thursday April 10: Open AI WebRTC Q&A with Sean DuBois appeared first on webrtcHacks.

April 07, 2025

• Digium Why Healthcare Providers Are Turning to UC with GenAI for Better Patient Care

  Healthcare providers are under more pressure than ever. Doctors and healthcare staff spend long hours, dealing with mountains of paperwork, managing telemedicine appointments, and answering patient calls. It’s a lot to handle—and it takes time away from what matters most: caring for patients. That’s where Unified Communications (UC) and Generative AI (GenAI) come in to […]

  The post Why Healthcare Providers Are Turning to UC with GenAI for Better Patient Care appeared first on Sangoma Technologies.

April 01, 2025

• WebRTC Hacks Measuring the response latency of OpenAIs WebRTC-based Realtime API
  

  As Chad mentioned in his post last week, we have been diving into what OpenAI is doing with WebRTC. Over the last months, we actually did a full teardown and compared OpenAI’s Realtime API to what powers chatgpt.com. What intrigued us most was how to measure response latency. One of the key metrics for any […]

  The post Measuring the response latency of OpenAIs WebRTC-based Realtime API appeared first on webrtcHacks.

March 27, 2025

• Digium The Role of Unified Communications in Enhancing Guest Experience in Resorts and Hotels

  In hospitality, the pressure to provide exceptional guest experiences is always high. Whether you run a boutique hotel or a large resort, guests expect fast, personalized service, and any hiccup in communication can quickly lead to frustration and bad reviews. How can you keep things running smoothly and ensure each guest leaves happy? The answer […]

  The post The Role of Unified Communications in Enhancing Guest Experience in Resorts and Hotels appeared first on Sangoma Technologies.

March 25, 2025

• Digium The Ultimate Guide to Unified Communications Solutions

  Every missed call, delayed message, or clunky video conference costs your business more than time—it costs opportunities. The average employee switches between 13 different apps 30 times a day, losing focus and wasting hours in the process. Over the course of a week, that’s four hours spent just trying to reorient after toggling between tools. […]

  The post The Ultimate Guide to Unified Communications Solutions appeared first on Sangoma Technologies.

March 20, 2025

• Digium Doctors Losing Patients Over Missed Calls: How Sangoma’s Healthcare Communications Can Help

  Imagine being a doctor at a busy practice. Your office is packed with patients, your team is juggling phone calls, prescription refills, appointment scheduling, and in-person visits—all at once. The phone rings again, but this time, it’s not answered, or worse, it’s dropped entirely. You’re already buried in paperwork, and the outdated phone systems aren’t […]

  The post Doctors Losing Patients Over Missed Calls: How Sangoma’s Healthcare Communications Can Help appeared first on Sangoma Technologies.

• Digium Switchvox Admin Training Videos for Beginners and Experts

  With big players like NEC pulling the plug on their on-premises offerings and others cutting support for traditional systems, it’s easy to think the future of Unified Communications (UC) lies entirely in the cloud. However, not all companies are on board with this shift.  At Sangoma, we’ve committed to continuing to invest in Switchvox On-Premises […]

  The post Switchvox Admin Training Videos for Beginners and Experts appeared first on Sangoma Technologies.

March 18, 2025

• WebRTC Hacks The Unofficial Guide to OpenAI Realtime WebRTC API
  

  OpenAI using WebRTC in its Realtime API is obviously exciting to us here at webrtcHacks. Fippo and I were doing some blackboxing of this based on a quick sample the day of the WebRTC announcement so we could look at it in webrtc-internals and Wireshark. Some weeks later, my daughter was interested in using ChatGPT […]

  The post The Unofficial Guide to OpenAI Realtime WebRTC API appeared first on webrtcHacks.

March 07, 2025

• Digium Celebrating Women in Business: How Sangoma Supports Empowerment and Innovation

  International Women’s Day is a time to celebrate the incredible contributions of women worldwide and reflect on the progress made toward gender equality. At Sangoma, we proudly recognize the women who inspire us daily, driving innovation, growth, and success across our company and the broader business world. As a company rooted in values like trust, […]

  The post Celebrating Women in Business: How Sangoma Supports Empowerment and Innovation appeared first on Sangoma Technologies.

March 06, 2025

• Digium Avaya Abandons SMBs – Why Sangoma is the Ideal Solution for Small and Medium-Sized Businesses

  The communications world is buzzing with big changes, and it’s leaving many small and medium-sized businesses (SMBs) in a tough spot. Avaya, a long-standing player in the space, has announced that starting June 30, 2025, it will no longer support businesses with fewer than 200 seats on its Avaya Experience Platform (AXP). If you’re one […]

  The post Avaya Abandons SMBs – Why Sangoma is the Ideal Solution for Small and Medium-Sized Businesses appeared first on Sangoma Technologies.

February 28, 2025

• Jitsi GSoC 2025, let’s do this!

  We’re excited to share that Jitsi has been accepted into Google Summer of Code 2025! This is a great opportunity to get hands-on experience, collaborate with our awesome community, and contribute to the Jitsi open-source ecosystem.

  If you’re interested in participating, check out our idea tracker for some inspiration. If you have your own cool project idea, we’d love to hear it!

  To get started, make sure to check out the following resources:

  • Jitsi GitHub
  • Jitsi Handbook
  • Jitsi Community Forum

  The deadline for applications is April 8th, 2025, so be sure to get your proposal in before then! We’re here to support you throughout the process, and we can’t wait to see what you’ll bring to the table.

  Stay tuned for updates, join the community discussions, and let’s make GSoC 2025 amazing!

  The post GSoC 2025, let’s do this! appeared first on Jitsi.

January 28, 2025

• WebRTC Hacks 2024 WebRTC in Open Source Review: A Quantitative Analysis
  

  I have been updating a WebRTC in Open Source dataset derived from GitHub event data for 10 years now. I periodically update this to look for recent trends on WebRTC activity, popular repos, and new API usage. I hosted a live stream of my 2024 review back in December where Tsahi Levent-Levi joined to help […]

  The post 2024 WebRTC in Open Source Review: A Quantitative Analysis appeared first on webrtcHacks.

January 21, 2025

• WebRTC Hacks Capture & Replay WebRTC video streams for debugging – video_replay 2025 update
  

  Debugging WebRTC media issues, especially video, often requires access to the unencrypted RTP payloads. We talked about this back in 2017 already and had a great blog post on using the libWebRTC “video_replay” tool. While that post has aged remarkably well, video_replay has improved significantly, in particular since it is now possible to create the […]

  The post Capture & Replay WebRTC video streams for debugging – video_replay 2025 update appeared first on webrtcHacks.

January 13, 2025

• Digium The New FCC STIR/SHAKEN Rules and Why They Matter for Your Business in 2025

  Understanding the FCC’s New STIR/SHAKEN Rules: A Compliance Guide for Businesses

  The post The New FCC STIR/SHAKEN Rules and Why They Matter for Your Business in 2025 appeared first on Sangoma Technologies.

January 03, 2025

• Olle E. Johansson Edvina founds SBOMEUROPE.EU with APH10 in the UK
  During the fall of 2024 Edvina AB founded SBOM Europe in partnership with APH10 in Manchester, UK. Europe is undergoing heavy legislation for software, aimed at increasing the application security. One critical part in securing systems and software is the Bill of Materials (BOM). The Software Bill of Materials is in focus around the world […]

December 17, 2024

• Jitsi AV1 and more … how does Jitsi Meet pick video codecs?

  Say hello to AV1, the new default video codec in Jitsi Meet 

  

  The AV1 codec represents the cutting edge of video compression technology. Developed by the Alliance for Open Media (AOMedia), a consortium including tech giants like Google, Microsoft, Netflix, and Mozilla, AV1 is a loyalty-free video codec that was designed to meet the ever-growing demand for high-quality video streaming while minimizing bandwidth usage. 

  It offers up to 30-50% better compression compared to its predecessors like VP9, VP8 and H.264, enabling sharper visuals at lower bitrates. This makes it an ideal choice for bandwidth-constrained environments, such as mobile networks or rural areas with limited internet speeds. Despite its impressive capabilities, the adoption of AV1 has been slower than anticipated due to several factors. AV1 has higher computational demands as its advanced compression algorithms require significantly more processing power for encoding and decoding. Hardware acceleration for AV1 is still emerging and therefore use of AV1 can result in higher CPU/energy consumption and suboptimal performance on low end devices and those without hardware support.

  The path to adding AV1 support in Jitsi was not straightforward. Before we could enable AV1, it was essential to integrate support for the various modes and complexities that the codec offers, both in the Jitsi Meet client and the Jitsi Video Bridge (JVB). Jitsi had to extend JVB’s capabilities to handle AV1 streams, including managing simulcast and SVC modes seamlessly for multi-user conferences. This groundwork laid the foundation for AV1’s eventual inclusion as the preferred codec in Jitsi deployments.

  AV1’s RTP encapsulation is unusual, if not weird, compared to RTP payloads for other video codecs – all the information an RTP Selective Forwarding Unit (SFU) like the JVB needs is carried in a “Dependency Descriptor” RTP header extension, rather than in the RTP payload proper.  This means that the JVB doesn’t technically need to support the AV1 codec at all – it only needs to support the dependency descriptor header extension.

  Decoding AV1’s Dependency Descriptor

  This format is unusual in that it was developed not in the IETF, where RTP payload formats are normally defined, but rather by AOMedia itself.  The main consequence of this is that the header is encoded very much like a video codec: it’s very parsimonious of bit usage, at the cost of being both annoyingly complicated to parse, and being stateful – information needed to parse the header is sent only at intervals. For more information about this complexity, see Lorenzo’s post from several years ago – https://www.meetecho.com/blog/av1-svc/.

  Handling the complex parsing is relatively straightforward once some utility classes are written. However, handling the statefulness is harder, especially given that an SFU always needs to be prepared for packet loss and reordering, so packets that use some state may arrive before the packet that provides it.  Thus this work needs to keep track of the state that’s reported in those packets that carry it, and pass it forward to the parser to parse subsequent headers, while handling the possibility that a state update may have been missed.

  Because the AV1 DD is a header extension, it can be applied to codecs other than AV1 itself.  Notably, this allows us to indicate temporal scalability of an H.264 stream, which is useful because H.264 (without its little-implemented SVC extensions) has no way to indicate temporal scalability of its packets.  As a result, the work to support the AV1 DD also allows Jitsi to enable scalable H.264 streams for JVB-mediated conferences as well!  (Though there are currently some bugs in Chrome that make this less efficient than it could be – see here and here.)  In fact the header can be applied to any video codec, though we still prefer to handle VP8 and VP9 using their in-payload information when that information is available.

  Another notable feature of the AV1 dependency descriptor is its concept of “decode targets”, which are a specific layer that a decoder can decode, and thus that an SFU can forward.  These usually correspond to a specific spatial and temporal layer, but technically they do not have to.  The idea is that a decoder can choose among the various decode targets present in the stream. In most cases it would want to choose the highest-quality one available, but in some circumstances (for instance if it was CPU-constrained, or displaying a source in a small window) it could choose a lower-quality target instead.

  This has the consequence that a stream needs to be explicit about what decode targets are actually present.  An SFU, by design, forwards only some of the layers in a stream; this is what it means to “selectively forward”.  As a result, the ultimate decoder needs to know what layers it can actually expect to receive, vs. which ones it won’t receive, or it can end up waiting forever while it never gets the frames it thinks it should render.  To handle this case, the AV1 dependency descriptor contains a decode target bitmask in the AV1 header extension to indicate which layers are still present in the stream.  This bitmask then needs to be updated every time the SFU changes its layer forwarding decision, so the decoder doesn’t try to wait to decode a decode target that won’t be arriving any more, or, conversely, so it can know to start decoding a new layer that’s newly started arriving. Fortunately, the logic to do this work is not too complicated, and is similar in complexity to the logic needed to modify the in-payload information for forward VP8 or VP9 streams.

  Scalable Video Coding (SVC) Extension for WebRTC

  With the release of Chromium M111, significant advancements were made in WebRTC, particularly with the introduction of Scalable Video Coding (SVC) support. This update enabled WebRTC applications to configure encoding parameters for SVC by extending the RTCRtpEncodingParameters dictionary. Around the same time, Chrome also introduced AV1 and VP9 simulcast support. Before Chromium M111, the K-SVC mode (Keyframe-scalable video coding) was the only supported mode for SVC. This update allowed Jitsi Meet to experiment with various scalability modes for AV1 and VP9.

  In a Jitsi conference, the client and JVB work in tandem to ensure efficient video streaming. This involves an ongoing exchange of sender and receiver video constraints.

  • Receiver Constraints: Each participant sends constraints (e.g., desired resolution and priority) to the JVB for the video streams they want to receive. These constraints are influenced by the participant’s current layout (e.g., larger tiles for active speakers).
  • Sender Constraints: JVB aggregates these constraints and communicates the required video resolutions to the senders. This ensures a participant only sends higher-resolution streams (e.g., 720p) if at least one other participant views them in a sufficiently large tile.

  This dynamic coordination minimizes bandwidth usage and optimizes network resources while maintaining the quality of the user experience. Once the client receives sender constraints, it configures its outbound video streams using RTCRtpEncodingParameters. These parameters are tailored based on:

  1. Resolution: The effective resolution determined by JVB constraints.
  2. Video Type: Camera or desktop sharing (further based on content type).
  3. Codec Operating Mode: Whether the stream uses full SVC, simulcast, or unicast.

  For AV1 and VP9, three operating modes were tested:

  1. Full SVC Mode: Uses L3T3 (3 spatial layers, 3 temporal layers) and L2T3 (2 spatial layers, 3 temporal layers) scalability modes.
  2. K-SVC Mode: Employs L3T3_KEY and L2T3_KEY scalability modes, focusing on keyframe-based scalability.
  3. Simulcast Mode: Configures each simulcast layer with L1T3 (single spatial layer, 3 temporal layers).

  SVC allows a single video stream to be encoded in layers, each layer adding more detail or resolution to the base stream while simulcast involves sending multiple independent video streams of the same content, each at a different resolution and bitrate.

  Aspect	Simulcast	SVC
  Encoding	Multiple streams encoded separately.	One stream encoded with multiple layers.
  Bandwidth Usage (Sender)	Higher (multiple streams).	Lower (single stream).
  CPU Usage (Sender)	High (due to multiple encodings).	Lower (single encoding with layers).
  CPU Usage (Receiver)	Lower (no need to decode layers).	Higher (decoding layered streams).
  Adaptability	Coarser (switching between streams).	Finer (dynamic layer adjustment).
  Compatibility	Broadly supported in WebRTC platforms.	Limited support, requires advanced codecs.

  After extensive performance testing and careful evaluation of product requirements, Jitsi selected full SVC mode as the default configuration for both AV1 and VP9. This choice ensures optimal scalability and video quality across Jitsi’s deployments. However, this behavior is not rigid; it is configurable and can be easily overridden through config.js settings, providing flexibility to adapt to specific use cases or deployment needs.

  Choosing “The One”

  To determine the optimal video codec for use in the Jitsi Meet client, Jitsi conducted comprehensive testing under realistic conditions to ensure that codec selection would meet product needs for quality, performance, and scalability. Below is an overview of the methodologies and considerations involved:

  Testing Scenarios

  1. Bandwidth Variations – Simulations spanned low, medium, and high bandwidth environments. The goal was to assess how each codec managed network fluctuations while maintaining quality.
  2. Latency and Packet Loss – Varying levels of latency and packet loss were introduced to evaluate codec resilience. Stress tests were performed to observe behavior under severe conditions, such as 30% packet loss or latency spikes of 300ms.
  3. Device Diversity – Tests were conducted on a range of hardware, including Windows and macOS devices and multiple operating systems, to measure CPU load and adaptability. Both high-end and low-end systems were evaluated to cover a wide user base.

  Metrics Captured

  1. CPU Usage – Encoding and decoding performance were assessed, focusing on average encode times (in milliseconds). Data was derived from totalEncodeTime stats in outbound RTP streams, with averages computed across test runs.
  2. Bandwidth Efficiency – The minimum bitrate required to deliver acceptable video quality was recorded. Metrics were analyzed for each codec to identify which offered optimal quality for a given bitrate.
  3. Scalability Performance – Tested the ability of each codec to handle spatial and temporal scalability. Metrics such as switch latency (time to adjust to new sender constraints) were captured to evaluate adaptability during resolution and frame rate changes.
  4. User Experience Metrics – Frame drops and jitter were monitored to quantify playback quality. Recovery time after network disruptions or resolution changes was measured, ensuring codecs could handle dynamic conditions effectively.

  Results and observations

  • AV1: Delivered superior video quality at low bitrates but required higher CPU power (but surprisingly on par with VP9 in some cases), making it ideal for high-quality sessions on modern devices. It turned out that it was the best codec for screen sharing on all platforms because of how it uses screen content coding to achieve low bitrates without compromising on video quality and using low CPU, all at the same time.
  • VP9: Balanced bandwidth efficiency and CPU usage, proving effective for scalable video streams in multi-party calls.
  • VP8: Demonstrated resilience under suboptimal conditions but lagged in scalability and modern features compared to newer codecs.
  • H.264: Showed minimal CPU usage only where hardware acceleration was supported. The CPU usage was much higher when it was done in software, especially for higher resolutions like 4K and screenshare. It also struggled with bandwidth efficiency and adaptability in low-bandwidth scenarios.

  By rigorously analyzing these metrics, Jitsi optimized its codec selection strategy. While Full SVC modes remained the default for high-performance scenarios, fallback options like VP9 and VP8 were configured for legacy or resource-constrained devices. This comprehensive approach ensures that the Jitsi Meet client provides the best possible video experience across a wide range of devices and network conditions.

  Addressing CPU overuse with Adaptive Mode in Jitsi Meet

  With the integration of AV1 into Jitsi Meet, users benefit from superior compression and high-quality video at lower bitrates. However, these advantages come at the cost of increased computational demands, especially on low-end devices. To address this, Jitsi introduced a three-fold adaptive quality control mechanism, ensuring a seamless experience even under CPU constraints.

  How Adaptive Mode Works

  1. Decreasing the Encoding Load
     • Dynamic Codec Switching:
       In adaptive mode, the Jitsi Meet client monitors the WebRTC stats for outbound RTP streams. If the stats indicate a CPU limitation, the client iteratively switches to a lower-complexity codec. This process continues until the lowest complexity codec is reached, based on predefined performance benchmarks for each video type (e.g., camera feed, screen share)  thereby reducing the computational demand of video encoding without significantly compromising video quality.
  2. Decreasing the Decoding Load
     • Requesting Fewer Videos: If reducing encoding complexity isn’t sufficient, the client requests fewer video streams from the server. This limits the number of video decoders active at a given time, cutting down CPU usage.
     • Lowering Received Video Resolution: For videos already being received, the client requests lower resolutions, further reducing decoding requirements. This helps balance computational load while maintaining an acceptable user experience.

  This adaptive approach enables Jitsi Meet to leverage the advanced capabilities of AV1 while ensuring that users with diverse hardware configurations can participate in meetings without disruptions caused by excessive CPU usage.

  However, when the CPU spike originates from an external process rather than the Jitsi Meet client, the adaptive mode ensures that quality degradation is minimal. To enhance the user experience, Jitsi Meet also incorporates a recovery mechanism that restores the video configuration once the external constraints are resolved.

  Mechanism for Recovery

  1. Continuous Monitoring
     • The client monitors the CPU limitation statistics reported by the browser through WebRTC metrics. If the browser no longer reports CPU constraints, the client initiates a recovery sequence.
  2. Incremental Recovery Process
     • The recovery mechanism keeps increasing the number of remote video streams the client requests from the JVB until it reaches the limit set for the conference.
     • This process is incremental to prevent sudden spikes in CPU usage that could destabilize the client.
  3. Dynamic Adjustment
     • If CPU constraints reappear during the recovery process, the client halts further recovery steps. This ensures the system does not enter a state where CPU usage exceeds the device’s capabilities.

  This gradual approach minimizes the risk of overloading the system during recovery. It also adapts to fluctuating CPU availability, maintaining a balance between performance and quality. The client handles this entire process dynamically without any user interaction, providing a seamless experience.

  Browser / device support

  Firefox and Safari do not advertise support for the AV1 codec yet. As a result, when users on these browsers join a call, all other participants automatically switch to the next codec in the preferred list, ensuring compatibility across all endpoints.

  Additionally, while Chromium-based mobile endpoints are capable of both encoding and decoding AV1, Jitsi has opted to use AV1 only for decoding. For encoding, a lower-complexity codec is used, as encoding typically imposes a higher CPU load compared to decoding. This decision balances performance and device resource constraints, especially on mobile devices.

  Eager to start using AV1 in Jitsi?

  We have great news for you then!! AV1 support was introduced to Jitsi in June 2024 and has been available in our stable packages ever since. Initially, AV1 had to be manually configured as the preferred codec through config.js settings, allowing users to opt in.

  Building on this, AV1 was soon made the preferred codec on meet.jit.si, marking a significant step in leveraging its advanced compression capabilities. Starting with release stable-9909, AV1 became the default preferred codec in our Docker deployments, ensuring out-of-the-box support for users opting for containerized setups.

  After thorough experimentation and analysis of real-world performance data, we’re excited to share that AV1 will very soon become the default preferred codec in all deployments, bringing its exceptional bandwidth efficiency and video quality to a broader audience. Stay tuned!

  Happy holidays!

  Your personal meetings team.

  P.S – With contributions from Jonathan Lennox (Jitsi VideoBridge)

   

   

  The post AV1 and more … how does Jitsi Meet pick video codecs? appeared first on Jitsi.

December 02, 2024

• Digium Introducing Sangoma TeamHub for CommUnity

  Sangoma TeamHub—a user-friendly app designed to simplify team collaboration and boost productivity—is now available to new users of Sangoma's UCaaS platform CommUnity.

  The post Introducing Sangoma TeamHub for CommUnity appeared first on Sangoma Technologies.

• Digium How to Successfully Migrate from Traditional Telecom to Modern Packet-Based Phone Networks

  A portion of the telephone network that dates back several decades is often called Plain Old Telephone Service, or POTS for short. In recent years.

  The post How to Successfully Migrate from Traditional Telecom to Modern Packet-Based Phone Networks appeared first on Sangoma Technologies.

• WebRTC Hacks Upcoming Livestream 10-Dec: 2024 WebRTC in Open Source Review
  

  Tuesday, December 10 @ 5PM CET / 11AM ET / 8AM PT / 16:00 UTC Join Chad Hart, Editor of webrtcHacks, for an analysis of WebRTC trends in GitHub,  StackOverflow, and other open-source communities.   Leveraging advanced quantitative analysis techniques, this talk examines millions of GitHub events and developer activity data to uncover key trends […]

  The post Upcoming Livestream 10-Dec: 2024 WebRTC in Open Source Review appeared first on webrtcHacks.

November 20, 2024

• Digium Introducing Sangoma TeamHub for CommUnity

  Sangoma TeamHub—a user-friendly app designed to simplify team collaboration and boost productivity—is now available to new users of Sangoma’s UCaaS platform CommUnity.

  With features like voice calling, real-time chat, SMS, video meetings, and file storage, you get all your communication tools in one place without jumping between multiple apps. Stay connected wherever you are! Access Sangoma TeamHub easily through your web browser or use the desktop app on Mac or Windows. It’s also available on iOS and Android mobile devices.

  Key Features:

  • Talk: Make clear calls using Sangoma TeamHub’s built-in softphone, which features call transfers and rings across all your devices. Enjoy convenient access to visual voicemail and the ability to seamlessly hand off calls, allowing you to continue conversations on another device. Fine-tune your audio settings to fully leverage CommUnity’s powerful voice features, including parking lots, advanced ‘Find Me/Follow Me’ routes, and your own conference bridge.

    
  • Chat: Easily share ideas in public or private channels, and send direct chat messages with smart features that save time. AI tools help you quickly catch up on discussions or find information about Sangoma products without sifting through documentation.
  • SMS: Connect with your customers via SMS using your designated number, activated in a 10DLC campaign.
  • Video Meetings: Host productive meetings with features like live closed captioning, remote control, and easy calendar integrations.
  • File Storage: Organize your documents in your personal Sangoma TeamHub Drive, allowing you to access files wherever you go.
  • Contact Management: Effortlessly manage personal contacts with dial-in options, organize favorites, view ring groups, and sync your corporate phonebook with MS Office 365 and Google contacts for easy access.

  Sangoma TeamHub focuses on user satisfaction by providing robust and secure communications, as well as easy customization. Accessible from any internet-connected device, it offers timely notifications whether you’re in the office, working remotely, or on the go, keeping you connected and informed.

  Sangoma TeamHub is the ultimate tool for team collaboration and communication, helping you work efficiently from anywhere.

  Learn more about mastering teamwork with Sangoma TeamHub today!

  Join us on December 12th for the exclusive TeamHub for CommUnity webinar: Register Now!

  The post Introducing Sangoma TeamHub for CommUnity appeared first on Sangoma Technologies.

October 29, 2024

• Digium Seamlessly Transition from POTS to IP Networks with Sangoma Vega Gateways

  As businesses increasingly migrate to IP networks, a significant challenge remains: how do you transition from legacy POTS (Plain Old Telephone Service) while maintaining the investment in devices like phones, fax machines, and security equipment?

  The post Seamlessly Transition from POTS to IP Networks with Sangoma Vega Gateways appeared first on Sangoma Technologies.

October 24, 2024

• Digium NEC Steps Out of the UCaaS Market, Now What?

  In a significant shift in the Unified Communications (UC) landscape, NEC announced its decision to exit the UCaaS market, in addition to its earlier announcement to leave the on-prem market. These moves have left many NEC partners and prospects wondering, “Where do we go from here?” NEC in the News Intermedia Cloud Communications and NEC […]

  The post NEC Steps Out of the UCaaS Market, Now What? appeared first on Sangoma Technologies.

• Digium Introducing ASK Sangoma: Your AI-powered Knowledge Bot for Quicker Support

  As part of our commitment to innovation and customer support, we are excited to announce the launch of @ASKSangoma, an AI-powered Knowledge Bot. The latest version 3.3 of the Sangoma Teamhub collaboration app introduces a new bot designed to assist our partners and customers with inquiries regarding Sangoma’s product portfolio. Trained on comprehensive product documentation, […]

  The post Introducing ASK Sangoma: Your AI-powered Knowledge Bot for Quicker Support appeared first on Sangoma Technologies.

September 03, 2024

• WebRTC Hacks Power-up getStats for Client Monitoring
  

  WebRTC’s peer connection includes a getStats method that provides a variety of low-level statistics. Basic apps don’t really need to worry about these stats but many more advanced WebRTC apps use getStats for passive monitoring and even to make active changes. Extracting meaning from the getStats data is not all that straightforward. Luckily return author […]

  The post Power-up getStats for Client Monitoring appeared first on webrtcHacks.

August 16, 2024

• Daniel Pocock ClueCon 2024 photos

  ClueCon has just finished. Here are some of my photos.

  Monday, pizza night

   

  

   

  

  Tuesday

   

  

   

  

   

  

   

  

  Tuesday, Gigabit reception and 20th birthday party for ClueCon

   

  

   

  

   

  

   

  

   

  

   

  

   

  

   

  

   

  

   

  

   

  

  Wednesday, panel discussion

   

  

  Wednesday, Casino night

   

  

   

  

  Thursday, Dangerous Demos

   

  

   

  

   

  

   

  

   

  

   

  

   

  

  Thursday, final raffle prize

  Seven Du from China won the Macbook. Congratulations.

   

  
• Daniel Pocock ClueCon 2024 photos

  ClueCon has just finished. Here are some of my photos.

  Monday, pizza night

   

  

   

  

  Tuesday

   

  

   

  

   

  

   

  

  Tuesday, Gigabit reception and 20th birthday party for ClueCon

   

  

   

  

   

  

   

  

   

  

   

  

   

  

   

  

   

  

   

  

   

  

  Wednesday, panel discussion

   

  

  Wednesday, Casino night

   

  

   

  

  Thursday, Dangerous Demos

   

  

   

  

   

  

   

  

   

  

   

  

   

  

  Thursday, final raffle prize

  Seven Du from China won the Macbook. Congratulations.

   

  

August 15, 2024

• Olle E. Johansson Need to learn more about AppSec in the light of the coming regulation?
  The EU Cyber Resilience Act will come into full force in three years from now. That means that software needs to be secure by design and secure by default. Manufacturers will get more responsibility for the cyber security of their customers. In addition, manufacturers will be forced to deliver many years of free security updates. […]

July 31, 2024

• Enable Security July 2024: WebRTC flaws that suddenly appear out of nowhere, hardphone security and more!
  Welcome to the July edition of your favorite VoIP and WebRTC security newsletter. While many are slowing down this time of year, we are ramping up our efforts. In this edition, we cover: Much news from us, including a podcast, pentesting and OWASP ASVS WebRTC project vulnerabilities that were previously hidden Hardware phone security research and exploitation Low-latency VoIP Security Analytics and Anonymization challenges and Twilio troubles The RTCSec newsletter is a free periodic newsletter bringing you commentary and news around VoIP and WebRTC security.

July 26, 2024

• Enable Security TADSummit Innovators Podcast reviews the Last 6 Months of RTC Security Trends with Sandro Gauci
  This week, I had the pleasure of joining Alan Quayle on the TADSummit Innovators Podcast to review the last six months of VoIP and WebRTC security news. We delved into some of the most intriguing trends emerging in the RTC security space. We covered the following RTC security trends for 2024 so far: Increasing focus on WebRTC vulnerabilities and security Growing concern over VoIP and conferencing platform security Emerging threats from AI and machine learning in audio manipulation Growing importance of resilience in communication systems SMS/Voice 2FA is hugely problematic Here are the top 10 insights that emerged from our discussion:

June 30, 2024

• François Marier Upgrading from chan_sip to res_pjsip in Asterisk 18

  After upgrading to Ubuntu Jammy and Asterisk 18.10, I saw the following messages in my logs:

  WARNING[360166]: loader.c:2487 in load_modules: Module 'chan_sip' has been loaded but was deprecated in Asterisk version 17 and will be removed in Asterisk version 21.
  WARNING[360174]: chan_sip.c:35468 in deprecation_notice: chan_sip has no official maintainer and is deprecated.  Migration to
  WARNING[360174]: chan_sip.c:35469 in deprecation_notice: chan_pjsip is recommended.  See guides at the Asterisk Wiki:
  WARNING[360174]: chan_sip.c:35470 in deprecation_notice: https://wiki.asterisk.org/wiki/display/AST/Migrating+from+chan_sip+to+res_pjsip
  WARNING[360174]: chan_sip.c:35471 in deprecation_notice: https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip
  

  and so I decided it was time to stop postponing the overdue migration of my working setup from chan_sip to res_pjsip.

  It turns out that it was not as painful as I expected, though the conversion script bundled with Asterisk didn't work for me out of the box.

  Debugging

  Before you start, one very important thing to note is that the SIP debug information you used to see when running this in the asterisk console (asterisk -r):

  sip set debug on
  

  now lives behind this command:

  pjsip set logger on
  

  SIP phones

  The first thing I migrated was the config for my two SIP phones (Snom 300 and Snom D715).

  The original config for them in sip.conf was:

  [2000]
  ; Snom 300
  type=friend
  qualify=yes
  secret=password123
  encryption=no
  context=full
  host=dynamic
  nat=no
  directmedia=no
  mailbox=10@internal
  vmexten=707
  dtmfmode=rfc2833
  call-limit=2
  disallow=all
  allow=g722
  allow=ulaw
  
  [2001]
  ; Snom D715
  type=friend
  qualify=yes
  secret=password456
  encryption=no
  context=full
  host=dynamic
  nat=no
  directmedia=yes
  mailbox=10@internal
  vmexten=707
  dtmfmode=rfc2833
  call-limit=2
  disallow=all
  allow=g722
  allow=ulaw
  

  and that became the following in pjsip.conf:

  [transport-udp]
  type = transport
  protocol = udp
  bind = 0.0.0.0
  external_media_address = myasterisk.dyn.example.com
  external_signaling_address = myasterisk.dyn.example.com
  local_net = 192.168.0.0/255.255.0.0
  
  [2000]
  type = aor
  max_contacts = 1
  
  [2000]
  type = auth
  username = 2000
  password = password123
  
  [2000]
  type = endpoint
  context = full
  dtmf_mode = rfc4733
  disallow = all
  allow = g722
  allow = ulaw
  direct_media = no
  mailboxes = 10@internal
  auth = 2000
  outbound_auth = 2000
  aors = 2000
  
  [2001]
  type = aor
  max_contacts = 1
  
  [2001]
  type = auth
  username = 2001
  password = password456
  
  [2001]
  type = endpoint
  context = full
  dtmf_mode = rfc4733
  disallow = all
  allow = g722
  allow = ulaw
  direct_media = yes
  mailboxes = 10@internal
  auth = 2001
  outbound_auth = 2001
  aors = 2001
  

  The different direct_media line between the two phones has to do with how they each connect to my Asterisk server and whether or not they have access to the Internet.

  Internal calls

  For some reason, my internal calls (from one SIP phone to the other) didn't work when using "aliases". I fixed it by changing this blurb in extensions.conf from:

  [speeddial]
  exten => 1000,1,Dial(SIP/2000,20)
  exten => 1001,1,Dial(SIP/2001,20)
  

  to:

  [speeddial]
  exten => 1000,1,Dial(${PJSIP_DIAL_CONTACTS(2000)},20)
  exten => 1001,1,Dial(${PJSIP_DIAL_CONTACTS(2001)},20)
  

  I have not yet dug into what this changes or why it's necessary and so feel free to leave a comment if you know more here.

  PSTN trunk

  Once I had the internal phones working, I moved to making and receiving phone calls over the PSTN, for which I use VoIP.ms with encryption.

  I had to change the following in my sip.conf:

  [general]
  register => tls://555123_myasterisk:password789@vancouver2.voip.ms
  externhost=myasterisk.dyn.example.com
  localnet=192.168.0.0/255.255.0.0
  tcpenable=yes
  tlsenable=yes
  tlscertfile=/etc/asterisk/asterisk.cert
  tlsprivatekey=/etc/asterisk/asterisk.key
  tlscapath=/etc/ssl/certs/
  
  [voipms]
  type=peer
  host=vancouver2.voip.ms
  secret=password789
  defaultuser=555123_myasterisk
  context=from-voipms
  disallow=all
  allow=ulaw
  allow=g729
  insecure=port,invite
  canreinvite=no
  trustrpid=yes
  sendrpid=yes
  transport=tls
  encryption=yes
  

  to the following in pjsip.conf:

  [transport-tls]
  type = transport
  protocol = tls
  bind = 0.0.0.0
  external_media_address = myasterisk.dyn.example.com
  external_signaling_address = myasterisk.dyn.example.com
  local_net = 192.168.0.0/255.255.0.0
  cert_file = /etc/asterisk/asterisk.cert
  priv_key_file = /etc/asterisk/asterisk.key
  ca_list_path = /etc/ssl/certs/
  method = tlsv1_2
  
  [voipms]
  type = registration
  transport = transport-tls
  outbound_auth = voipms
  client_uri = sip:555123_myasterisk@vancouver2.voip.ms
  server_uri = sip:vancouver2.voip.ms
  
  [voipms]
  type = auth
  password = password789
  username = 555123_myasterisk
  
  [voipms]
  type = aor
  contact = sip:555123_myasterisk@vancouver2.voip.ms
  
  [voipms]
  type = identify
  endpoint = voipms
  match = vancouver2.voip.ms
  
  [voipms]
  type = endpoint
  context = from-voipms
  disallow = all
  allow = ulaw
  allow = g729
  from_user = 555123_myasterisk
  trust_id_inbound = yes
  media_encryption = sdes
  auth = voipms
  outbound_auth = voipms
  aors = voipms
  rtp_symmetric = yes
  rewrite_contact = yes
  send_rpid = yes
  timers = no
  dtmf_mode = rfc4733
  

  The TLS method line is needed since the default in Debian OpenSSL is too strict. The timers line is to prevent outbound calls from getting dropped after 15 minutes.

  Finally, I changed the Dial() lines in these extensions.conf blurbs from:

  [from-voipms]
  exten => 5551231000,1,Goto(2000,1)
  exten => 2000,1,Dial(SIP/2000&SIP/2001,20)
  exten => 2000,n,Goto(in2000-${DIALSTATUS},1)
  exten => 2000,n,Hangup
  exten => in2000-BUSY,1,VoiceMail(10@internal,su)
  exten => in2000-BUSY,n,Hangup
  exten => in2000-CONGESTION,1,VoiceMail(10@internal,su)
  exten => in2000-CONGESTION,n,Hangup
  exten => in2000-CHANUNAVAIL,1,VoiceMail(10@internal,su)
  exten => in2000-CHANUNAVAIL,n,Hangup
  exten => in2000-NOANSWER,1,VoiceMail(10@internal,su)
  exten => in2000-NOANSWER,n,Hangup
  exten => _in2000-.,1,Hangup(16)
  
  [pstn-voipms]
  exten => _1NXXNXXXXXX,1,Set(CALLERID(all)=Francois Marier <5551231000>)
  exten => _1NXXNXXXXXX,n,Dial(SIP/voipms/${EXTEN})
  exten => _1NXXNXXXXXX,n,Hangup()
  exten => _NXXNXXXXXX,1,Set(CALLERID(all)=Francois Marier <5551231000>)
  exten => _NXXNXXXXXX,n,Dial(SIP/voipms/1${EXTEN})
  exten => _NXXNXXXXXX,n,Hangup()
  exten => _011X.,1,Set(CALLERID(all)=Francois Marier <5551231000>)
  exten => _011X.,n,Authenticate(1234)
  exten => _011X.,n,Dial(SIP/voipms/${EXTEN})
  exten => _011X.,n,Hangup()
  exten => _00X.,1,Set(CALLERID(all)=Francois Marier <5551231000>)
  exten => _00X.,n,Authenticate(1234)
  exten => _00X.,n,Dial(SIP/voipms/${EXTEN})
  exten => _00X.,n,Hangup()
  

  to:

  [from-voipms]
  exten => 5551231000,1,Goto(2000,1)
  exten => 2000,1,Dial(PJSIP/2000&PJSIP/2001,20)
  exten => 2000,n,Goto(in2000-${DIALSTATUS},1)
  exten => 2000,n,Hangup
  exten => in2000-BUSY,1,VoiceMail(10@internal,su)
  exten => in2000-BUSY,n,Hangup
  exten => in2000-CONGESTION,1,VoiceMail(10@internal,su)
  exten => in2000-CONGESTION,n,Hangup
  exten => in2000-CHANUNAVAIL,1,VoiceMail(10@internal,su)
  exten => in2000-CHANUNAVAIL,n,Hangup
  exten => in2000-NOANSWER,1,VoiceMail(10@internal,su)
  exten => in2000-NOANSWER,n,Hangup
  exten => _in2000-.,1,Hangup(16)
  
  [pstn-voipms]
  exten => _1NXXNXXXXXX,1,Set(CALLERID(all)=Francois Marier <5551231000>)
  exten => _1NXXNXXXXXX,n,Dial(PJSIP/${EXTEN}@voipms)
  exten => _1NXXNXXXXXX,n,Hangup()
  exten => _NXXNXXXXXX,1,Set(CALLERID(all)=Francois Marier <5551231000>)
  exten => _NXXNXXXXXX,n,Dial(PJSIP/1${EXTEN}@voipms)
  exten => _NXXNXXXXXX,n,Hangup()
  exten => _011X.,1,Set(CALLERID(all)=Francois Marier <5551231000>)
  exten => _011X.,n,Authenticate(1234)
  exten => _011X.,n,Dial(PJSIP/${EXTEN}@voipms)
  exten => _011X.,n,Hangup()
  exten => _00X.,1,Set(CALLERID(all)=Francois Marier <5551231000>)
  exten => _00X.,n,Authenticate(1234)
  exten => _00X.,n,Dial(PJSIP/${EXTEN}@voipms)
  exten => _00X.,n,Hangup()
  

  Note that it's not just replacing SIP/ with PJSIP/, but it was also necessary to use a format supported by pjsip for the channel since SIP/trunkname/extension isn't supported by pjsip.

June 28, 2024

• Enable Security June 2024: WebRTC security specs that need fixing and vulnerable VoIP firmware and WebEx
  Welcome to the June 2024 edition of the RTCSec newsletter, covering VoIP and WebRTC security news and related topics. In this edition, we cover: Our latest publication on our blog about WebRTC vulnerabilities Cisco WebEx’s seemingly obvious vulnerabilities and their effect on military and political entities Security fixes in Chrome, affecting WebRTC Vulnerabilities in Mitel phones, sngrep, and… iTunes? And more! The RTCSec newsletter is a free periodic newsletter bringing you commentary and news around VoIP and WebRTC security.

June 25, 2024

• Enable Security A Novel DoS Vulnerability affecting WebRTC Media Servers
  Executive summary (TL;DR) A critical denial-of-service (DoS) vulnerability has been identified in media servers that process WebRTC’s DTLS-SRTP, specifically in their handling of ClientHello messages. This vulnerability arises from a race condition between ICE and DTLS traffic and can be exploited to disrupt media sessions, compromising the availability of real-time communication services. Mitigations include filtering packets based on ICE-validated IP and port combinations. The article also indicates safe testing methods and strategies for detecting the attack.

June 11, 2024

• WebRTC Hacks WebRTC Plumbing with GStreamer
  

  GStreamer is one of the oldest and most established libraries for handling media. As a core media handling element in Linux and WebKit that as launched near the turn of the century, it is not surprising that many early WebRTC projects use various pieces of it. Today, GStreamer has expanded options for helping developers plumb […]

  The post WebRTC Plumbing with GStreamer appeared first on webrtcHacks.

May 31, 2024

• Enable Security May 2024: Presenting on DTLS WebRTC DoS and the latest VoIP vulnerabilities
  It is already the end of May, and we have a packed newsletter this month! In this edition, we cover: Our upcoming presentation about the DTLS ClientHello DoS vulnerability Vulnerabilities fixed in Asterisk, ALU and Cisco phones and more RCS phishing attempts and a Pre-War Reality Check and VoIP resilience New features from Kwanlabs SIP Open Relay tester A talk about STIR/SHAKEN privacy concerns Short news covering fax, physical access control vulnerabilities and honeypots The RTCSec newsletter is a free periodic newsletter bringing you commentary and news around VoIP and WebRTC security.

May 21, 2024

• Jitsi Connecting anything to everything via SIP

  In the evolving landscape of virtual meetings, seamless connectivity remains paramount. SIP integration enables participants to join meetings from various devices, including hardware phones or softphones such as Bria, video conferencing systems such as Zoom, and traditional telephony systems. This broadens the scope of participants who can connect to Jitsi conferences, making it more inclusive.

  Leveraging SIP for Video and Audio Connectivity

  Prerequisites

  1. JaaS Account: Create a JaaS account
  2. Host this sample code on your server 
  3. Zoom Account: Ensure you have Room System enabled in Zoom

  Note: We are using JaaS here for the purpose of simplicity, but all of this can be deployed using the Open Source components available on GitHub.

  Step-by-Step Guide

  • Join a Jitsi conference on your hosted instance
  • Get the SIP Addresses for Dial-In

  

  • Users can dial into Jitsi conferences from any hard SIP device or Zoom by using the following SIP addresses:
    • For a combined audio and video experience: pinCode@8×8.vc or pinCode@video.8×8.vc
    • For audio only: pinCode@audio.8×8.vc

  Note: Replace pinCode with the specific conference PIN provided for your Jitsi conference

  

  • Join a Zoom conference
    • To connect a Zoom conference to a Jitsi conference, use the Invite via Room System option in Zoom to call out to the provided SIP address

  

  • Testing:
    • Test the configuration by dialing the SIP address. Verify that the call connects to the Jitsi conference and that audio and video is properly routed.

  

  SIP Audio-Only Connectivity: Cost-Effective and Reliable

  SIP audio-only connectivity provides a cost-effective and reliable way for participants to join Jitsi conferences. It reduces bandwidth consumption and costs, making it ideal in scenarios where video isn’t really needed, such as webinars. This option ensures users with limited internet access or slower connections can participate without interruptions.

  Under the Hood: Exploring the Technical Details

  

  Integrating Voximplant with Jitsi Meet involves several key steps:

  1. Setting Up Voximplant Application:
     • Create a Voximplant application and configure it with the necessary call handling logic. This involves setting up a scenario for incoming calls, managing call routing, and defining custom IVRs 
     • Add logic in the scenario to validate the conference, select a SIP-Jibri and then forward the call to it
  2. Configuring SIP Video Gateways:
     • Configure SIP Jibris. Refer to the Jitsi SIP Video Gateway documentation for detailed setup instructions
     • Run a pool of SIP Jibris and use the SIP Jibri selector to select an available SIP Jibri
  3. Setting up a sip domain (Eg. video.8×8.vc):
     • Define a sip domain and ask VoxImplant to map it to your VoxImplant application
  4. Testing:
     • One easy way to test the integration is using a softphone to dial in

  Note: Voximplant can be replaced with a programmable SIP server such as Kamailio or OpenSIPS.

  

  Wrapping up

  While SIP is these days referred to as legacy, it remains the most used protocol for VoIP and acts as the common denominator across many vendors in the industry. Thus it’s a great candiate for connecting anything to everything

  Your personal meetings team.

  The post Connecting anything to everything via SIP appeared first on Jitsi.

May 14, 2024

• Digium Delivering a One-two Punch to NEC’s Departure from the On-premises PBX Market

  The Risks of Sticking with Unsupported On-Premises PBX Systems and Why Switching to Sangoma’s Switchvox is Essential Now You’ve found yourself in a tough spot – change is not just coming; it’s here. NEC has announced its departure from the on-premises PBX market, shifting its focus towards cloud-based solutions. So where does that leave you? […]

  The post Delivering a One-two Punch to NEC’s Departure from the On-premises PBX Market appeared first on Sangoma Technologies.

• Digium Delivering a One-two Punch to NEC’s Departure from the On-premises PBX Market

  The Risks of Sticking with Unsupported On-Premises PBX Systems and Why Switching to Sangoma’s Switchvox is Essential Now You’ve found yourself in a tough spot – change is not just coming; it’s here. NEC has announced its departure from the on-premises PBX market, shifting its focus towards cloud-based solutions. So where does that leave you? […]

  The post Delivering a One-two Punch to NEC’s Departure from the On-premises PBX Market appeared first on Sangoma Technologies.

May 07, 2024

• WebRTC Hacks Probing WebRTC Bandwidth Probing – why and how in gcc
  

  Maximizing stream quality on an imperfect network in real-time is a delicate balancing act. If you send too much information then will cause congestion and packet loss. If you send too little then your video quality (or audio) will look like garbage. But how much can you send? One of the techniques used to find […]

  The post Probing WebRTC Bandwidth Probing – why and how in gcc appeared first on webrtcHacks.

May 01, 2024

• Digium Why Choose On-Premises Solutions In a Cloud-Dominated Era?

  As of 2023, a significant portion of businesses still rely on on-premises systems. While the specific percentage of businesses using on-premises UC solutions is not detailed in recent reports, it’s evident that both on-premises and cloud solutions continue to coexist, with each offering distinct advantages depending on organizational needs and priorities. The unified communications market […]

  The post Why Choose On-Premises Solutions In a Cloud-Dominated Era? appeared first on Sangoma Technologies.

• Digium Why Choose On-Premises Solutions In a Cloud-Dominated Era?

  As of 2023, a significant portion of businesses still rely on on-premises systems. While the specific percentage of businesses using on-premises UC solutions is not detailed in recent reports, it’s evident that both on-premises and cloud solutions continue to coexist, with each offering distinct advantages depending on organizational needs and priorities. The unified communications market […]

  The post Why Choose On-Premises Solutions In a Cloud-Dominated Era? appeared first on Sangoma Technologies.

April 30, 2024

• Enable Security April 2024: Kamailio security, Mitel, sngrep and Grandstream vulnerabilities and more
  Welcome to the April edition of the VoIP and WebRTC security monthly newsletter. In this edition, we cover: Kamailio World 2024 review Our short and longer presentation on insecure Kamailio configuration patterns Changes to the newsletter Updates to T-Pot honeypot, sngrep security fixes, Mitel IP Phone vulnerabilities New security course on WebRTC by BlogGeek.me And some more! RTCSec newsletter is a free periodic newsletter bringing you commentary and news around VoIP and WebRTC security.

April 23, 2024

• Jitsi Improving performance on very large calls: introducing SSRC rewriting

  In the last stable release, Jitsi enabled a new feature called SSRC rewriting that improves the system performance for very large calls. This feature helps reduce the overall load on the system by reducing the number of signaling messages that get exchanged during a large call involving hundreds of endpoints. It also reduces the load on the local endpoint drastically by restricting the number of audio and video decoders created by the WebRTC engine thereby offering a better user experience for large calls.

  When this feature is enabled, only a fixed set (let’s say up to 50) of SSRCs are signaled to the downstream endpoints in the call irrespective of the call size. An SSRC is nothing but a unique ID used for identifying a stream of RTP packets that belong to an audio or a video source. When additional media sources are requested by the receiver, the Jitsi Videobridge (JVB) overwrites the SSRCs of the newly requested media streams with that of the ones that were already signaled to the client before and are no longer needed. Therefore, no more than 50 SSRCs need to be signaled to the endpoints even if the number of media sources that will be routed in total far exceeds the set limit.

  

  Moving on to the why – what is the problem that we were trying to solve by implementing SSRC rewriting?

  The challenges that we faced when adding support for very large calls with respect to source signaling with the existing approach of signaling every new source to every other participant in the call were two fold.

  At the client level, the number of m-lines in the SDP grew linearly with every remote source that got added to the call irrespective of whether media for that particular source gets routed to the endpoint or not. When a new m-line with SSRC is added to the remote SDP, the libwebrtc engine creates a transceiver and does all the plumbing necessary to decode a media stream with the given SSRC if and when it starts receiving it from the JVB. This tied up resources on the local endpoint unnecessarily and introduced delays in renegotiation cycles which resulted in unpleasant user experience. The client can also hit transceiver and SDP parser limits imposed by the browser resulting in unexpected behaviors. These performance issues are more pronounced on mobile endpoints which have fewer resources to begin with compared to the endpoints running on desktops.

  On the backend, as the number of participants grew, so did the number of audio and video sources that needed to be signaled to every other participant in the call. This made the signaling traffic from prosody (XMPP communication server) to the endpoints grow quadratically. This was a problem, because Prosody, which is single-threaded, was already the bottleneck when scaling calls. Previously we had to introduce artificial delays in signaling in order to reduce the load. This caused long delays for the media to be established across participants when they unmuted their audio or video for the first time and was very disruptive to large meetings.

  The solution to both of these problems was to switch to a demand based signaling mechanism where only a limited number of remote audio and video tracks are signaled to the endpoints depending on what is being needed or requested by them in real time instead of signaling all the known media sources in the call as and when they get added to the call.

  Implementation in Jitsi Videobridge

  Jitsi Videobridge (JVB) uses a slightly different approach for audio and for video when determining what sources to forward. Forwarding decisions for audio are based simply on the “loudness” of the streams determined from the audio level RTP extension.

  With SSRC rewriting, JVB uses a separate SSRC space for each receiver. It maintains a map from an SSRC number to the name of a source. Changes to the map are signaled to the receiver over the direct signaling channel (a WebRTC DataChannel over SCTP), using partial updates:

  [modules/RTC/BridgeChannel.js] <e.onmessage>:  Received AudioSourcesMap: [{"source":"fc63db0f-a0","owner":"fc63db0f","ssrc":2602882473},{"source":"449360a0-a0","owner":"449360a0","ssrc":1358697798}]
  [modules/RTC/BridgeChannel.js] <e.onmessage>:  Received VideoSourcesMap: [{"source":"e01f2103-v0","owner":"e01f2103","ssrc":3129389873,"rtx":3219602897,"videoType":"CAMERA"},{"source":"9ac8fef2-v0","owner":"9ac8fef2","ssrc":1542056973,"rtx":1571329554,"videoType":"CAMERA"},{"source":"ed6b60f5-v0","owner":"ed6b60f5","ssrc":550523896,"rtx":2808127984,"videoType":"CAMERA"}]

  When a new stream needs to be forwarded, it is allocated an SSRC. Before the limit is reached, JVB simply generates a new SSRC number, and when the limit has been reached the oldest entry is reused. Let’s look at an example to make this more clear. Assume the limit is set to just 3, and the available sources are A, B, C, D, E. Initially the map is empty. When A starts sending packets, we allocate SSRC 101 to it and signal it to the receiver like this:

  AudioSourcesMap: [{"source":"A","owner":"endpoint-A","ssrc":101}]

  Similarly when B and C start to speak we allocate SSRCs 102 and 103 for them:

  AudioSourcesMap: [{"source":"B","owner":"endpoint-B","ssrc":102}]

  AudioSourcesMap: [{"source":"C","owner":"endpoint-C","ssrc":103}]

  Now we have reached the limit of 3 SSRCs. When D starts to speak, we’ll find the source in the map that has been active least recently (let’s say that’s B) and re-use its SSRC for D. We’ll signal an update (“SSRC 102 now belongs to D”):

  AudioSourcesMap: [{"source":"D","owner":"endpoint-D","ssrc":102}]

  The scheme is identical for video, except the forwarding decisions are made in a different way. Receivers explicitly signal their preferences using video constraints. The source names and their mute status are published in presence when an endpoint signals its source information to the Jitsi Conference Focus (Jicofo) and therefore this information is already available with all the other endpoints in the call. Based on the current layout in the UI and the user’s preferences, the client sends the updated receiver video constraints over the bridge channel.

  A bandwidth allocation algorithm in the JVB then decides which streams to forward to a particular receiver, based on its constraints and current network conditions:

  [modules/RTC/BridgeChannel.js] <Fa.sendReceiverVideoConstraintsMessage>:  Sending ReceiverVideoConstraints with {"constraints":{"ed6b60f5-v0":{"maxHeight":360},"e01f2103-v0":{"maxHeight":360},"9ac8fef2-v0":{"maxHeight":360}},"defaultConstraints":{"maxHeight":0},"lastN":-1,"onStageSources":[],"selectedSources":[]}

  Implementation on the receiver side in the client

  On receiving an update to one of the maps (audio or video), the client adds the signaled SSRCs to the remote description on the peerconnection. The browser then fires a track event for each of the SSRCs, the corresponding remote tracks are then added to the HTMLElements associated with the remote user.

  So when the audio packets with this SSRC arrive, the browser starts decoding the media and plays it through the selected audio output device. If the SSRC is already in use (i.e. the limit on the bridge has been reached) the client updates the owner of the associated track so that it gets attached to the corresponding HTMLAudioElement and the audio switches over to the new speaker seamlessly.

  The video track creation process is the same as that of the audio tracks as described above. The client application needs to update the track’s owner whenever there is an updated source map involving the SSRC that is assigned to the track and re-attach it to the corresponding HTMLVideoElement so that the correct video stream is rendered in the remote participant’s viewport.

  Challenges

  But wait, re-using an SSRC like this is okay for audio because the streams simply get mixed before playback, but what about video, how do we avoid video content being rendered in the wrong viewport when signaling and media race? That’s the elegance of this approach, we simply use a large enough limit (larger than the maximum number of streams forwarded at any one time) and the occurrence becomes extremely unlikely. If the limit is larger by K, then K new forwarding decisions must be made before the signaling arrives at the receiver for the problem to happen.

  So how do we choose the limits? We have the constraint just mentioned, but also an interesting trade-off. If the limit is too high we’re using unnecessary resources at the receivers. But if the limit is too low, we’ll be signaling updates more often. We have chosen to set the limits to 50 by default. That’s 50 for audio and 50 for video, which is well above the maximum of 25 tiles that we display at any time.

  When SSRC rewriting is enabled, the number of source signaling messages can increase drastically based on the SSRC limits set for the conference and the total number of participants in the call. Imagine a call with 100 participants where everyone has their video on; UI shows a grid of 25 participants and the SSRC limit is set to 25. Whenever the user scrolls to the next grid of 25 participants, existing SSRCs get remapped. This happens everytime the user scrolls back and forth. This results in a lot of signaling messages over the bridge channel. What if the websocket connection for the bridge channel is down at this time? This would result in videos not being rendered or audio from new dominant speakers not being heard which can be very disruptive to meetings. All the sources are signaled immediately after the websocket connection reforms but even minimal disruptions to audio can be very annoying.

  To mitigate these issues, Jitsi client switches to using WebRTC’s SCTP data channel for establishing the bridge channel instead of using a websocket. This ensures that the bridge channel is up and running all the time as long as the media connection between the client and the JVB is up. This results in minimal or no disruptions to the signaling messages from the JVB to the downstream endpoints.

  Current status of the feature

  This feature has been well tested and has been running on meet.jit.si for the past few months now, with limits set to 50. We also enabled it by default in our last stable release of the Debian packages and Docker images. We will be releasing it soon to all our production deployments in the next few releases pending investigation into some SCTP crashes that we are seeing in the JVB .

  Your personal meetings team.

  The post Improving performance on very large calls: introducing SSRC rewriting appeared first on Jitsi.

April 19, 2024

• Digium Navigating the Future with Confidence: The Strategic Imperative of On-Premises UC Solutions

  In a digital age where the Unified Communications (UC) landscape is rapidly expanding, On-Premises UC solutions stand out as the bedrock for businesses aiming to secure, customize, and control their communication infrastructures. With the UC market projected to swell to USD 145.58 billion by 2024 and further grow to an impressive USD 496.30 billion by […]

  The post Navigating the Future with Confidence: The Strategic Imperative of On-Premises UC Solutions appeared first on Sangoma Technologies.

• Digium Navigating the Future with Confidence: The Strategic Imperative of On-Premises UC Solutions

  In a digital age where the Unified Communications (UC) landscape is rapidly expanding, On-Premises UC solutions stand out as the bedrock for businesses aiming to secure, customize, and control their communication infrastructures. With the UC market projected to swell to USD 145.58 billion by 2024 and further grow to an impressive USD 496.30 billion by […]

  The post Navigating the Future with Confidence: The Strategic Imperative of On-Premises UC Solutions appeared first on Sangoma Technologies.

April 02, 2024

• Digium Switchvox On-Premises: Alive & Well

  The rumor mill started churning when cloud-based solutions began gaining prominence. These solutions offer scalable, flexible alternatives to traditional on-premises setups. As more companies migrated to the cloud, a narrative emerged suggesting that on-premises solutions like Switchvox were becoming obsolete. Though popular, this view only captures part of the picture. The Reality of Switchvox On-Premises […]

  The post Switchvox On-Premises: Alive & Well appeared first on Sangoma Technologies.

• Digium Switchvox On-Premises: Alive & Well

  The rumor mill started churning when cloud-based solutions began gaining prominence. These solutions offer scalable, flexible alternatives to traditional on-premises setups. As more companies migrated to the cloud, a narrative emerged suggesting that on-premises solutions like Switchvox were becoming obsolete. Though popular, this view only captures part of the picture. The Reality of Switchvox On-Premises […]

  The post Switchvox On-Premises: Alive & Well appeared first on Sangoma Technologies.

March 28, 2024

• Enable Security March 2024: Webex leak, WhatsApp and Apple WebRTC vulnerabilities
  Welcome to the end of March, and this month’s edition of the RTCSec Newsletter. This one’s a short one. In this edition, we cover: German military phone call leak and Webex WhatsApp’s past VoIP stack vulnerabilities and preventing future exploits Security fixes in Apple’s WebRTC framework and baresip WebRTC podcast covers security with Tsahi Levent-Levi RTCSec newsletter is a free periodic newsletter bringing you commentary and news around VoIP and WebRTC security.
• Jitsi Jitsi + Moodle, with a dash of JaaS

  So you want to have live meetings in Moodle courses. Well, as it turns out, this is quite an easy feat. Thanks to the wonderful work done by UDIMA (Universidad a Distancia de Madrid), you can use their Jitsi Moodle Plugin.

  If your use-case doesn’t go beyond 25 monthly individual endpoints, you might want to opt for the JaaS Dev offering which is completely free. For users requiring more than 25 monthly endpoints or desiring premium features like transcriptions, dial-in, recordings or RTMP streaming, there are two options:

  1. Add a credit card for overages, paying extra costs as needed, without any discounts.

  2. Sign up for alternative plans offering an initial discount of 80% off for the first three months of JaaS usage.

  To benefit of the 80% discount you need to use the MOODLE23 JaaS Coupon. The coupon expires on September 2024.

  Setting up the Jitsi Moodle Plugin

  Before starting the configuration process, you need to download and install the latest Jitsi Moodle Plugin in your Moodle instance and create a JaaS account.

  Right off the bat, the plugin tries to use the freely accessible meet.jit.si instance as the backend. This is only going to work for the first five minutes due to the changes announced here. This should be more than enough if you only want to give it a try.

  Once you have created your JaaS Account, here are the steps to configure the plugin:

  Go to the JaaS API Keys section and create a new key pair. Name it something meaningful. Download the private key and store it somewhere safe.

  

  Open the Moodle Jitsi plugin settings and change the values as follows:

  – Domain: `8×8.vc`

  – Server type: pick `8×8 Servers`

  – App_ID: copy it from the JaaS Console API Keys page, i.e. `vpaas-magic-cookie-xxxxx`

  – Api Key ID: copy it from the keys table in the same page, it should be something like `vpaas-magic-cookie-xxxxx/somehex`

  – Private key: the contents of the private key you just downloaded from JaaS Console

  – Make sure to leave the ID User (jitsi_id) dropdown to Username, the default

  

   

  With just a few steps, you’ll now have a complete communication solution right within Moodle!

  Your personal meetings team.

  The post Jitsi + Moodle, with a dash of JaaS appeared first on Jitsi.

March 26, 2024

• Digium PCI Compliance: How the Sangoma P-Series Business Phone System Can Keep You Out of Jail

  There was a time when cash was king. Today, however, not so much. Paying over the phone for everything from fast food to a holiday abroad has become the norm for millions of consumers who prioritise modern convenience over traditional transacting. Protection from fraud is, of course, paramount, which is why strict rules exist. Phones […]

  The post PCI Compliance: How the Sangoma P-Series Business Phone System Can Keep You Out of Jail appeared first on Sangoma Technologies.

• Digium PCI Compliance: How the Sangoma P-Series Business Phone System Can Keep You Out of Jail

  There was a time when cash was king. Today, however, not so much.

  Paying over the phone for everything from fast food to a holiday abroad has become the norm for millions of consumers who prioritise modern convenience over traditional transacting.

  Protection from fraud is, of course, paramount, which is why strict rules exist. Phones used by businesses to take payments must be Payment Card Industry-compliant. They must feature ‘pause-and-resume’ functionality for use at the critical point that customers provide their payment card details. Also, all transactional calls and call recordings must be encrypted.

  Breaching these rules can lead to seriously big fines capable of dealing a catastrophic blow to profit and reputation. Ultimately, in the most extreme cases, non-compliance can even lead to jail!

  Next year, the rules change: an update to the Payment Card Industry Data Security Standard (PCI DDS) which beefs-up protection, but which also places new obligations on in-scope organisations. In a world in which technology plays a vital part in the way over-the-phone transactions occur, it is the perfect time for businesses and their Managed Service Providers to also change things up – upgrading desk and softphones that support that all-important compliance.

  Choose Sangoma’s award-nominated P-Series Desk and Softphone, and that-all important compliance also comes with a feature set that ensures the wider desk calling experience is rich and rewarding for both callers and agents. High-definition audio, unprecedented plug-and-play deployment, and advanced IP applications as standard that include voicemail, call log, contacts, phone status, user presence, call parking, and more. Big and bold, yet at the same time stylish and sleek, its ergonomic design leverages the beauty of angles, curves and corners to provide users with brilliant visibility of and access to its bright touchscreen display and lightweight receiver, regardless of where they sit or stand. The audio is crisp and clear, the management and compliance of calls is fast and effective, and overall satisfaction levels are high. For callers, that overall high-quality reflects favourably on the brands or organisations with which they interact.

  Importantly, the P-Series’ versatile compatibility with both PBX and cloud-based voice systems also means it can be deployed on different platforms in different spaces whilst maintaining an organisation’s look-and-feel. In addition, the P-Series is the only Desk Phone designed to be fully-compatible with Sangoma’s wider communications portfolio – further enhancing its value to Sangoma customers and enabling its commercial reseller partners to benefit from the efficiency and simplicity of stocking and supporting just one Sangoma phone product line. The P-Series brings yet more added value too. The rarest of combinations: it appeals to all types of user groups, at a price point that suits all types of budgets.

  For user organisations and their MSPs, we think that makes for a compelling offer all-round.

  The post PCI Compliance: How the Sangoma P-Series Business Phone System Can Keep You Out of Jail appeared first on Sangoma Technologies.

March 12, 2024

• WebRTC Hacks End-to-End Encryption in WebRTC… 4 Years Later
  

  We covered End-to-end encryption (E2EE) before, first back in 2020 when Zoom’s claims to do E2EE were demystified (not just by us; they later got fined $85m for this), followed by the quite exciting beta implementation of E2EE in Jitsi using Chromium’s Insertable Streams API. A bit later we had Matrix explain how their approach […]

  The post End-to-End Encryption in WebRTC… 4 Years Later appeared first on webrtcHacks.

February 29, 2024

• Enable Security February 2024: manipulating audio using LLM, malware using CPaaS and WebRTC security
  Special day today, being a leap year! In other news, this month brought quite a bit of written content of interest to the VoIP and WebRTC security community, which we’re covering here: Generative AI on live audio conversations (sorry!) Vulnerabilities affecting Yealink, WebRTC and OpenScape Hardening WhatsApp’s VoIP library and new mobile malware using CPaaS WebRTC related security content courtesy of Staex, Mozilla and Fonoster FCC rules affecting VoIP providers and telcos RTCSec newsletter is a free periodic newsletter bringing you commentary and news around VoIP and WebRTC security.

February 21, 2024

• Jitsi Google Summer of Code 2024

  We’re happy to announce that Jitsi will be participating in Google Summer of Code 2024!

  We have some very cool project ideas in the list for this year, and we’re still open to discussing new ones.

  You can also check out the official program website, the list of accepted organizations and the full program timeline.

  The next important date is March 18 when the contributor application period opens. In the meantime, please join me in welcoming the new contributors to our community!

   

  The post Google Summer of Code 2024 appeared first on Jitsi.

• Digium Powering Patient Touchpoints: Sangoma’s Cure for Communication Roadblocks

  In today’s healthcare landscape, the patient experience hinges on seamless communication. This is where Sangoma Technologies makes an indelible mark. With their unified communications as a service (UCaaS) portfolio, end-to-end solutions are crafted that enhance patient care, streamline processes, and reduce costs.

  Sangoma CX stands as a testament to this commitment, magnifying call-handling capabilities and more than doubling call volumes for healthcare providers, as evidenced by the transformation of the Healthcare Physicians Group. The robust reporting suite of Sangoma CX, coupled with its callback features, optimizes patient touchpoints, ensuring no call – and no patient – is left unanswered.

  Furthermore, Sangoma’s integrated suite of value-based Communications as a Service solutions allows care organizations of all sizes to maximize productivity. This means healthcare institutions can focus on what they do best – providing top-notch patient care – while Sangoma takes care of the rest.

  With the help of Sangoma Apps, outreach initiatives are taken to new heights. From online scheduling to automated reminders, every interaction is personalized, enhancing the patient experience at every turn. Video conferencing is a must for telemedicine, and Sangoma delivers a consistent and feature-rich experience for virtual consultations, becoming a partner to deliver exceptional patient care.

  The results speak for themselves. Hospitals, pharmacies, and labs report improved patient care and significant time savings in emergency handling – up to 50% in some cases. The future of healthcare communication is here, and it’s powered by Sangoma.

  Learn more about our solutions in the Sangoma Healthcare eBook.

  The post Powering Patient Touchpoints: Sangoma’s Cure for Communication Roadblocks appeared first on Sangoma Technologies.

• Digium Powering Patient Touchpoints: Sangoma’s Cure for Communication Roadblocks

  In today’s healthcare landscape, the patient experience hinges on seamless communication. This is where Sangoma Technologies makes an indelible mark. With their unified communications as a service (UCaaS) portfolio, end-to-end solutions are crafted that enhance patient care, streamline processes, and reduce costs.

  Sangoma CX stands as a testament to this commitment, magnifying call-handling capabilities and more than doubling call volumes for healthcare providers, as evidenced by the transformation of the Healthcare Physicians Group. The robust reporting suite of Sangoma CX, coupled with its callback features, optimizes patient touchpoints, ensuring no call – and no patient – is left unanswered.

  Furthermore, Sangoma’s integrated suite of value-based Communications as a Service solutions allows care organizations of all sizes to maximize productivity. This means healthcare institutions can focus on what they do best – providing top-notch patient care – while Sangoma takes care of the rest.

  With the help of Sangoma Apps, outreach initiatives are taken to new heights. From online scheduling to automated reminders, every interaction is personalized, enhancing the patient experience at every turn. Video conferencing is a must for telemedicine, and Sangoma delivers a consistent and feature-rich experience for virtual consultations, becoming a partner to deliver exceptional patient care.

  The results speak for themselves. Hospitals, pharmacies, and labs report improved patient care and significant time savings in emergency handling – up to 50% in some cases. The future of healthcare communication is here, and it’s powered by Sangoma.

  Learn more about our solutions in the Sangoma Healthcare eBook.

  The post Powering Patient Touchpoints: Sangoma’s Cure for Communication Roadblocks appeared first on Sangoma Technologies.

February 20, 2024

• Digium More AI Features for Your Contact Center With Sangoma CX 7.5

  Building on the new, powerful AI features introduced to Sangoma CX already in 2024, our cloud contact center solution now expands its automation capabilities and adds other significant enhancements with our 7.5 release. The new version is even more capable, empowering agents, supervisors, and administrators in their day-to-day operations.

  New Features in CX 7.5

   

  • AI Assist: Agents can now leverage the amazing powers of OpenAI for generating content effortlessly in Digital Channels. Boost response times and improve overall customer service by getting reply suggestions, spelling and grammar fixes, changing message length or tone, and simplifying what you want to tell your customer.

  

  • Speech Analytics: Available as a queue configuration setting for CX Premium Users, the novel Speech Analytics feature processes audio recordings to automatically generate call transcriptions, summaries, and sentiment analysis. Call sentiment, which can be positive, negative, or neutral, is provided for both individual call parties and for the overall conversation. The analytics capabilities will help supervisors easily gather valuable insights from audio data to audit agent-customer interactions.

  

  • Queue Status Viewer: Agents can now view the status of all queues they are assigned to at a glance, regardless of whether they are logged in to that queue or not. Accessible directly from the Agent Panel, this feature allows agents to easily identify which queues require their attention based on caller volume, and to provide help where their presence is most needed at any given time.

  

  • Phone Book Import: Seamlessly add Contacts in bulk to the embedded Phone Book in CX by importing a CSV file in a predefined template format.

  

  • Stop call recording on transfers: By default, if call recording is enabled, audio conversations continue to be recorded even after being transferred. However, in certain cases you may need to stop recording, such as when sensitive information is involved, for instance, in the case of a transfer to a doctor’s office. Now, you have the option to halt call recording during transfers for compliance purposes.

   

  Release 7.5 also brings several other minor improvements, like the capability to export the Queue Annual report to a spreadsheet format, and a new simplified implementation for logging agent call flow for phone-only Agents, in simple call center setups. These improvements enhance the overall functionality and user experience for contact center administrators.

  If you have any questions, need a quote, or require assistance with these new features, please reach out to us.

  Stay tuned for updates on upcoming enhancements and exciting new features in Sangoma CX!

   

  Sincerely,

  The Sangoma Product Team

   

   

  Learn More

   

  Sangoma CX Release Notes

  Sangoma CX Knowledge Base

  Partner Release Kit

  The post More AI Features for Your Contact Center With Sangoma CX 7.5 appeared first on Sangoma Technologies.

• Digium More AI Features for Your Contact Center With Sangoma CX 7.5

  Building on the new, powerful AI features introduced to Sangoma CX already in 2024, our cloud contact center solution now expands its automation capabilities and adds other significant enhancements with our 7.5 release. The new version is even more capable, empowering agents, supervisors, and administrators in their day-to-day operations.

  New Features in CX 7.5

   

  • AI Assist: Agents can now leverage the amazing powers of OpenAI for generating content effortlessly in Digital Channels. Boost response times and improve overall customer service by getting reply suggestions, spelling and grammar fixes, changing message length or tone, and simplifying what you want to tell your customer.

  

  • Speech Analytics: Available as a queue configuration setting for CX Premium Users, the novel Speech Analytics feature processes audio recordings to automatically generate call transcriptions, summaries, and sentiment analysis. Call sentiment, which can be positive, negative, or neutral, is provided for both individual call parties and for the overall conversation. The analytics capabilities will help supervisors easily gather valuable insights from audio data to audit agent-customer interactions.

  

  • Queue Status Viewer: Agents can now view the status of all queues they are assigned to at a glance, regardless of whether they are logged in to that queue or not. Accessible directly from the Agent Panel, this feature allows agents to easily identify which queues require their attention based on caller volume, and to provide help where their presence is most needed at any given time.

  

  • Phone Book Import: Seamlessly add Contacts in bulk to the embedded Phone Book in CX by importing a CSV file in a predefined template format.

  

  • Stop call recording on transfers: By default, if call recording is enabled, audio conversations continue to be recorded even after being transferred. However, in certain cases you may need to stop recording, such as when sensitive information is involved, for instance, in the case of a transfer to a doctor’s office. Now, you have the option to halt call recording during transfers for compliance purposes.

   

  Release 7.5 also brings several other minor improvements, like the capability to export the Queue Annual report to a spreadsheet format, and a new simplified implementation for logging agent call flow for phone-only Agents, in simple call center setups. These improvements enhance the overall functionality and user experience for contact center administrators.

  If you have any questions, need a quote, or require assistance with these new features, please reach out to us.

  Stay tuned for updates on upcoming enhancements and exciting new features in Sangoma CX!

   

  Sincerely,

  The Sangoma Product Team

   

   

  Learn More

   

  Sangoma CX Release Notes

  Sangoma CX Knowledge Base

  Partner Release Kit

  The post More AI Features for Your Contact Center With Sangoma CX 7.5 appeared first on Sangoma Technologies.