Runs test voice configurations to ensure voice routing and policies work as expected.
Syntax
Test-CsVoiceTestConfiguration -TestCaseInputObject <TestConfiguration> [-Dialplan <LocationProfile>] [-Force <SwitchParameter>] [-RouteSettings <PstnRoutingSettings>] [-VoicePolicy <VoicePolicy>] |
Test-CsVoiceTestConfiguration -DialedNumber <PhoneNumber> -Dialplan <LocationProfile> -VoicePolicy <VoicePolicy> [-Force <SwitchParameter>] [-RouteSettings <PstnRoutingSettings>] |
Parameters
Parameter | Required | Type | Description |
---|---|---|---|
DialedNumber |
Required |
PhoneNumber |
The phone number to run the test against. Based on the dial plan, route, and policy, this number will be normalized and displayed as output. This parameter is required unless the TestCaseInputObject parameter is supplied with a value. You cannot supply a DialedNumber and a TestCaseInputObject. (The TestCaseInputObject already contains a DialedNumber within that object.) |
Dialplan |
Required |
LocationProfile |
A reference to a dial plan object of the dial plan to use when running the test. Dial plan objects can be retrieved by calling the Get-CsDialPlan cmdlet. This parameter is required if you’ve also specified the DialedNumber parameter. Do not use this parameter if you are using the TestCaseInputObject parameter. If you do, the object in this parameter must match the dial plan specified in the TestCaseInputObject, making the use of this parameter redundant. |
TestCaseInputObject |
Required |
TestConfiguration |
An object containing a reference to the voice configuration to test. This object reference can be retrieved by calling the Get-CsVoiceTestConfiguration cmdlet. If you call the cmdlet with this parameter, you cannot specify a DialedNumber. You should also not specify a Dialplan or VoicePolicy, as those would be redundant with the values in the voice test configuration object. |
VoicePolicy |
Required |
VoicePolicy |
A reference to a voice policy object of the voice policy to use when running the test. Voice policy objects can be retrieved by calling the Get-CsVoicePolicy cmdlet. This parameter is required if you’ve also specified the DialedNumber parameter. Do not use this parameter if you are using the TestCaseInputObject parameter. If you do, the object in this parameter must match the voice policy specified in the TestCaseInputObject, making the use of this parameter redundant. |
RouteSettings |
Optional |
PstnRoutingSettings |
A reference to an object containing all the voice routes available on the Communications Server installation. You can retrieve this object by calling the Get-CsRoutingConfiguration cmdlet. You can use this parameter with either the DialedNumber parameter or with the TestCaseInputObject parameter. |
Force |
Optional |
SwitchParameter |
Suppresses any confirmation prompts that would otherwise be displayed before making changes. |
Detailed Description
Before implementing voice routes and voice policies, it's a good idea to test them out on various phone numbers to ensure the results are what you're expecting. Running this cmdlet with the appropriate parameter settings allows you to run these tests.
This cmdlet tests a phone number against the voice route, usage, dial plan, and voice policy to compare the actual outcome to the expected outcome. The voice configurations to be tested can be defined by using the New-CsVoiceTestConfiguration cmdlet.
This cmdlet returns whether the test passed or failed, comparing the input values to the expected results. The output from this cmdlet also includes which normalization rules were used to achieve the results, as well as which route and usage were used.
Return Types
This cmdlet returns an object of type Microsoft.Rtc.Management.Voice.OcsVoiceTestResult.
Examples
-------------------------- Example 1 --------------------------
Copy Code | |
---|---|
Get-CsVoiceTestConfiguration -Identity TestConfig1 | Test-CsVoiceTestConfiguration |
This example runs a voice configuration test against configuration TestConfig1. First the Get-CsVoiceTestConfiguration cmdlet is run to retrieve the configuration with the Identity TestConfig1. That configuration object is then piped to the Test-CsVoiceTestConfiguration cmdlet.
-------------------------- Example 2 --------------------------
Copy Code | |
---|---|
$a = Get-CsVoiceTestConfiguration -Identity TestConfig1 Test-CsVoiceTestConfiguration -TestCaseInputObject $a |
Example 2 is identical to Example 1 except that instead of piping the results of the Get operation directly to the Test cmdlet, the object is first stored in the variable $a, and then is passed as the value to the parameter TestCaseInputObject to be used as the test configuration.
-------------------------- Example 3 --------------------------
Copy Code | |
---|---|
$dp = Get-CsDialPlan -Identity Global $vp = Get-CsVoicePolicy -Identity Global Test-CsVoiceTestConfiguration -DialedNumber 4255551212 -Dialplan $dp -VoicePolicy $vp |
This example runs a test configuration without first having to define it with New-CsVoiceTestConfiguration. Instead of passing a TestConfiguration object created ahead of time, this example shows how to set up a test “on the fly” by specifying the dialed number to test, and the dial plan and voice policy against which to perform the test.
The first line in this example calls the Get-CsDialPlan cmdlet to retrieve the Global dial plan. The dial plan object retrieved is assigned to the variable $dp. In the second line, we do the same thing with the voice policy by calling the Get-CsVoicePolicy cmdlet to retrieve the Global voice policy, and then assigning that policy to the variable $vp.
Finally, we’re ready to run the test. We call Test-CsVoiceTestConfiguration, passing the phone number to test to the DialedNumber parameter, the dial plan we retrieved in line 1 (stored in $dp) to the Dialplan parameter, and the voice policy we retrieved in line 2 (stored in $vp) to the VoicePolicy parameter.