Microsoft has released CU December 2012 for Polycom CX500, CX600, and CX3000 Lync Phone Editions

Microsoft has released CU December 2012 for Polycom CX500, CX600, and CX3000 Lync Phone Editions

Yesterday Microsoft released CU January 2013 specifically for Polycom CX 500, CX600, and CX3000 phones. The latest LPE firmware is for both Lync 2010 and Lync 2013. Multiple updates are included within the CU but the most common issues I saw with the phones and does seem to be addressed are white-horizontal lines or just a blank screen (sometimes white, sometimes black). I have not experienced those issues since the firmware update. The update list (and of course all previous updates are included and assumed and not listed) is listed below.

2703325 Updates are available that enable the "Music on Hold" feature on Lync Phone Edition telephones

2781616 Description of the cumulative updates for Lync Phone Edition that add support for additional languages

2781617 A common area phone that is running Lync Phone Edition does not try to sign in after the Front End server restarts

2802790 Graphic output is not displayed correctly on the screen of a Polycom telephone that is running Lync Phone Edition

2781618 A white screen or a white horizontal line appears on a Polycom telephone that is running Lync Phone Edition

2781620 White lines appear on the screen of a Polycom telephone that is running Lync Phone Edition

Product

Version

KBs

Download

Lync Phone Edition
[Polycom CX500, CX600, and CX3000]

4.0.7577.4372

2737911

MS download


Additional Notes:

Lync Server 2010 build number is 4.0.7577.205
Lync Client build number is 4.0.7577.4356
Lync 2013 Client build number is 15.0.4420.1016
Lync Group Chat build number is 4.0.7577.4102
Lync Group Chat Server build number 4.0.7577.4071
Lync Group Chat Admin build number 4.0.7577.4102
Lync Attendee build number is 4.0.7577.4356
Lync Attendant build number is 4.0.7577.4098
Lync Phone Edition Polycom build number 4.0.7577.4372
Lync Phone Editions (other than Polycom) build number is 4.0.7577.4366 (4363 for CX700/8540)

Hiding your Caller-ID in Lync 2013

An unintended feature for some...

There may be times (and it may be all the time) where you do not want you caller-id (CID) to be presented when making an outbound call. If you have moved to Lync 2013 or plan to move to Lync 2013 this featute may be available for you. The mayambiguity comes from your unknown - what SBC are you using and how is it configured. As of today, the IntelePeer SBC that is being used can make this happen...

To start, the Lync 2013 Server product introduced many new features including the ability to include P-Asserted-Identity history in the SIP signaling. This additional features is intended to allow the originator's ID to be masked with a new identity allowing forwarded calls to be 'authenticated' by the originating number but display to the receiving party as the forwarded user. This concept may be defined as follows (and may be found in RFC3325):

"Lync User" <sip:lyncuser@domain.com>
"Outside Caller" <sip:+14805551212@domain.com>
"My Cell" <sip:+16025551212@domain.com>

Outside caller calls Lync User who has call forwarding enabled on their phone. Ideally when the call is forwarded to the Lync user's cellular device it displays the caller ID of the Outside Caller, not the Lync User. This worked just fine in the past with SIP Trunk Providers and SBCs that supported Lync Server. However, if you have ever worked with a non-certified SIP trunk provider the call was typically denied as it appeared to be a call from the Outside Caller using the company’s SIP trunk (and that is not allowed). Using the P-Assert-Identity history these carriers would be able to recognize that the call was actually originating from the Lync User but the CID was simply being masked with the Outside Caller’s CID.

So how does this help us in hiding our CID you ask? Well, again, this depends on the SBC and how it interprets RFC3325. Currently IntelePeer and their SBCs interpret the RFC to mean mask ALL CID information. So, if this feature is enabled on the trunk, all CID is blocked and the recipient receives an incoming call that is shown as PRIVATE. This feature may or may not remain in effect but as of today it works. For your own SBCs, it may be an option to configure this as well.

Configuring Lync 2013 to block PRIVATE numbers is a simple task if you want it to be global. If you do not want it to be global, but perhaps for some users, additional voice policies, PSTN usages, and routes would need to be defined to create a one-off setup. To enable the option globally from the Lync Control Panel navigate to Voice Routing | Trunk Configuration.


What you display here will be different based off your configuration but the ideas and concepts are the same. If you only have a single trunk, the configuration may be in the Global Policy. If you have multiple trunks as shown then you would want to modify the policy(s) that apply to your trunk.

To modify the policies select it from the list and double-click (or select Edit | Show details…). Once in the policy you will see many new options; the one we are concerned with is Enable forward P-Assert-Identity data. Select the box to enable to feature and click OK to close the dialog.


You will need to commit the changes (Commit | Commit All) and then have a little patience. Once committed, the changes must be replicated to the Mediation Servers which may take a minute or two. If you want to see this change within the Event Viewer, search for Event ID 25091 which will look something like this:

Information       10/3/2012 5:32:27 AM    LS Mediation Server       25091   (1030)

Trunk configuration has changed
Trunk: 1-la01.intelepeer.com;trunk=1-la01.intelepeer.com
ByPass Enabled: False
Forward PAI Enabled: True
Forward Call History Enabled: True
Refer Supported: False
3pcc Refer Supported: False
SRTP Mode: NotSupported
Online Voice Enabled: False
RTP Latching Enabled: False

Once that Event Log has been logged, you may make an outbound call and check the results. If all the stars have aligned in your configuration, the recipient of the call will see the CID of the incoming call as PRIVATE and will probably not answer.

For further validation that the feature is enabled you may capture and inspect Lync Server Logs (IncomingAndOutgoingCall scenario). After you have captured the logs, open then in a text reader (such as notepad) and search for Privacy:id (not ms-privacy:id as that is always there). If you want to use Snooper to view the logs unfortunately this particular option is filtered and not shown so be aware – use a text viewer. Assuming the Privacy:id option is listed in the call setup things are configured as expected. If not, either the caller did not use the route you modified or the configuration has not replicated (Event ID 25091).