Share via

Lync 2013 client crashing for RCC enabled accounts

  • Article

When accounts are RCC enabled and CSTA gateway does not send expected events Lync 2013 client generates a time-out 30 seconds after request has been made. In some scenarios this can lead to an access violation so client will crash. Currently Microsoft is working on this topic however this is just a side effect of CSTA gateway not sending expected responses/events. Please see below SIP stack from working scenario:

Lync client request:

- <SetForwarding xmlns=" https://www.ecma-international.org/standards/ecma-323/csta/ed3 ">
<device> tel:1799;phone-context=enterprise</device >
<forwardingType>forwardImmediate</forwardingType>
<activateForward>false</activateForward>
</SetForwarding>

CSTA gateway response:

- <SetForwardingResponse xmlns=" https://www.ecma-international.org/standards/ecma-323/csta/ed3 ">
</SetForwardingResponse>

CSTA gateway response:

- <ForwardingEvent xmlns=" https://www.ecma-international.org/standards/ecma-323/csta/ed3 ">
<monitorCrossRefID>9a19c24c</monitorCrossRefID>
+ <device AA=" https://www.w3.org/2001/XMLSchema-instance "
type="SubjectDeviceID">
<forwardStatus>true</forwardStatus>
<forwardTo typeOfNumber="dialingNumber"
bitRate="constant"> tel:;phone-context=enterprise</forwardTo >
</ForwardingEvent>

 

In this case CSTA gateway sent event for forwarding highlighted at yellow above. In non-working scenario I have been working this event was never sent so reason why Lync client crashes. This means that this problem can be avoided if CSTA gateway is compliant and send expected events.

Even after potential correction is released Lync client will display a pop-up asking users if they would like to keep trying applying forwarding as event was not received. So basically potential hot fix will only avoid access violation and CSTA gateway behavior should be fixed.

image

For this specific scenario adding registry key to disable RCC Forwarding was an effective workaround:

 

(…)

9. Disable RCC Forwarding (DisableRCCForwarding)

Remote call control is a feature of a PBX that allows the VoIP phones on a network to come online and share the same configuration that is configured for them on the PBX that hosts the VoIP network. One of the features that is shared by most PBXs is call forwarding. Call forwarding allows VoIP phones to forward calls to destinations that are chosen by the VoIP phones user. When a Communicator client is configured as a remote call control client, it cannot inherit the call forwarding features that are designed into the Communications Server Enterprise Voice client. Instead it will inherit the call forwarding features that are provided by the PBX that is hosting it on the VoIP network. Third-party remote call control call forwarding is not a fully supported feature. However, it is recognized as a compatibility issue that appears intermittently when the Communicator client is brought into an existing VoIP network as a remote call control client with a legacy PBX installation. As a means to troubleshoot issues with remote call control call forwarding, the Disable RCC Forwarding group policy was implemented. This allows administrators to toggle the remote call control call forwarding feature on or off while troubleshooting remote call control call forwarding issues.

(…)

 This registry key should be created in the following path:

 

HKLM\Software\Policies\Microsoft\Office\15.0\Lync

1.     On the Edit menu, point to New, and then click DWORD Value.
2.     Type DisableRCCForwarding, and then press ENTER.
3.     Right-click DisableRCCForwarding, and then click Modify.
4.     In the Value data box, type 1, and then click OK.
5.     Make sure this key does not exist on the HKCU tree on the same machine.
6.     Exit Registry Editor. 

As soon potential fix is released this post will be updated.

Comments

  • Anonymous
    September 06, 2013
    Hi, Is there already some solution available ?

  • Anonymous
    June 04, 2014
    Hello,
    Do you know if there is anupdate about this issue? We are encountering problems with Lync 2013 client and RCC (while Lync 2010 client works perfectly) and are wondering if this could be the same issue.
    Thanks for your update on this.
    Bruno