Hello All,

Our polycom cx600 phones are signing out and then signing back in many times(5+) throughout the day. We are running Lync 2013 with 2 Frontend servers in our pool. The phones are running firmware version 4.0.7577.4397 and are connected by ethernet and usb tethering. Everything is functioning properly on the phones including Exchange UM integration. We have run OCSLogger traces as well as tried to look through the phone logs, but haven't been able to identify why the phones will sign out and then immediately sign back in. While the phone is signing out and back in the Lync Client on the PC remains connected.

Any thoughts would be greatly appreciated.

Thanks

Check the similar thread at http://social.technet.microsoft.com/Forums/lync/en-US/7412b5a4-fe61-4a9c-ad40-74adf4291035/polycom-phones-keep-disconnecting-then-reconnecting

Try the three solutions in the following link.

http://support.microsoft.com/kb/2464556

If all the methods fail, enable logging on Lync phone client and collect the trace file.

We had previously set the Registry key SendTrustedIssuerList  to false, this did not address the issue. Additionally we are not experiencing a sign in issue. The behavior is sign out, then immediately sign back in. The phones are using PoE. We will collect the phone logs as well as review the LyncServer logs to determine if there are any similarities to the post you have referenced. Is there anything in particular that we should be looking for?

Here is what we see in the frontend server logs when the phone signs out:

 TL_INFO(TF_CONNECTION) [3]73E8.34C4::09/19/2013-15:54:32.816.0002e7cd (SIPStack,SIPAdminLog::WriteConnectionEvent:1207.idx(446))[1371068063] $$begin_record
Severity: information
Text: TLS negotiation started
Local-IP: 192.168.1.173:5061
Peer-IP: 172.16.190.10:51606
Connection-ID: 0x20C200
Transport: TLS
$$end_record

TL_INFO(TF_PROTOCOL) [2]73E8.0B94::09/19/2013-15:54:33.639.0002e7cf (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2420.idx(196))[1252968009] $$begin_record
Trace-Correlation-Id: 1252968009
Instance-Id: F85B
Direction: incoming
Peer: 192.168.1.180:49279
Message-Type: request
BYE sip:user@domain.com;opaque=user:epid:1k73YVPknVSxf9dZ6Y2kTwAA;gruu SIP/2.0
Start-Line: BYE sip:user@domain.com;opaque=user:epid:1k73YVPknVSxf9dZ6Y2kTwAA;gruu SIP/2.0
From: <sip:user@domain.com>;tag=9a4d1b79cc;epid=9404dd4bbf
To: <sip:user@domain.com;opaque=user:epid:1k73YVPknVSxf9dZ6Y2kTwAA;gruu>;epid=18ddb46564;tag=dd4339c07a
Call-ID:  5dcdb134bc1748da9e21736a29d51209
CSeq: 25 BYE
Via:  SIP/2.0/TLS 192.168.1.180:49279
Route:  <sip:CentralFE.domain.local:5061;transport=tls;ms-fe=svr12s-vm-lync2.domain.local;opaque=state:T:F:Eu:Ci.R1ab900;lr;ms-route-sig=faXBv9mtoquEBuBg4LzSZJ3WHQBHEHTeE95z1LxFseeuPjmC-GlYjrAQAA>
Max-Forwards:  70
Content-Length:  0
ms-client-diagnostics:  52142;reason="Disconnect tpcp control channel"
$$end_record

TL_INFO(TF_DIAG) [4]73E8.0B94::09/19/2013-15:54:33.647.0002e7d0 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1207.idx(778))[1252968009] $$begin_record
Severity: information
Text: Routed a request using signed route headers
SIP-Start-Line: BYE sip:172.16.190.10:51525;transport=tls;ms-opaque=788db60f64;ms-received-cid=193B00;grid SIP/2.0
SIP-Call-ID: 5dcdb134bc1748da9e21736a29d51209
SIP-CSeq: 25 BYE
Peer: 172.16.190.10:51525
Data: destination="user@domain.com"
$$end_record

TL_INFO(TF_PROTOCOL) [1]73E8.0B94::09/19/2013-15:54:33.647.0002e7d1 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2420.idx(196))[1252968009] $$begin_record
Trace-Correlation-Id: 1252968009
Instance-Id: F85B
Direction: outgoing
Peer: 172.16.190.10:51525
Message-Type: request
BYE sip:172.16.190.10:51525;transport=tls;ms-opaque=788db60f64;ms-received-cid=193B00;grid SIP/2.0
Start-Line: BYE sip:172.16.190.10:51525;transport=tls;ms-opaque=788db60f64;ms-received-cid=193B00;grid SIP/2.0
From: <sip:user@domain.com>;tag=9a4d1b79cc;epid=9404dd4bbf
To: <sip:user@domain.com;opaque=user:epid:1k73YVPknVSxf9dZ6Y2kTwAA;gruu>;epid=18ddb46564;tag=dd4339c07a
Call-ID: 5dcdb134bc1748da9e21736a29d51209
CSeq: 25 BYE
Via: SIP/2.0/TLS 192.168.1.173:5061;branch=z9hG4bKA31EDD95.B77C6F64B0617CC9;branched=FALSE;ms-internal-info="agt0CexBJ-xxaJeXn3EUMC3HW3-kVfgCbCIUDYHbIAJyBkb3y3SM3iwQAA"
Via: SIP/2.0/TLS 192.168.1.180:49279;ms-received-port=49279;ms-received-cid=1AB900
Max-Forwards: 69
Content-Length: 0
ms-client-diagnostics: 52142;reason="Disconnect tpcp control channel"
$$end_record

TL_ERROR(TF_CONNECTION) [2]73E8.0B94::09/19/2013-15:54:33.648.0002e7d3 (SIPStack,SIPAdminLog::WriteConnectionEvent:1207.idx(452))[1371067982] $$begin_record
Severity: error
Text: Receive operation on the connection failed
Local-IP: 192.168.1.173:5061
Peer-IP: 172.16.190.10:51525
Connection-ID: 0x193B00
Transport: TLS
Result-Code: 0x80072746
User-Uri: user@domain.com
Data: peer-type="Client";user="user@domain.com";winsock-code="10054";winsock-info="The peer forced closure of the connection"
$$end_record

TL_INFO(TF_COMPONENT) [2]73E8.0B94::09/19/2013-15:54:33.648.0002e7d4 (SIPStack,CAUTHRecord::ExpireDisconnectedEndpointContext:412.idx(449))( 00000027BD12B0E0 ) Expired 00000027BB5A4E30
TL_INFO(TF_CONNECTION) [2]73E8.0B94::09/19/2013-15:54:33.648.0002e7d5 (SIPStack,SIPAdminLog::WriteConnectionEvent:1207.idx(446))[1371067982] $$begin_record
Severity: information
Text: Connection closed
Local-IP: 192.168.1.173:5061
Peer-IP: 172.16.190.10:51525
Connection-ID: 0x193B00
Transport: TLS
User-Uri: user@domain.com
$$end_record

just wondering if you can help.  i was able to find some user activity in monitoring server shows

52142; reason="Disconnect tpcp control channel".   also has sign in and sign out issues with cx600 phones.   but the problem is that i dont get that error msg in event viewer as said in

http://support.microsoft.com/kb/2464556/

which is

Event Type: Warning
Event Source: Schannel
Event Category: None
Event ID: 36885
Date: date
Time: time
User:
Computer: COMPUTERNAME

not sure if htis solution is required on our server to fix the sign in /sign out ..when we dont see event ID 36885.  pls help.

hm, and the poe from the switch is ok? Sometimes the switch has a problem. Maybe it could help to run wirehark on a mirror port for one phone to see whats happened on the phone port?

Holger.

thanks for the reply. That was actually my first thought...but no, I powered the phone with the power supply, besides, it doesn't reboot, it just logs out, and back in (sometimes). 

The mirror port option I haven't tried, let me propose that to the network admin and see if that switch can do thatt.

FR

other thing is, have you tried the latest update, because I have read that sometimes the phone will restart if a pstn call will be hold etc.?

Holger.

already running latest version. The phone does upgrades from the FE web services without issues.

FR

We are experiencing the same issue....wonder if anybody found a solution for this??

Please duble check you dhcp setting, I had the same issue with worng settings on one customer site.

Login workung, but reconect is not working because of faulty NTP and VLAN settings.

Hum.

No vlans here, and NTP is properly set. The phone connects....works for a while, then suddenly disconnects. must of the times it reconnects automatically. Sometimes it has to be powercycled and it will reconnect.

Been dealing with this issue for about 2 weeks.

Check this out - https://social.technet.microsoft.com/Forums/lync/en-US/d9cf0adf-cabf-423a-b5ce-445a94abc682/lync-phone-edition-constant-sign-in-and-out-for-some-users?forum=ocsclients

If SCHANNEL is sending a truncated list of trusted root certificate authorities to the Lync phone edition client during the TLS/SSL handshake process, this can explain the symptoms.

To check this look in your Lync FE servers system event log for the following warning:

----
EVENT ID: 36885

When asking for client authentication, this server sends a list of trusted certificate authorities to the client. The client uses this list to choose a client certificate that is trusted by the server. Currently, this server trusts so many certificate authorities that the list has grown too long. This list has thus been truncated. The administrator of this machine should review the certificate authorities trusted for client authentication and remove those that do not really need to be trusted.
----

The easiest way to fix this is to configure SCHANNEL on the Lync FE's not to send this list:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey - 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

3. On the Edit menu, point to New, and then click DWORD Value.
4. Type SendTrustedIssuerList, and then press ENTER to name the registry entry.
5. Right-click SendTrustedIssuerList, and then click Modify.
6. In the Value data box, type 0 if that value is not already displayed, and then click OK.
7. Exit Registry Editor.

You shouldn't need to reboot the server for this to take effect.

Hope this helps!!

For more information and other options on how to resolve this see Microsoft article - 

http://support.microsoft.com/kb/2464556

Thanks,
Andrew