Monday, 27 February 2017

AudioCodes Mediant Virtual SBC Transcoding Requirements

This blog post covers an interesting issue that I ran into the other day with AudioCodes Mediant Virtual Edition and getting transcoding capabilities working on VMWare. The AudioCodes Virtual Edition SBCs are very capable and are great for SIP Trunk deployments and routing calls between various SIP platforms. They can support a large number of non-transcoded calls as well as supporting transcoding for audio and DTMF streams. In a hardware SBC, transcoding is usually done with a DSP chip that is used to convert one codec to another codec. However, in a Virtual SBC this is done using the CPU cores provided to the virtual machine.

The requirement for transcoding in a deployment can come up when connecting to carriers with mandatory codec requirements like G.729 (a low bandwidth codec) that are not supported by Skype for Business. In these cases, if the carrier decides to send a call inbound with only G.729 (or some other unsupported codec) as the only media type available in the INVITE SDP, rather than reject the call, we can have the SBC transcode between the two different codecs.

So what is required for transcoding to work on the AudioCodes Virtual Edition SBC? Just CPU cores right? Well, not exactly… Continue on, intrepid reader…



CPU Specifications


The AudioCodes manuals are quite clear with their requirements for how many CPU Cores are required to support different numbers of sessions and transcoding capabilities. These range from low spec VMs with only 2 cores up to 8 cores (as of version 7.2). For details of the number of CPU Cores required for each scenario, I suggest you check out the latest Mediant Virtual Edition User Guide (the Channel Capacity section).

In addition to the number of CPU Cores required, the 7.0 and 7.2 manuals for the AudioCodes Virtual Edition both state the following about CPU requirements:

Specifications Resource
Specifications
Processor type
64-bit Intel® CPU of at least 2.5 GHz, with support for hardware virtualization (Intel VT-x) enabled with Advanced Vector Extensions (AVX) and AES-NI support (Sandy-Bridge architecture or newer)

Whilst usually the exact specifications of a CPU that an application vendor lists can be taken as a generic baseline for the systems that they may have done capacity testing on, in this case the CPU capabilities absolutely matter! It seems that when the Virtual Edition was designed, the code used for transcoding was specifically targeted for CPUs that support the AVX feature set introduced in Sandy Bridge CPUs. When the Virtual SBC boots, it checks the CPU capacities and if it is not at least Sandy Bridge level (with AVX support) then the SBC transcoding capabilities will not be available!
This limitation has some additional flow-on effects depending on the hypervisor on which it is being deployed. See the following section for more details of these limitations.

VMWare and CPU Capabilities


In addition to the raw CPU capabilities in the host machines (ie. Sandy Bridge generation of processors with AVX support), a VMWare environment using vMotion also can be configured with a specific level of processor support across all hosts in a vMotion cluster. This is a feature within VMWare that is called Enhanced vMotion Compatibility (EVC) and controls the level of CPU capabilities being emulated at the VM level across multiple machines. This ensures that the same CPU capabilities are presented for all machines in a cluster, and protects against having differing CPU capabilites when VMs are migrated between hosts. This can mean that even if the host machine has a Sandy Bridge CPU, this capability set may not be passing through to the VM on which the SBC is running.

The VMWare vMotion EVC level will be used when the host machines in a cluster have different levels of CPU capabilities. The lowest CPU capability will be the one that is emulated for all machines in the cluster. So, whilst many of the hosts may have Sandy Bridge or above CPUs, there may be lower capability machines included in the cluster that force the EVC baseline in VMWare to be configured to a lower CPU feature set. This setting can directly affect the Virtual Edition SBC's ability to support transcoding, because even if the host has Sandy Bridge capabilities the VMWare environment might be masking these capabilities and presenting a lower CPU level than is actually in the host.

Below is a table that describes the various EVC levels that can be configured within VMWare:

VMWare Description of Intel EVC Baselines:
EVC Level
EVC Baseline
Description
L0
Intel® "Merom" Gen. (Intel® Xeon® Core™ 2)
Applies baseline feature set of Intel® "Merom" Generation (Intel® Xeon® Core™ 2) processors to all hosts in the cluster.
L1
Intel® "Penryn" Gen. (formerly Intel® Xeon® 45nm Core™ 2)
Applies baseline feature set of Intel® "Penryn" Generation (Intel® Xeon® 45nm Core™ 2) processors to all hosts in the cluster.
Compared to the Intel® "Merom" Generation EVC mode, this EVC mode exposes additional CPU features including SSE4.1.
L2
Intel® "Nehalem" Gen. (formerly Intel® Xeon® Core™ i7)
Applies baseline feature set of Intel® "Nehalem" Generation (Intel® Xeon® Core™ i7) processors to all hosts in the cluster.
Compared to the Intel® "Penryn" Generation EVC mode, this EVC mode exposes additional CPU features including SSE4.2 and POPCOUNT.
L3
Intel® "Westmere" Gen. (formerly Intel® Xeon® 32nm Core™ i7)
Applies baseline feature set of Intel® "Westmere" Generation (Intel® Xeon® 32nm Core™ i7) processors to all hosts in the cluster. Compared to the Intel® "Nehalem" Generation mode, this EVC mode exposes additional CPU features including AES and PCLMULQDQ.
L4
Intel® "Sandy Bridge" Generation
Applies baseline feature set of Intel® "Sandy Bridge" Generation processors to all hosts in the cluster. Compared to the Intel® "Westmere" Generation mode, this EVC mode exposes additional CPU features including AVX and XSAVE.
L5
Intel® "Ivy Bridge" Generation
Applies baseline feature set of Intel® "Ivy Bridge" Generation processors to all hosts in the cluster. Compared to the Intel® "Sandy Bridge" Generation EVC mode, this EVC mode exposes additional CPU features including RDRAND, ENFSTRG, FSGSBASE, SMEP, and F16C.
L6
Intel® "Haswell" Generation
Applies baseline feature set of Intel® "Haswell" Generation processors to all hosts in the cluster. Compared to the Intel® "Ivy Bridge" Generation EVC mode, this EVC mode exposes additional CPU features including ABMX2, MOVBE, FMA, PERMD, RORX/MULX, INVPCID, VMFUNC. 


In order for AVX to be supported in a large VMWare environment, the Processor Support needs to be configured at a minimum of L4 Sandy Bridge level. If EVC mode is not being used the EVC mode may display as "N/A" or "disabled", both of these modes will allow for the raw processor capabilities to be passed through to the SBC, which will also allow for transcoding to work if the CPU is Sandy Bridge or above.



The host EVC level can be viewed in the host summary page within vSphere. In the example below the current EVC level is set to Merom Generation or L0 level which would not support transcoding:



Hyper-V Processor Compatibility Mode


I haven’t actually tested this on Hyper-V because transcoding on Hyper-V has only been supported as of 7.2 software. However, Hyper-V also has a CPU Compatibility mode feature which allows for various features that involve moving VMs between machines (eg. Live Migration, Quick Migration and Save/Restore features). This feature is similar to VMWare EVC mode, however, the implementation is slightly different than VMWare. When the Processor Compatibility mode is enabled in Hyper-V the CPU (for Intel and AMD CPUs) feature set gets “normalised” by removing extended feature sets of the each CPU type to lower the capabilities to a baseline.

For the Microsoft documentation, when a VM in processor compatibility mode is started, the following processor features are hidden from the VM:

Host running Intel based processor
SSSE3, SSE4.1, SSE4.2, POPCNT, Misaligned SSE, XSAVE, AVX


You will note that AVX is one of the hidden features, which is one of the features required for the AudioCodes Virtual Edition SBC to work! Uh-oh…

When this feature was released, the following Q&A was documented about this functionality:

From the Hyper-V Compatibility Mode Q and A:

Q: Can I individually select which features should be hidden from VM when put in processor compatibility mode?
A:  No, once you put VM in a processor compatibility mode, Hyper-V will hide the necessary set of features from the VM to ensure a successful migration between Hyper-V enabled processors. 

Q: What happens if a vendor has written an application that uses one of these features that isn’t visible with processor compatibility enabled?
A: Since the feature isn’t exposed to the virtual machine, the application won’t “see it” and it’s up to the application to determine how to proceed; however, there are two likely paths.

So presumably the CPU compatibility feature within Hyper-V is going to cause the AudioCodes Virtual Edition SBC to not be able to see the AVX capabilities of the CPU. As a result, transcoding will likely not work on Hyper-V if processor compatibility mode is enabled.


Hyper-V Processor Compatibility References:


Checking CPU Capabilities after Installation


If the Virtual Edition SBC has been installed within a virtual environment, you can tell if the hardware will support transcoding by checking the following CLI commands:

Working Transcoding example:
Mediant VE SBC> show system hardware
  CPU: Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz, total 4 cores avx support(avx)
  Memory: total RAM: 4096 MB
  Chassis: VMware Virtual Platform
  Network:
          VMware VMXNET3 Ethernet Controller (rev 01)
          VMware VMXNET3 Ethernet Controller (rev 01)
  Virtual env: vmware
Mediant VE SBC>

In the example above you can see that the CPU has “avx support (avx)”. Transcoding will work on this server.

Non-supported hardware example:
Mediant VE SBC# show system hardware
  CPU: Intel(R) Xeon(R) CPU           X5650  @ 2.67GHz, total 4 cores avx support(none)
  Memory: total RAM: 8192 MB
  Chassis: VMware Virtual Platform
  Network:
          VMware VMXNET3 Ethernet Controller (rev 01)
          VMware VMXNET3 Ethernet Controller (rev 01)
          VMware VMXNET3 Ethernet Controller (rev 01)
  Virtual env: vmware
Mediant VE SBC#

In the example above you can see that the CPU has “avx support (none)”. Transcoding will not work on this server.


Web Interface Check


The only way to tell from the web interface whether or not the current server hardware will support transcoding is to download the configuration file and check the following:

Transcoding Working Example:
;Board: Mediant VE SBC
;HW Board Type: 73  FK Board Type: 79
;Product Key:
;Slot Number: 1
;Software Version: 7.00A.095.004
;DSP Software Version: SOFTDSP => 700.53
;Board IP Address: 10.20.1.168
;Board Subnet Mask: 255.255.255.0
;Board Default Gateway: 10.20.1.1
;Ram size: 3831M   Flash size: 0M
;Num of DSP Cores: 3  Num DSP Channels: 100
;Profile: NONE
;Client defaults file is being used (file length=352)

In this working example the configuration file displays that it has discovered 3 DSP Cores and has 100 DSP channels available for transcoding.


Transcoding Not Working Example:

In this example, the configuration file displays that it has discovered 0 DSP Cores and has 0 DSP channels available for transcoding. In this case the SBC has detected that the CPU does not have AVX support and as a result will not support transcoding.

;Board: Mediant VE SBC
;HW Board Type: 73  FK Board Type: 79
;Product Key:
;Slot Number: 1
;Software Version: 7.00A.095.004
;DSP Software Version: SOFTDSP => 700.53
;Board IP Address: 10.20.1.165
;Board Subnet Mask: 255.255.255.0
;Board Default Gateway: 10.20.1.1
;Ram size: 7871M   Flash size: 0M
;Num of DSP Cores: 0  Num DSP Channels: 0
;Profile: NONE
;Client defaults file is being used (file length=352)


Example of Transcoding Failure Errors


When the transcoding resources are not available due to a lack of CPU support for AVX, you will see errors complaining about a lack of resources in the log at the time of the SBC trying to apply extension coders or setting up the call:
22:41:25.812  147.76.26.84    local0.notice  [S=4742] [SID=a64ab9:33:279]  (      lgr_flow)(      4645)  #MediaResourcesConnector::AllocateMediaResources
22:41:25.812  147.76.26.84    local0.notice  [S=4743] [SID=a64ab9:33:279]  ( media_connect)(      4646)  ConnectionData::CalculateResourcesForExtTranscoding Leading:DSP Opposite:CODERTRANSCODING MediationLevel:RTP
22:41:25.812  147.76.26.84    local0.notice  [S=4744] [SID=a64ab9:33:279]  ( media_service)(      4647)  ServicesMngr: Allocate Coder Transcoding session. current active: 0 and max is: 250
22:41:25.812  147.76.26.84    local0.notice  [S=4745] [SID=a64ab9:33:279]  ( media_service)(      4648)  ServicesMngr: Allocate Media channel. current active: 0 and max is: 0
22:41:25.812  147.76.26.84    local0.warn    [S=4746] [SID=a64ab9:33:279]  ( media_service)(      4649) !! [ERROR] ServicesMngr: Cannot allocate more Media channel. current active: 0 and max is: 0
22:41:25.812  147.76.26.84    local0.warn    [S=4747] [SID=a64ab9:33:279]  (      lgr_flow)(      4650) !! [ERROR] (#2198)RTPStreamResource::AllocateResource Allocate Resource - cannot allocate DSP. probably lack of resources
22:41:25.812  147.76.26.84    local0.notice  [S=4748] [SID=a64ab9:33:279]  ( media_service)(      4651)  ServicesMngr: Deallocate Coder Transcoding session. current active: 1 and max is: 250
22:41:25.812  147.76.26.84    local0.notice  [S=4749] [SID=a64ab9:33:279]  ( media_service)(      4652)  ServicesMngr: Allocate Coder Transcoding session. current active: 0 and max is: 250
22:41:25.812  147.76.26.84    local0.notice  [S=4750] [SID=a64ab9:33:279]  ( media_service)(      4653)  ServicesMngr: Allocate Media channel. current active: 0 and max is: 0



Licensing


In addition to the CPU requirements, you will also need licensing for transcoding to work. The CODER-TRANSCODING licence must be available in the licence installed on the SBC. The CODER-TRANSCODING licence will appear in the licence as shown below:

Key features:
Board Type: Mediant VE SBC
IP Media: VXML
Coders: G723 G729 G728 NETCODER GSM-FR GSM-EFR AMR EVRC-QCELP G727 ILBC EVRC-B AMR-WB G722 EG711 MS_RTA_NB MS_RTA_WB SILK_NB SILK_WB SPEEX_NB SPEEX_WB OPUS_NB OPUS_WB
Channel Type: DspCh=100 IPMediaDspCh=100
HA
Security: IPSEC MediaEncryption StrongEncryption EncryptControlProtocol
DSP Voice features:
DATA features:
Control Protocols: MGCP SIP SBC=10 MSFT FEU=50 CODER-TRANSCODING=50
Default features:
Coders: G711 G726

If you do not have the CODER-TRANSCODING licence then the SBC will still run, however transcoding functionality will not be available.


The Wrap Up


So before jumping in to the Virtual Edition SBC world with your customers, be sure to understand the server and Hypervisor environment that you are deploying the SBC into. Some useful questions to ask up front are:
  • What hypervisor will the SBC be installed on?
  • Have you purchased CODER-TRANSCODING licences for the SBC?
  • Is the hypervisor server host CPU at least Sandy Bridge level and does it support AVX?
  • If vMotion is being used within VMWare: What is the VMWare vMotion EVC baseline of the host that the SBC is deployed on?
  • If Hyper-V is being used, is Processor Capability mode disabled?
  • Have you ensured that the hypervisor is going to have enough dedicated CPU Cores available for the SBC? Also, note that the CPU resource must be reserved for the SBC and not shared.

Armed with this information, you will be able to make an informed assessment on whether or not transcoding is going to be supported on the Virtual Edition SBC! Hope this was helpful. Cheers!



Read more →

Tuesday, 17 January 2017

Skype for Business Rate My Call Viewer Tool

Rate My Call is a feature in Skype for Business that provides enterprises a way of acquiring feedback from their end-users via a special dialog window that pops up after a specified number of calls. The Rate My Call dialog window offers a combination of star rating system, predefined feedback checkboxes for audio and video calls, as well as the option for custom text based feedback. This gives the administrator a method for adding real user feedback to the existing Quality of Experience statistics that have been available since Lync was first introduced.



Rate My Call Prerequisites


In order to use the Rate My Call feature you will need the following pre-requisites:
  • You must have Skype for Business Server installed;
  • Users need to have a client version 15.0.4711.1002 or later and using the Skype for Business UI;
  • The RateMyCallDisplayPercentage in Client Policy must be set to a value larger than 0;
  • Users must be homed on a Skype for Business Server front end pool; and
  • The Skype for Business environment must have a monitoring database deployed.

Rate My Call Settings


The Rate My Call feature has two settings within Client Policy: Display Percentage and Allow Custom User Feedback. The Display Percentage is the percentage of calls that the user will be asked to provide feedback on. The percentage number is very important because if you set this value too high it can result in user survey fatigue whereby users stop providing relevant feedback due to being asked too often. The Allow Custom feedback setting is used to give users the ability to offer specific text based feedback in addition to their star rating and standard checkbox responses. The custom feedback can be great for drilling deeper into what the actual issue may be that the user is experiencing, rather than trying to interpret checkboxes responses that may not exactly match the user's experience.

There is no action required to enable the base feature, however custom feedback will need to be enabled separately if it is desired. The Rate My Call feature is automatically enabled in the Client Policy with the following defaults:
  • Rate My Call Display Percentage – 10%
  • Rate My Call Allow Custom User Feedback – disabled
If you have deployed Skype for Business and not changed the defaults, you may already have some data saved within the Monitoring database that you can start analysing.

The following Windows PowerShell cmdlet is an example of enabling custom end user feedback and changing the interval from 10% to 80%.

Configuring Rate My Call:
Set-CSClientPolicy -Identity <PolicyIdentity> -RateMyCallDisplayPercentage 80 - RateMyCallAllowCustomUserFeedback $true

The feature can be completely turned off by setting the RateMyCallDisplayPercentage to 0%.


Accessing Rate My Call Data


When the Rate My Call feature was introduced in Skype for Business Server, there was no interface added to the in the Skype for Business Monitoring Reports interface (which is still true to this day). There was, however, access added in the Call Quality Dashboard product which often doesn’t get deployed due to the overhead of additional SQL server(s) infrustructure. Technet does offer a couple of SQL query examples for getting the basic data out of the system. However, this is not particularly user friendly, so I thought I might make a simple Powershell tool for pulling out data and visualizing it so you can start compiling the user feedback that you may already have stored in your Monitoring database.


Rate My Call Viewer Tool




Features:
  • Select your required start and end date, rating filter (above or below the selected rating), SIP URI filter, Reason filter, and Voice and/or Video to be listed up. Note: the filters use regex, so for example you could use it to filter for multiple reasons using the OR Operator like this “echo|backgroundnoise”.
  • Export all events into CSV format.
  • Create graphs (Stars Bar Graph, Stars Pie Graph, Reason Pie Graph, Reason Bar Graph, Type Pie Graph, Stars Stacked Bar Graph, Trend Over Time Line) of your Call Rating data.

Version 1.01 Update:
  • Added the ability to select individual monitoring servers from a drop down box. This was added for large environments that have multiple monitoring databases and only want to retrieve statistics from one at a time. By default, all monitoring database will be queried.
  • Added a check for the database version. The tool only works on Skype for Business databases so the check makes sure the database is at least Version 7 (ie. Skype for Business level).
Version 1.02 Update (20/04/2017)
  • Added date/time localisation checkbox. By default the monitoring server records time is in GMT. This update adds a checkbox to localise all the date/time values to be in the timezone of the server you are running it on (instead of GMT). This changes the date pickers as well as the date displayed in the list and graphs.
  • Added the ability to zoom in on the Trend Over Time chart. You do this by clicking and dragging the mouse on the area of the graph you want to zoom to, scroll bars will appear so you can scroll the zoomed in view.
Version 1.03 Update (22/04/2017)
  • Fixed an issue with the SQL query used for Video / Audio. The query now gets all records.
  • Fixed issue with data grid view scroll bar refresh.
  • Fixed a sorting issue with the Stacked Bar and Trend Over Time Graphs that would cause an issue with the output.
  • More accurate graphs! When both video and voice are selected the rating data gets listed twice for each call because video calls contain both voice and video ratings. So in previous versions the star ratings were counted as separate calls which artificially inflated the star rating value given. In this version the double counting of this data has been removed from star rating graphs, with the voice and video star rating given by each user being combined. 


Prerequisites:
  •  This tool should be run on a machine that has the Skype for Business powershell module installed. This is required because the "Get-CSService" command is used to discover the location of the Montoring Database.
  • The user running the tool needs to have sufficient rights to run select queries on the "QoEMetrics" database and SELECT access on the following tables: Session, AudioStream, CallQualityFeedback, CallQualityFeedbackToken, CallQualityFeedbackTokenDef, User, MediaLine

Download from Technet Gallery:




Built-in Graphs


The Stars Bar Graph is the simpliest way to quickly see the how the users are rating calls on the system. In general you can ignore 0 star ratings because they these will be non-rated calls.



The Reason Bar Graph allows you to easily see trends in the number of each type of issue reported by users. This can be useful for picking out specific types of problems in your network.


  
The Reason Pie graph give you a quick view of which types of issues are most prevalent within your environment.


  
The Starts Pie Graph give you an idea of the how pleased your users are overall with the quality of calls within the environment.



The Stars Stacked Bar Graph allows you to differentiate between the ratings of Video and Voice calls separately from each other. This will allow you to understand if the either of the modality types is having more issues than the other. This will allow you to make choices about what to focus your future troubleshooting on.



The Type Pie Chart gives you an extremely simple depiction whether users are having more issues with Voice or Video calls within the environment.



The Trend Over Time Line is useful for tracking over time how the call quality has been changing within the environment. Note: if you are graphing over a long period of time it can be useful to maximize the graph window to see more details in the graph.



The Wrap Up


Well there it is! Now listening to your users is as simple by turning on the Rate My Call feature (which by default is already on!) and using this tool to extract and graph your data. In addition to the standard QoE statistics that the system offers, the Call Rating System built into Skype for Business can be an invaluable tool to understand your network quality. Enjoy!



Read more →

Popular Posts