This view lists out the entire message transaction log of the conversation in order. To explain what is going on here, there is a process flow view in Snooper (the purple icon top right with arrows) that provides a graphical view of a conversation This image shows you the complete conversation that happened between two parties. Either way you end up with something like this the called party or find the first invite in the conversation and right click to find related messages to the same conversation. You can do this by searching the log for unique values e.g. The first thing you want to do is filter the log to show only to conversation you want to troubleshoot. The trace tab gives you verbose information of the entire log file. Here, lists all the SIP messages captured by the log. The key tab you probably always want to start in is the “Messages” tab. When you first open Snooper and parse the log file it can be quite daunting. It provides deep insight into a SIP conversation and it fundamental to troubleshooting communication problems within the Skype for Business ecosystem. Snooper is a log parse program especially designed to parse Skype for Business SIP log files. You open this log using Snooper, a tool included in the Skype for Business Debugging Tools. With Skype for Business Online and Cloud PBX you lose some of this end to end traceability because you don’t have access to the Front End Servers, so all your troubleshooting is done using the client log file called Lync-UCCApi.UCCApiLog located in the local app data folder of the user’s profile. They are stored in log files on clients and can also be captured from the Server using centralised logging or using a network packet capture program such as Wireshark. SIP messages are not located in Server Event Logs like most Microsoft applications. Viewing SIP messages in Skype for Business you need the debugging tools installed on your machine. The result is of course that systems can communicate with each other at various degrees of integration. Granted almost every system has their own small modifications to the protocol (usually additional information only relevant to their system within the SIP message) but the core methods are pretty standardised. Both Cisco, Microsoft and others conform to at least SIP RFC 3261 an internet standards based protocol. For instance Cisco and Microsoft are two very different VoIP ecosystems but they can quite easily talk to one another because under the bonnet there is a common set of protocols that define how they fundamentally work. I know I am never going to deploy or work on these other systems, but learning how the underlying protocols work gives you a firmer footing to deal with questions around it. I am Microsoft, why would I have this experience? But as a Skype consultant you’re expected to have knowledge of these systems to some degree if you are to integrate voice especially. I have never deployed or administered a Cisco or Avaya PBX system for instance because I just haven’t been in a situation where I have needed to. As a result, I often find it difficult to grasp some concepts on how things work outside of Lync / Skype for Business. There are still some areas where I feel I have gaps in my “data bank” as it were. Some might say this is the best way to learn, and while I agree to a point, there are times where I am in a room full of people and feel like the novice still. All of my knowledge has been a mixture of trial and error, death by fire and reading other people’s blogs. I have never been officially trained on Lync or Voice over IP. Coming from a traditional Microsoft background, when I started with Lync I had no conception of voice, or SIP and spent the best part of my early career actively avoiding anything to do with the subject. This blog is mainly for myself but it may serve anyone who needs a refresher or who is beginning to enter the world of SIP and Skype for Business.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |