Well folks after my last tutorial, Finally Connected OCS to Trixbox I’m getting more and more questions about the OCS side of things…so 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 = 10.1.1.30 which makes sense when looking at the OCS machines from Trixbox as follows:

Note the 10.1.1.30 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)

(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. 
3. 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>
   
4. 

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. 
3. From the OCS 2007 R2 Logging Tool – log S4 and the Mediation Server settings.
4. 
5. 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.
6. Go through and run through a test session of what you’re wanting to try out. e.g. incoming call or outgoing call.
7. Click Stop Logging and click Analyze Log Files
8. 
9. 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 on.
10. Here’s a sample for an outgoing call:
11. 
12. What’s more interesting is an incoming call:
13. 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.
1. 

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. 
3. Finally let’s look at what a user like myself looks like from the OCS Admin Tool. (In my case Enterprise Pools->BreezePool1->Users)
4. 

Hopefully this has helped a little more in working out what is going on in your OCS world(s).

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 these.

(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.

Mick.