Subscribe via RSS Feed Connect on LinkedIn

Test-CsPstnPeerToPeerCall Known Bug: “Expected DTMF Tones to be received within 10 seconds”

15/04/2013 10 Comments

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

image

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

<snip>

(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

http://support.microsoft.com/kb/2621842?wa=wsignin1.0

 

I believe it’s on the to fix list, but no eta. I’ve endeavour to update this post when the issue is fixed

Tom

Useful? Please take a second to shareTweet about this on TwitterShare on LinkedInShare on Google+Email this to someone
Tom Arbuthnot

Tom Arbuthnot

Managing Consultant at Modality Systems
Tom Arbuthnot is a Microsoft Lync Certified Master and MVP. He is a blogger, regular on The UC Architects Podcast, contributing writer to Lync Server 2013 Unleashed and speaker at events such as Lync Conference and The Microsoft UC User Group London. He is currently Managing Consultant at Modality Systems.
Tom Arbuthnot
Filed in: Lync • Tags: , ,

Comments (10)

Trackback URL | Comments RSS Feed

  1. soder says:

    LOL, the issue has been recognized in 2011 november (actually it was way sooner, as the patch development needed another 2-3 months), but the problem is still not resolved. Thats so Microsoftish..

  2. Has this happened for anyone with any of the AudioCodes gateways?

  3. I haven’t tested on an AC gateway, but hopefully someone has/can and will comment.

    Tom

  4. Dan Bacon says:

    I’m seeing this issue using Avaya Session Manager.

  5. Linus says:

    Hello Tom,

    we are also facing the same issue with our NET UX 1000 Gateways.
    We upgraded to from Lync 2010Lync 2013 but its there in 2013 as well .
    Is there any other update regarding this.

  6. mihai says:

    Just repro the problem with Lync 2013 RTM BUT after installing Lync 2013 CU3 the issue is gone. So the solution is to apply the latest CU on the watcher node

    Hope this helps
    FYI

    here is the event after the issue is fixed (note the GREEN status):

    ‘InviteOcsPSTNOc’ activity started.
    Establishing Audio Video Call to ‘sip:+1797;ms-skip-rnl@our_domain.org;user=phone’.
    Audio Video Flow is now Established.
    Incoming Call Received by Receiver’s Endpoint.
    ‘InviteOcsPSTNOc’ activity completed in ’4.4293016′ seconds.
    ‘SendReceiveDTMF’ activity started.
    Sender sent DTMF Tone: ‘Pound’ (11).
    Receiver received DTMF Tone: ‘Pound’ (11).
    ‘SendReceiveDTMF’ activity completed in ’0.8055928′ seconds.
    ‘UnRegister’ activity started.
    ‘UnRegister’ activity completed in ’0.4785203′ seconds.
    ‘UnRegister’ activity started.
    ‘UnRegister’ activity completed in ’0.1047803′ seconds.

    Workflow Instance ID ’9e294af4-70bc-45cb-8ed8-ba7e3dae0a12′ completed.
    Workflow run-time (sec): 6.1671498.

    public_edge_FQDN
    PSTN
    ICC PSTN Test
    GREEN
    5.4448929

Leave a Reply