Pre Call Diagnostic tool

The Pre Call Diagnostic Tool is a really interesting tool that has been available in 64 and 32bit versions for quite some time now but it still surprises me how many customers don’t realize its available for their use for free. The 64 bit version is available when you down load the OCS 2007 R2 Reskit and the 32 bit version is a separate download since it was only available after the release of the Reskit.

This tool offers the ability for a user to check the current state of the network before making an enterprise voice call. It is most useful when users are using networks that are uncontrolled like the internet, so great for testing you network access back to the OCS AV edge.

The screen shot below is the tool open on the desktop showing a good connection back to my corporate network. This is just after starting the tool.



The next shot shows the tool after its been up and running on my desktop for a while. It is showing a little bit of jitter but still good conditions to make a call. Some variation delay is normal on any network so this small amount of jitter is none to be concerned about.



This next shot is of the allowed settings and log file location. Similar to Communicator it uses the same DNS methods to locate the edge or internal pool resources, hence the use of a user SIP URI to find the correct SIP domain. You do not need to be logged onto Communicator to use the tool.



The last shot shows the tool minimized in the Task Bar. So if the tool is left running you will be able to see network conditions before making a call.



Hopefully for those that didn’t already know of its existence this has been of some help.

12 comments:

  1. just 2 sidenotes:

    #1 it is not trivial to make that work if the computer is not joined to domain (at least I was not able to configure it, the xml config file has no documentation)

    #2 this tool is nothing more scientific than an ordinary "ping -t". I expected that this tool shows statistics of packets sent/received by the communicator.exe process, but no.

    ReplyDelete
  2. I agree with the comment above. I have not been able to make this work on my workstation that is not a domain member. If anyone has any information on how to configure the XML config file, I'd love to hear it.

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Hi,

    #1 I am looking into this point. Even with a machine that allowed Communicator to function without it being a domain joined machine it didn’t work. I will post back when I find something out.
    #2 This isnt a packet monitoring tool like you suggest. Although this is much simpler it does provide some important troubleshooting information that can be collected over time and help troubleshooting flaky network connections. I still think you have an interesting idea but I am not sure the average user would be able to take advantage of this information. If the information can be presented in a understandable format so that a user could at least describe it to a help desk operator it may be helpful.

    ReplyDelete
  5. if the tool is no more intelligent than a ping, its close to useless. if the tool is intelligent and actually uses traffic patterns (or allows configuration) to mirror a network QoS policy, then there is some value.

    using bad data or a tool that does not understand the underlying network is more dangerous than helpful.

    ReplyDelete
  6. The tool is really aimed at the average user to understand network conditions to make a call similar to the indicator you get on a cell phone. Its not meant as a replacement for more complicated network sniffing or monitor tools. On the internet there is no QoS policy so any tool to help a user make a decision to use Communicator to make a call is in my opinion helpful.

    It sounds as though you are looking for a more comprehensive troubleshooting tool. There is a OCS VoIPtestset but it may not be as comprehensive as you would like as far as call quality goes.

    Good feedback that I can pass back to the BU. Thanks.

    ReplyDelete
  7. Chris:

    (I wrote the 1st post)

    this tool actually sends about 10-15 UDP STUN packets/sec to the AV edge server. The response it gets back from the AV edge is used to guees/ calculate roundtrip time, jitter and packet loss. I think that amount of traffic is so scarce, it can only be used to see a really BASIC network quality.

    At the first time when I had no experience with this tool, my assumption was that this tool will actually visualize network conditions DURING a call. So I can visually see why that call was terrible: example I see the packet loss graph goes high and during that second I hear silence instead of the remote party speaking; or 2nd example: jitter graph goes high, and in parallel I start hearing the speaker talking in chipmunk style (2x times faster than normal) because packets was delayed in the buffer and now start to playback audio from the previous 4-5 seconds @ a faster speed.

    Communicator client by default has only 2 yellow exclamation marks for "poor" network conditions, but I cannot interrogate the client to tell me exact facts, why it is "poor". That tool was my expectation for the problem, but no luck.

    ReplyDelete
  8. Hi Chris,

    First - I really get a ton of value from what you write (that's why I'm here) so a big thank you.

    I agree that if the tool is meant to help the 'average user' get some indication of what their experience may be - especially over an ISP, there is value.

    The danger is when this tool is given to users on an enterprise network that is designed to handle 'real time' traffic, then imply this tool can give an indication of what call quality may be. Context is everything and when it is missing usually means more work & problems created than problems solved.

    Thanks and please keep up the very informative and helpful talks!

    ReplyDelete
  9. I think I get more from where you are coming from when you started to mention the current status indicators of poor network conditions. I agree the current client is challenged in this area and there is certainly room for improvement. Watch this space in the next release.

    Back to the very first comment about non domain joined computers. This is a known issue and a fix is being incorperated for a future release to the tool.

    Thanks for the great feedback from everyone it certainly keeps me motivated that I am bringing value in the information I am posting.

    Thanks
    Chris (VoIPNorm:)

    ReplyDelete
  10. Chris,

    Have you had any luck making the tool work on a machine that is not joined to a domain?

    ReplyDelete
  11. This is a known issue and a fix is being incorperated for a future release to the tool. I was unsuccessful at making it work on the current release of the tool.

    ReplyDelete
  12. This tool doesnot work and error's out with the below message, The machine is joined to the domain but OCS R2 is installed in a different domain,is this related ? Communicator is configured for auto and has no issues connecting to OCS R2 environment from this pc.

    "There was an error starting the channel,

    There was an error signing into the SIP server using the sip URI you've configured.Please double check that the SIP URI is correct for the logged-on user,Also, this might indicate that the server might be temporarily down."

    Avinash

    ReplyDelete

Note: Only a member of this blog may post a comment.