Twitter

Thursday, January 22, 2015

Lync Mobile Client does not normalize dialed number

There is an issue cause confusion with the Lync Mobile Client behavior.
 
Let me give you a scenario:
Assume a user is located in Munich:
+49    Country Code Germany
89     Area Code Munich
314253 (main number)
554    (extension)
Full number : +4989314253544
 
Munich Lync phone number: tel:.+4989314253544;ext=1544
(the 1 stands for Munich)

New York Lync phone number: tel:.+16312455554;ext=2544
(the 2 stands for New York)

 
This number belongs to an internal Lync user and you have the normalization rules for this Munich location profile set as:
normalizing to 3-digit ->       +4989314253$1
normalizing to 4-digit ->       cut 1 - +4989314253$1
normalizing to 4-digit ->       cut 2 - +16312455$1
normalizing to 9-digit ->       +4989$1
normalizing to 0+11-digit ->    cut 0 - +49$1
normalizing to 0049+11-digit -> cut 00 - +$1
normalizing to 001+10-digit ->  cut 00 - +$1
 
This number belongs to an internal Lync user and you have the normalization rules for this New York location profile set as:
normalizing to 3-digit ->       +16312455$1
normalizing to 4-digit ->       cut 1 - +4989314253$1
normalizing to 4-digit ->       cut 2 - +16312455$1
normalizing to 7-digit ->       +1631$1
normalizing to 0049+11-digit -> cut 00 - +$1
normalizing to 001+10-digit ->  cut 00 - +$1
 
It normalize the expected E.164 format matching the internal users Lync Phone Number
 
If you dial as use have a location profile of Munich location to, you now can dial the following:
 
544             Mobile Client show: 544
1544            Mobile Client show: 1544
314253544       Mobile Client show: 314253544       
089314253544    Mobile Client show: 089314253544      
+4989314253544  Mobile Client show: +4989314253544 
004989314253544 Mobile Client show: 004989314253544       
All Calls are successful !
 
If you dial as use have a location profile of New York location to, you now can dial the following:
 
544             Mobile Client show: 544 (not match and normalize to New York)
1544            Mobile Client show: 1544 (CALL SUCCESSFUL and normalize to Munich)
314253544       Mobile Client show: 314253544 (no match)       
089314253544    Mobile Client show: 089314253544 (no match)     
+4989314253544  Mobile Client show: +4989314253544  (CALL SUCCESSFUL)
004989314253544 Mobile Client show: 004989314253544 (CALL SUCCESSFUL)
 
 
As you see the Lync mobile client do not show the normalization.
It keeps the number you dialed, similar as the behavior dialing from your mobile itself.

Why the call can reach the user?
Lync can process the given normalization rules on the Server, (in-band provisioning) and also knows the location profile the calling user has assigned, which than include the DialPlan with the Normalization Rules.

Therefore its a normal behavior.

Solution:
If the call do not work as described in the simple example aforementioned, your location profile and normalization rules are incorrect. You need modifying your dial plans.


Wednesday, January 21, 2015

Cannot send IM from Outlook Web Apps

There are three possible reasons why you can't send IM from Outlook Web Apps (OWA).
I assume first, the integration was done according to the recommendations given. Meaning you have also tested that internal IM from OWA was possible to send and receive.

If you encounter the following behavior:
- Presence can be queried, but I’M cannot be initiated.
- If you receive an external IM, you are able to answer the external contact.
- You cannot receive or send external IM from OWA
 
While you are using the OCSLogger on the Lync Edge Server, you might see the following SIP 403 Forbidden message:
 
Text: SUBSCRIBE request for get rich presence was rejected by the Access Edge Server
Result-Code: 0xc3e93d80 SIPPROXY_E_EPROUTING_MSG_INT_GET_RICH_PRESENCE_FILTERED

You also see the internal Exchange Server with ipconfig -displaydns as:
_sipfederationtls._tcp.sip-domain.com


Solution:
1. Your external policy do not allow access to federated partner or public IM systems. Therefore you need to change those policies, or assign the correct policy to the affected users

2. You have the correct policy, but you sill can't reach out to external contact, the SIP address might be incorrect, or the federated partner is not allowed to communicated externally

3. Most likely, if the policy settings are correct the third possibility occurs. For external IM communication you must have a CONTACT OBJECT in Exchange. IM can only be initiated via a contact object and this is different from your Lync Client, where you are able to type a address in the address bar.
In OWA you can add a contact including the CHAT address, but here you have to add the chat address in the following format:
SIP:user@sip-domain.com
OWA can only initiate a IM if the SIP Prefix is present, else the error message shown above will be logged. This is an issue by design of Exchange utilizing the UCMA API.
Additionally, you also have to apply the Lync Cumulative Updates to the UCMA installed on each Exchange CAS Server. This is mostly forgotten by the Exchange admins.
 
 

This article says, if you wish to communicate with external buddies, you have to add a Outlook Contact and MUST include SIP: prefix.
https://support.microsoft.com/kb/2977259

Thursday, January 15, 2015

Skype for Business and Lync Monitoring for Enterprise Voice

Monitoring, a component in Lync which is most important.
Not only collecting information about the servers and their services. Since here are users directly involved with their end devices, like phones, headset or computers. In between of those components sits the network and routing devices. Not enough here, mostly Lync or Skype for Business work in an environment where other voice solutions, e.g. PBX's or SIP Systems are running in parallel. During a migration for example, if you move users towards Enterprise Voice, the PBX and e.g. SIP Trunk Providers are in the loop for quite some time.

This makes monitoring of the entire Voice solution essential.

Lets see hat Lync and Skype for Business offers:
Microsoft has introduced a two databases, the CDR and QoE database. Those are databases where Call Details are recorded and the entire environment quality data, like Server and service health, as well as the quality relevant information about call, either a P2P or Enterprise Voice call, and data about conferences.
With predefined SQL Reports you can query those data. And they are essential not only for troubleshooting, they are essential monitoring trends as well.
You have a dashboard providing an generic overview and the individual reports allowing you having a deep inside view of each call and component.

But here the main question comes into place: If I'm in the midst of an migration, or even having two UC solution in place, where can I see and monitor the entire environment of my company.

The answer is you cannot do this with the Microsoft Monitoring components. You need either multiple different systems, where you will encounter difficulties bringing those information together.

Saying a Skype for Business user is calling a user still not migrated from an AVAYA PBX. Both system are connected via SIP Trunk or via the SBC.
Now you cannot monitor this call.
The only solution is you take the Microsoft site and the Avaya site combine possible reports and try your best.

Now what I personally recommend to customers addressing this problem:

It is IR, PROGNOSIS.

This is the only solution able to utilize every source in your environment, the Microsoft Reporting databases, the SDN APIs, and the most PBX and UC vendors. Consolidating all information into a single system and provide you the entire, overall view.

Lets have a look into it:

 
With Prognosis I can address all components in Lync and Skype for Business, including the SDN API too. Therefore I also collect the CDR and QoE database information.
 
 
But that's not enough, in an UC environment, we learned that the user experience is quite important. This the user has a sensitive organ, the ear. Therefore he has subjective sense to a call he made. It is helpful, if we can identify those calls too. We know that the Skype for Consumes offer those function. With Prognosis, we can integrate this feature also into Lync 2010 and Lync 2013.
 
 
 
From here we can validate the call in more simpler way than we could do with the integrated reporting in Lync/ Skype for Business. 
 
 
As mentioned earlier, having a view over all involved components, we call this feature in Prognosis Voice Quality 360. The call can be monitored from end-to-end over all solution, e.g. from Lync to Avaya, or from CCM to Skype for Business.

 
As the path is important we also need trace those call with e.g. SBC. here is an example tracing a call from Cisco Call Manager to Lync, End-to-End. Have the SBC from AMCE in place. This can help us to clearly identify where we would have the problem located, e.g. a lower MOS Score. From this point onwards we simple click down to the component identified.

 
Conference are another issue. How often I was asked to identify a "bad" call in a conference, even with more than 100 participants. Wow difficult task and a lot of work.
With Prognosis, it made my life easy, as I could see the call was bad on the sending path.

 
Summary:
if you are the Administrator in company, you should be able tracing your environment entirely and have the right tool to support your work, so you can approach the correct troubleshooting way directly.
Additionally, we can deliver those information also to our support partners which than save a lot of time doing their parts.

Monday, January 12, 2015

Troubleshooting Guide Skype for Business and Lync

The free eBook is about troubleshooting Skype for Business and Lync.

A complex solution in unified communication marking people's life more simpler, connecting to óther at any point of time, staying in contact with fellow friends and family members. Developing a set of skills, supporting and analyzing issues in this environment is an advanced task. I describe the troubleshooting work flow from general understanding of Skype for Business and Lync Server and Services.

In the Troublehsooting Guide the following areas are covered:
- General Approach to troubleshooting
- Logging, Tracing and CLS
- TCP and SIP Protocol
- SIP Session Establishment
- Lync/ Skype for Business Call Setup (entire process)
- Troubleshooting IM
- Troubleshooting Call with A/V
- Diagnostic Headers
- Monitoring
- Troubleshooting Voice
- Troubleshooting Conferencing
- Troubleshooting Web Services
- Troubleshooting Edge (external/ remote)
- Health Monitoing
- Troubleshooting Exchange Intergation
(Autodiscover, Exchange Web Service EWS, IM Integration in OWA, Unified Contact Store UCS, Unified Messaging)
- Troubleshooting Mobility Services
- Troubleshooting Mobile Clients
- Troubleshooting Office Web App Server (OWA)


Troubleshooting Enterprise Voice will be released during a future update of this document (Version 2.0)


Troubleshooting Guide is ready for download:

Please have a look and enjoy.

Wednesday, December 17, 2014

Skype Translator online Preview

A most amazing tool and option bringing our world closer together.
Making contact with other people around the world, with different languages and culture.

Humanization is the ultimate goal for peace and happiness in our modern World. I took strong faith in this to be happened.

Please try this out and open your mind towards an peaceful, harmonizing world. Get out and reach others, not only for business purposes. The privat side of live is important too.

Watch this amazing Preview Video from Microsoft. Translating Voice on the fly with Skype Translator is the correct way in doing so.

https://www.youtube.com/watch?v=G87pHe6mP0I

Thanks you

Tuesday, December 2, 2014

Summary Lync 2013 Cumulative Updates and Database Updates

Do not forget and update the Lync backend databases. ;)


We need to patch all the databases, and the LIS / XDS from CMS.

First we remember, the Standard Edition has its own local SQL Server containing all databases necessary for its related Frontend Services, therefore a single command similar as for the SQL Backends is required.

If you have an Enterprise setup, you need to identify which features are installed, e.g. only native or incl. Archiving/ Monitoring, or even Persistent Chat.
This separated databases require their own commands.

For the entire process based on Enterprise Deployment, please enumerate your Topology and identify the configured components.


Lync Standard Edition:
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn SE.FQDN -Verbose

Lync Server 2013 Enterprise Edition
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn FEBE.FQDN
-DatabasePaths "D:\LOGS","D:\DATA" 
-SqlInstanceName DBInstance -Verbose
 
Lync Server 2013 Persistent Chat Databases
Install-CsDatabase -DatabaseType PersistentChat -SqlServerFqdn PChatBE.fqdn
-SqlInstanceName DBInstance -Verbose
 
Lync Server 2013 Monitoring/Archiving/Persistent Chat Databases
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn SQLServer.FQDN
-SqlInstanceName DBInstance -Verbose
 

The CMS needs to be updates to, the LIS and XDS Database, but this must be done AFTER the other Database are updated.
This is also valid if there are multiple pools and multiple SQL backends.

Apply the Central Management Database update
Install-CsDatabase -CentralManagementDatabase -SqlServerFqdn CMS.FQDN
-SqlInstanceName DBInstance -Verbose
 
 

Friday, November 21, 2014

Lync and Skype for Business protocols

today is time that I will explain the Lync protocol short cuts, the name what actually this couple of letters mean.
I was very often asked what e.g. is the meaning of STUN or RT.

Also, which RFC is behind this protocol. If further information are available, I have posted this info too.

Therefore, here it come:

STUN - (Simple Traversal of User Datagram Protocol (UDP) - Through Network Address Translators (NATs))
This is protocol used on the Edge server, where UDP data is passed through the NAT. It contains information about the external (public) IP address where the client is hidden behind and the internal (private) IP address the client has assigned.
https://www.ietf.org/rfc/rfc3489.txt
 
STUN (Session Traversal Utilities for NAT)
http://tools.ietf.org/html/rfc5389

URI Scheme for the Session Traversal Utilities for NAT protocol
https://tools.ietf.org/html/rfc7064

NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
https://tools.ietf.org/html/rfc5780



TURN - Traversal Using Relay NAT
TURN is a design part of the ICE process, but can be used also without ICE. It is responsible for NATed client supporting "direct" communication. in Lync/ Skype for business, this protocol is server related.
https://tools.ietf.org/html/rfc5766
https://tools.ietf.org/html/rfc6062


ICE - Interactive Connectivity Protocol
IT determines all possible UDP and TCP port involved in a SIP communication. Necessary for the client negotiation process which is the best possible path for communication. This protocol is client related. But need ICE award servers.
https://tools.ietf.org/html/rfc5245
http://tools.ietf.org/html/rfc5768


MRAS - Media Relay Authentication Service
This is an authentication protocol used with Lync and Skype for business. MRAS initiates Token for authentication. It can be seen more as a component, rather then a protocol. It involves in the SIP authentication.

I haven't found official information about the MRAS Server/ Service, but it is most best describe the Audio/ Video Authentication description.
http://msdn.microsoft.com/en-us/library/cc431496(v=office.12).aspx


PSOM - Shared Object Messaging Protocol
It a Microsoft proprietary protocol used for Web Conferencing. PSOM is the media protocol for data collaboration. PSOM will use TLS as the underlying transport. PSOM can be used by conferencing clients to establish media channels with the Web Conferencing Server to negotiate or transfer media.
http://msdn.microsoft.com/en-us/library/ff595355(v=office.12).aspx


C3P - Centralized Conference Control Protocol (CCCP)
The Centralized Conference Control Protocol (C3P) activates, modifies, deactivates, and controls conferences. It utilize SIP standards for conferencing.
http://msdn.microsoft.com/en-us/library/cc431498(v=office.12).aspx
http://www.rfc-editor.org/rfc/rfc4353.txt



RTP/ RTCP - Real-Time Transport Protocol
RTP/RTCP is the standard protocol for the transport of real-time data, including audio and video.
https://www.ietf.org/rfc/rfc3550.txt
https://tools.ietf.org/html/rfc3605
https://tools.ietf.org/html/rfc3611

SRTP - Secure Real-Time Transport Protocol
http://www.ietf.org/rfc/rfc3711.txt
https://tools.ietf.org/html/rfc5763


SIP - Session Initiation Protocol
Session Initiation Protocol (SIP) is the industry standard protocol described in IETF RFC 3261 that defines a standard way for session setup, termination, and media negotiation between two parties. It is widely used for Voice over IP (VoIP) call signaling.
https://www.ietf.org/rfc/rfc3261.txt


SDP - Session Description Protocol
Session Description Protocol (SDP) is the industry standard protocol described in IETF RFC 4566 that defines a standard way to convey media details, transport addresses, and other session description metadata to the participants when initiating multimedia teleconferences, Voice over IP calls, streaming video, or other session
https://www.rfc-editor.org/rfc/rfc4566.txt



TLS
https://www.ietf.org/rfc/rfc2246.txt (1.0)
http://tools.ietf.org/html/rfc5246 (1.2)


MTLS
MTLS is nearly the same as TLS, but can contain multiple session with in a TLS connection setup. That's why Lync and Skype for Business use it between the Server-to-Server communication.
https://tools.ietf.org/html/draft-badra-hajjeh-mtls-05



General information:

Signaling and Control Protocol
SIP, as specified in RFC 3261, is used for session setup and termination in Office Communications Server. SIP messages use TCP or TLS as the underlying transport layer for client-to-server communications and TLS with mutual authentication (MTLS) for server-to-server communications. Conferences and call control are established within the context of existing SIP sessions using C3P protocol. C3P commands are sent using SIP INFO messages. A separate SUBSCRIBE/NOTIFY dialog is used to subscribe to conference packages, state change notifications, and the conference participant list.

Media Protocol
The Web Conferencing Server uses PSOM as the media protocol for data collaboration. PSOM uses TLS as the underlying transport. As the client for the Web Conferencing Server, Live Meeting functionality also relies on PSOM.
RTP and RTCP are used to provide audio/video functionality. Secure Real-time Transport Protocol (SRTP) and Secure Real-time Transport Control Protocol (SRTCP) are used to provide secure, encrypted audio/video functionality.) RTP/RTCP uses TCP or User Datagram Protocol (UDP) as the underlying transport.

Codec(s):
RTA/RTAudio - Realt-Time Audio 
RTV/RTVideo - Real-Time Video

G711/ G729/ G722

SILK
This is the SKYPE codec used with Skype and Skype for Business. The new version is only used between clients and client to server. The Mediation Server in Skype for Business will not make use of SILK.

OPUS
A new codec with will be used also in the open communication program with Polycom new phone. But will not be supported with in Skype for Business.

SIREN

PCM




Tuesday, November 18, 2014

Lync become Sykpe for Business (#skype4b) - vNext

Finally it is time to announce the changes Microsoft made.
Still a lot feature are not yet public, but the name and the look and feel of the new client.

A lot of rumors ran around the last month and now we have a huge discussion if this name could be the right one.

YES, I say it is the right name, it is the right way Microsoft is going.

Nothing is more efficient for a company, if user are familiar with the tools they need to master within the company. And here it come. over 20m people use Skype today and yes, they are very familiar with this tool.
This means to us, the unified communication is now taking place in the real world.

Families and their members come closer together. We increase the social component in our work environments.

Never forget how amazing this is, chatting with your parents over the same tool. Even if this are two different platforms. Consumer (Skype) and Business (Skype for Business).
But now we have them together finally. Never sitting in a hotel on a business trip and can't see your wife and loved children.

That's what we were waiting for.
Thank you Microsoft.

And here a look into the new Client:


Please follow us in twitter:

our hash tag is: #skype4b

https://twitter.com/msftlync
https://twitter.com/thomaspoett
http://blogs.skype.com/2014/11/11/introducing-skype-for-business/





Monday, November 3, 2014

Monday, September 29, 2014

SIPPROXY_E_CONNECTION_UNKNOWN_SERVER (TLS negotiation error)

Recently I encountered a very strange issue:

After installation another Lync Frontend Server, in this case a SBS. The Federation was broken.
Incoming via the Edge Server everything looked fine. Meaning, incoming Federation request, e.g. presence or IM, as well as remote access from users hosted on this SBS were working correctly.
But all outing communication to federated partners didn't work at all.
After using the OCSLogger and analyzing the logs in SNOOPER, I saw an error message: The peer is not a configured server on this network interface and SIPPROXY_E_CONNECTION_UNKNOWN_SERVER
coming along with another message: winsock-info="The peer forced closure of the connection"
I used the RUST tool internally verifying the SBS certificate, it was correct. Even requesting the certificate again didn't help at all. Even I imported the Topology on the Edge server again!
What this clearly explains was, if the SBS was presenting it's certificate, it didn't work. If the Edge Server was presenting it's internal certificate to the SBS, the SBS was accepting it.
This is because in the TLS NEGOTIATION message, I identified the peer:
Local-IP: 172.28.248.131:5061 (EDGE INTERNAL)
Peer-IP: 172.28.10.10:59238 (SBS)
Since the SBS had a high port, it must have been the sender.



Resolution:
I had to restart the SBS Frontend Service and the Edge Access Service. This solved the issue.

BUG:
I believe this is a bug, normally if the certificate is assigned, even during the service using it running, the service should query the certificate directly from the certificate store. but in whatever circumstance it is not doing so correctly. This is why you have to restart services, at least on the SBS, the server newly established in your environment.

Note:
A similar issue occurs, e.g. if you setup the Exchange OWA integration for presence and IM. IF the Exchange Server is not trusted server in the Topology, you will find a similar issue on the Frontend server.

---------------------------------------------------------------------------------------

For your better understanding, here are some traces of this case:
Starting with the EDGE Server first


TL_INFO(TF_CONNECTION) [0]0D14.06B4::09/29/2014-08:26:30.134.0007e9ae (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(454))[2855934840] $$begin_recordSeverity: information
Text: TLS negotiation started
Local-IP: 172.28.248.131:5061
Peer-IP: 172.28.10.10:59238
Connection-ID: 0x38F1600
Transport: TLS
$$end_record
 
TL_INFO(TF_PROTOCOL) [1]0D14.06B4::09/29/2014-08:26:30.197.0007ea1e (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[2485748977] $$begin_recordTrace-Correlation-Id: 2485748977
Instance-Id: 591B48
Direction: incoming;source="internal edge";destination="external edge"
Peer: 172.28.10.10:59238
Message-Type: request
Start-Line:
NEGOTIATE sip:127.0.0.1:5061 SIP/2.0
From: sip:sbs01.domain.local;tag=8D4E6E25C6A1BCE8C0AA4EBC780ED3E6
To: sip:LYNCEDGE01.domain.local
Call-ID: A0405E94346142207A1C
CSeq: 1 NEGOTIATE
Via: SIP/2.0/TLS 172.28.10.10:59238;branch=z9hG4bK1B170C12.50835B4246C5B624;branched=FALSE
Max-Forwards: 0
Content-Length: 0
Require: ms-compression
ms-negotiate-data: LZ77-64K
Supported: NewNegotiate,OCSNative,ECC,IPv6,TlsRecordSplit
Server: RTC/5.0
 
$$end_record
 
TL_ERROR(TF_CONNECTION) [1]0D14.06B4::09/29/2014-08:26:30.197.0007ea45 (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(389))[2855934840] $$begin_recordSeverity: error
Text: The peer is not a configured server on this network interface
Peer-IP: 172.28.10.10:59238
Transport: TLS
Result-Code: 0xc3e93d6a SIPPROXY_E_CONNECTION_UNKNOWN_SERVER
Data: fqdn="sbs01.domain.local"
$$end_record
 
 
Having a look into the SBS log here:
 
TL_INFO(TF_CONNECTION) [0]1DAC.056C::09/29/2014-08:47:01.986.000007a2 (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(454))[1674556973] $$begin_recordSeverity: information
Text: TLS negotiation started
Local-IP: 172.28.10.10:60309
Peer-IP: 172.28.248.131:5061
Connection-ID: 0x13B00
Transport: TLS
$$end_record
 
 
TL_INFO(TF_DIAG) [1]1DAC.056C::09/29/2014-08:47:02.064.000007a9 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[612839171] $$begin_recordSeverity: information
Text: Routed a locally generated request
SIP-Start-Line: NEGOTIATE sip:127.0.0.1:5061 SIP/2.0
SIP-Call-ID: 57883DA78E69E21BFB83
SIP-CSeq: 1 NEGOTIATE
Peer: LYNCEDGE01.domain.local:5061
$$end_record
 
 
TL_INFO(TF_PROTOCOL) [1]1DAC.056C::09/29/2014-08:47:02.064.000007aa (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[612839171] $$begin_recordTrace-Correlation-Id: 612839171
Instance-Id: 2835
Direction: outgoing;source="local"
Peer: LYNCEDGE01.domain.local:5061
Message-Type: request
Start-Line: NEGOTIATE sip:127.0.0.1:5061 SIP/2.0
From: sip:sbs01.domain.local;tag=A6CBF413214DBEF0CAE0CF071DBF904D
To: sip:LYNCEDGE01.domain.local
Call-ID: 57883DA78E69E21BFB83
CSeq: 1 NEGOTIATE
Via: SIP/2.0/TLS 172.28.10.10:60309;branch=z9hG4bK650D3356.5FCB69DE77B72B06;branched=FALSE
Max-Forwards: 0
Content-Length: 0
Require: ms-compression
ms-negotiate-data: LZ77-64K
Supported: NewNegotiate,OCSNative,ECC,IPv6,TlsRecordSplit
Server: RTC/5.0
$$end_record
 
 
TL_ERROR(TF_CONNECTION) [0]1DAC.056C::09/29/2014-08:47:02.095.000007ae (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(460))[1674556973] $$begin_recordSeverity: error
Text: Receive operation on the connection failed
Local-IP: 172.28.10.10:60309
Peer-IP: 172.28.248.131:5061
Peer: LYNCEDGE01.domain.local:5061
Connection-ID: 0x13B00
Transport: M-TLS
Result-Code: 0x80072746
Data: fqdn="LYNCEDGE01.domain.local:5061";ip-address="172.28.248.131";peer-type="InternalServer";winsock-code="10054";winsock-info="The peer forced closure of the connection"
$$end_record
 
 
TL_INFO(TF_PROTOCOL) [0]1DAC.056C::09/29/2014-08:47:02.095.000007be (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[4039661650] $$begin_recordTrace-Correlation-Id: 4039661650
Instance-Id: 2838
Direction: outgoing;source="local"
Peer: 172.28.91.102:6861
Message-Type: response
Start-Line: SIP/2.0 504 Server time-out
From: "Pött Thomas"<sip:thomas.poett@domain.de>;tag=e08f10ad81;epid=1d691e13e1
To: <sip:xyz@microsoft.com>;tag=A6CBF413214DBEF0CAE0CF071DBF904D
Call-ID: 9ef08610a5054b66a1040bef20d1b564
CSeq: 1 SUBSCRIBE
Via: SIP/2.0/TLS 172.28.91.102:6861;ms-received-port=6861;ms-received-cid=1700
Content-Length: 0
ms-diagnostics: 1039;reason="Failed to complete TLS negotiation with a peer server";fqdn="LYNCEDGE01.domain.local:5061";ip-address="172.28.248.131";peer-type="InternalServer";winsock-code="10054";winsock-info="The peer forced closure of the connection";source="SBS02.domain.local"
$$end_record