A quick note that there is a known bug in the Test-CsPstnPeerToPeerCall in Lync Server 2010 and 2013. When testing with certain gateways (such as Sonus SBC 1000 and 2000), you may see the following response
PS C:\> Test-CsPstnPeerToPeerCall –TargetFqdn pool1.domain.com
RunspaceId : c80a2c5f-0659-4081-b88c-54ccfe18f395
TargetFqdn : pool1.domain.com
Result : Failure
Latency : 00:00:03.3379616
Error : Expected DTMF Tones to be received within 10 seconds.
This issue occurs because the volume value of the dual tone multi-frequency (DTMF) digits in the test cmdlet is too low. This doesn’t affect all gateways, some, such as the Cisco ISR, will pass. The reason it works with some gateways and not others is that the digit detection level are different. With UX the digit detection level is -34db. Setting it lower can cause other issues such as false detections
We can see the volume level in a Wireshark trace, with the RTP EVENTS
The cmdlet sends a bunch of “#” DTMF tones that it expects the gateway to return them, proving the gateway is working. However the volume level is –53.
-53 is not valid per RFC2833 (http://www.ietf.org/rfc/rfc2833.txt), this is directly from the RFC:
volume: For DTMF digits and other events representable as tones, this field describes the power level of the tone, expressed in dBm0 after dropping the sign. Power levels range from 0 to -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0 (must accept); lower than -55 dBm0 must be rejected (TR-TSY-000181, ITU-T Q.24A).
Interestingly acceptable volume levels were changed in RFC4733 (http://tools.ietf.org/html/rfc4733), which obsoletes RFC 2833,
For DTMF digits and other events representable as tones, this field describes the power level of the tone, expressed in dBm0 after dropping the sign. Power levels range from 0 to -63 dBm0
(Note: A preferred level range for digital tone generators is -8 dBm0 to -3 dBm0.)
So even though the level is legal as per RFC4733, it is miles off the preferred volume range of –8 to –3 dB.
Actual in Call DTMF tones in Lync are sent at a much higher volume, so present no issue, it’s only the test cmdlet that is impacted, so it may flag false errors in SCOM synthetic transactions.
The issue was supposed to be fixed in Lync Server 2010 CU4, but evidently was not
I believe it’s on the to fix list, but no eta. I’ve endeavour to update this post when the issue is fixed