Test-CsPstnPeerToPeerCall -TargetFqdn <String> [-Force <SwitchParameter>] [-OutVerboseVariable <String>] [-ReceiverSipAddress <String>] [-RegistrarPort <Nullable>] [-SenderSipAddress <String>]

Test-CsPstnPeerToPeerCall -TargetFqdn <String> -ReceiverCredential <PSCredential> -ReceiverSipAddress <String> -SenderCredential <PSCredential> -SenderSipAddress <String> [-Force <SwitchParameter>] [-OutVerboseVariable <String>] [-RegistrarPort <Nullable>]

Parameters

Test-CsPstnPeerToPeerCall is an example of a Communications Server "synthetic transaction." Synthetic transactions are used in Microsoft Communications Server to verify that users are able to successfully complete common tasks such as logging on to the system, exchanging instant messages, or making calls to a phone located on the Public Switched Telephone Network (PSTN). These tests can be conducted "manually" by an administrator, or they can be automatically run by an application such as Microsoft System Center Operations Manager.

Synthetic transactions are typically conducted in two different ways. Many administrators will use the CsHealthMonitoringConfiguration cmdlets to set up a "health registrar" for each of their registrar pools. A health registrar is nothing more than a pair of users who have been preconfigured for use with synthetic transactions. (Typically these are test accounts and not accounts belonging to actual users.) With a health registrar configured for a pool, administrators can simply run a synthetic transaction against that pool without having to specify the identities of (and supply the credentials for) the user accounts involved in the test.

Alternatively, administrators can run a synthetic transaction using actual user accounts. For example, if two users are unable to exchange instant messages, an administrator could run a synthetic transaction using the two user accounts in question (as opposed to a pair of test accounts) and try to diagnose and resolve the problem. If you decide to conduct a synthetic transaction using actual user accounts keep in mind that you will have to supply the logon names and passwords for each user.

When you call Test-CsPstnPeerToPeerCall the cmdlet will first attempt to log the two test users on to Microsoft Communications Server. Assuming that the logons succeed, the cmdlet will then have user 1 attempt to call user 2 over the PSTN gateway; Test-CsPstnPeerToPeerCall will make this call using the dial plan, voice policy, and other policy and configurations settings assigned to the test user. If the test goes as planned, the cmdlet will verify that user 2 was able to answer the call, then log both test accounts off of the system.

Test-CsPstnPeerToPeerCall does not make an actual phone call; no phone will ring when you call this cmdlet. Instead, it simply verifies that a connection can be made between the two user accounts.

Test-CsPstnPeerToPeerCall returns an instance of the Microsoft.Rtc.SyntheticTransactions.TaskOutput object.

-------------------------- Example 1 --------------------------

	Copy Code
Test-CsPstnPeerToPeerCall -TargetFqdn atl-cs-001.litwareinc.com

The preceding example checks to see if a pair of preconfigured test users can log on to the pool atl-cs-001.litwareinc.com; after the test users are logged on, Test-CsPstnPeerToPeerCall then checks to see if the two users are conduct a peer-to-peer call over the PSTN gateway. This command will work only if a health monitoring registrar has been defined for the pool atl-cs-001.litwareinc.com. If it has, then the command will determine whether the first test user can log on to the system, then check to see if this user can call the second user defined for the pool.

If a registrar has not been defined then the command will fail because it will not know which users to employ when doing the test. If you have not defined a health monitoring registrar for a pool then you must include the -SenderSipAddress and –ReceiverSipAddress parameters as well as the corresponding credentials for the users serving as the test accounts. Test-CsPstnPeerToPeerCall will then conduct its checks using the two specified users.

-------------------------- Example 2 --------------------------

	Copy Code
$cred1 = Get-Credential "litwareinc\jhaas" $cred2 = Get-Credential "litwareinc\kenmyer" Test-CsPstnPeerToPeerCall -TargetFqdn atl-cs-001.litwareinc.com -SenderSipAddress "sip:jhaas@litwareinc.com" -SenderCredential $cred1 -ReceiverSipAddress "sip:kenmyer@litwareinc.com" -ReceiverCredential $cred2

The commands shown in Example 2 test the ability of a pair of users (litwareinc\jhaas and litwareinc\kenmyer) to logon to Microsoft Communications Server and then conduct a peer-to-peer call over the PSTN gateway. To do this, the first command in the example uses the Get-Credential cmdlet to create a PowerShell credential object containing the name and password of the user Jonathan Haas. (Because the logon name - litwareinc\jhaas - has been included as a parameter, the resulting Windows PowerShell Credential Request dialog box only requires the administrator to enter the password for the Jonathan Haas account.) The resulting credential object is then stored in a variable named $cred1. The second command does the same thing, this time returning a credential object for the Ken Myer account.

With the two credential objects in hand, the third command in the example determines whether or not the two users can log on to Microsoft Communications Server and then conduct a peer-to-peer call over the PSTN gateway. To carry out this task, Test-CsPstnPeerToPeerCall is called, along with the following parameters: -TargetFqdn (the fully qualified domain name of the registrar pool); -SenderSipAddress (the SIP address for user 1); -SenderCredential (the PowerShell object containing the credentials for user 1); -ReceiverSipAddress (the SIP address for user 2); and –ReceiverCredential (the PowerShell object containing the credentials for user 2).