Well folks after my last tutorial, Finally
Connected OCS to Trixbox I’m getting more and more questions about the OCS side
of thingsso I thought I’d expand on our OCS 2007 R2 side of the setup.

So the internal setup looks a little like this:

So here our IP:Z = which makes sense when looking at the OCS machines from
Trixbox as follows:

Note the or IP:Z in the hosts list here from Trixbox. In
short – as far as OCS is concerned when Chatterphone gets a request
(from either internal or external) it *has* to have all the knowledge to work out
where to route the call.

So don’t forget that OCS embeds a VOIP phone details into User Accounts within AD
– viewing the user class object will give you the right details. I wrote a webservice
that will display the user’s phone numbers etc.

I also wrote a quick WebService to pull out phone and sip address
details from AD from a search string. So if you supply part of a phone number, it
gives you the users, and if you have a sip address, it give you the phone number.
(I was going to use it for a lookup from Trixbox cause from OCS Communicator, I couldn’t
get the invite another person to the conf call via phone working – it was sending
an invalid CallerID out to our PSTN provider)

Download File – OcsHelperService

(source code included – as is, for a guide 🙂

Example calls:
I’ve installed it onto a site called ’ocsservices.office.breeze.net’ and
you can run it as follows:

  1. Lookup a Phone Number from SIP Address
    1. http://<webServer>/OcsHelperService/Lookup.svc/Process?action=getphone&caller=<sip address
      – minus ’ sip:’> e.g. mickb@acme.com
  2. Lookup a SIP Address from a Phone Number
    1. http://<webServer>OcsHelperService/Lookup.svc/Process?action=getaddr&caller=<start of
      a user’s voip number>
  3. >

    Let’s start

    Learning – What in the World is OCS doing?

    Setup meaningful logging to try and work out what Trixbox<->OCS is doing = MediationServer

    1. From the OCS Management Tool – setup a New Debug Session
    2. From the OCS 2007 R2 Logging Tool – log S4 and the Mediation Server settings.
    3. Then click Start Logging and you should be on your way to recording
      what OCS is doing in response to Trixbox. This helps you find out *exactly* what OCS
      is responding with. Calls, “No Service” etc.
    4. Go through and run through a test session of what you’re wanting to try out. e.g.
      incoming call or outgoing call.
    5. Click Stop Logging and click Analyze Log Files
    6. The OCS 2007 R2 SDK tool – snooper should come to the rescue here
      and display a detailed log of what happened. Colour coded and see what what going
    7. Here’s a sample for an outgoing call:
    8. What’s more interesting is an incoming call:
    9. In this particular call – I rang my OCS number and hung up after 2 rings. The conversation
      is pretty detailed in terms of what you see with SIP. i.e. Seeing this is the MediationServer there
      should be something like SIP INVITE->Trixbox->SIP INVITE->OCS Mediation
      (Chatterphone)->OCS Server
      You’ll notice these packets are like IP4 routing packets, with headers possibly changing,
      but you should be able to make out your dialled number in there.


      This is your handy weapon for OCS land – if communication isn’t getting through, then
      check all the IP details.

      Incoming calls to OCS

      1. Users are generally identified as +<country code><area code><number>
      2. If when making an External Call in, make sure in the above logs the number
        coming in is in the right format. i.e. +612.@acme.com
      3. What does a User Look Like
        1. Firstly they belong to a Location (the Location Name also has implications within
          ExchangeUM if you use it for Voice Mail), looking at the location code I just have
          it stock standard as follows:
        2. Finally let’s look at what a user like myself looks like from the OCS Admin Tool.
          (In my case Enterprise Pools->BreezePool1->Users)


        Hopefully this has helped a little more in working out what is going on in your OCS

        Between the logging here and the ’Asterisk -r’ option in a console app on Trixbox,
        you should be getting a better picture. Because many setups can be very different,
        looking down here at the ’packet’ level is really the only way to go in resolving

        (Another handy option is to turn on Event Logging in OCS Communicator, which gives
        some great info from a client perspective as well 🙂

        Good luck. 🙂