Outbound PSTN Calling from an OCS Response Group

The new Response Group Service in Office Communications Server 2007 R2 is a neat solution that provides inbound call routing to available agents. In terms of features, it sits somewhere between the hunt group offered on your PBX and a full contact center ACD. It’s pretty simple to setup initially and then you can delegate some workflow management tasks to the end users. There are other blogs that will walk you through setting up a response group.

There are scenarios where it is desirable to have the response group service forward the incoming call to a PSTN(1) number. This can be done when a call has remained in the queue longer than desired, when the queue is full, or anytime outside your designated working hours. The user interface is deceptively simple. As configured in the below dialog, any calls that remain in the InfoDesk queue for longer than 300 seconds will be forwarded to (206) 555-1202:

RGS-queue-properties-timeout

Pretty straightforward, right? I thought so, too. However, I had two reports of this not working in the same week. Then, I found this post from Kevin which, after claiming outbound PSTN calls don’t work, provides a workaround. Given the conflicting evidence on the issue, an investigation was in order.

If the Communicator logs from the client aren’t appropriate or available, I always start my investigations with OCSLogger. Since this problem involved outbound calls, I made sure to check the OutboundRouting component.

OCSLogger-outboundrouting

To reproduce the problem, I called into this response group from a PSTN phone and waited in the queue until it timed out then tried (but failed) to send me to the external number. Here is a (significantly trimmed) snippet of what shows up in the OutboundRouting log:

   Creating a OutboundRoutingTransaction object (4)
  From uri: +12065551201@contoso.com
  From User Uc Enabled: False
  From User Policy: <null>
  ReferrerUri: infodesk@contoso.com
  Referrer Uc Enabled: True
  Referrer Policy: <instance><property name="Name"><![CDATA[Default Policy]]></property>...
  Referrer Home server: <null>
  IsAvMCUDialOut: False
  Applying referrer's outbound policy
  Routing request based on caller: infodesk@contoso.com
  User infodesk@contoso.com has UC policy: Default Policy
  target phone number: +12065551202, PhoneRouteUsage: Default Usage
  No hits. Exit.
  Respond with 403

Can you tell what the problem is? I’ll wait here until you find it. :-)

Every outbound call that OCS makes must be done in the context of a voice policy. It is the voice policy that lets OCS know if the caller is authorized to make the call and, if so, which route should be selected. Usually, this is the policy that is assigned to the enterprise voice user making the call.

However, in several scenarios, it makes sense to apply a different policy. In the delegate scenario, you can place a call “on behalf of” the boss have the voice policy of the boss apply. For a call placed by an Exchange UM Auto Attendant, the policy assigned to the OCS AutoAttendant user is used. And, here, in the case of response groups, the policy assigned to the response group contact object is used. (Look for “Applying referrer's outbound policy” in the log above.)

“Wait,” you say. “When I created the response group contact object, I wasn’t able to specify a voice policy.” That’s right. The tool leaves the UC policy attribute blank for the application contact so OCS uses the “Default Policy.” In this case, the “Default Policy” has no routes. You can tell by the “No hits” statement in the log.

Note: This explains why the problem happens for some but not for others. If you have modified your enterprise voice Default Policy to include a valid route for the destination number, then you are blissfully ignorant of this particular problem.

There are two avenues, then, to correcting the problem. The first (and easiest) would be to modify the default policy to include a valid route for the PSTN numbers that you allow to be called. Because this policy may be used as the default in other situations, though, I would be wary of changing it. Perhaps the best idea is to leave it with no valid routes and choose my second option: modify the voice policy that is assigned to the response group contact object.

There are a number ways that you could modify the response group application contact object. I had problems, though, using any of the GUI tools. (I don’t think the OCS admin tool was really built to work from the Sites and Services snap-in which is what you need if you use the default settings and store application contacts in the AD configuration container.)

Since WMI is the supported method of administering OCS settings and since PowerShell is great with WMI, I decided to try that. These PowerShell commands will take the voice policy of an existing user and assign it to the Response Group Service application contact:

 $VoiceUser = gwmi -q "select * from MSFT_SIPESUserSetting where PrimaryURI='sip:alice@contoso.com'"
$RGSContact = gwmi -q "select * from MSFT_SIPApplicationContactSetting where PrimaryURI='sip:infodesk@contoso.com'"
$RGSContact.UCPolicy = $VoiceUser.UCPolicy
$RGSContact.Put()

Note: The WMI objects for OCS should be available on any machine where the OCS Administration Tools have been installed.

When selecting which voice policy to assign to the response group, consider who the managers of the workflow are and use the most restrictive policy that applies to them. This will avoid issues where the workflow can be configured to route calls to numbers that the users should not be able to call directly.

After correcting the voice policy and reproducing the scenario again, this is the corresponding OutboundRouting log:

   Creating a OutboundRoutingTransaction object (2)
  From uri: +12065551201@contoso.com
  From User Uc Enabled: False
  From User Policy: <null>
  ReferrerUri: infodesk@contoso.com
  Referrer Uc Enabled: True
  Referrer Policy: <instance><property name="Name"><![CDATA[Unrestricted Calling]]></property>...
  Referrer Home server: <null>
  IsAvMCUDialOut: False
  Applying referrer's outbound policy
  Routing request based on caller: infodesk@contoso.com
  User infodesk@contoso.com has UC policy: Unrestricted Calling
  target phone number: +12065551202, PhoneRouteUsage: Unrestricted
  #hits: 2, route names: Default Route Default 
  Attempting to find GetNextHop: Length:1; StartAt:0; Tried:1; FQDN/State:UCLAB-MS1.contoso.com:5061-Up
  New request line: sip:+12065551202@UCLAB-MS1.contoso.com:5061;user=phone;maddr=UCLAB-MS1.contoso.com. Exit.

Notice in this log that a policy other than the empty “Default Policy” is selected. You can see that a mediation server is selected from among the valid routes.

Note: This problem would not have occurred for a call from an enterprise voice-enabled user that called into the queue from Communicator. In that case, the caller’s voice policy (as determined by the From URI) would be applied instead of the policy of the response group contact object (as determined by the Referrer URI).

I hope that this post helps to resolve this particular issue for you but, more importantly, I hope it provides some insight into how OCS outbound routing works and how to troubleshoot these kinds of issues.

--Doug

Footnote 1: Most of the time, when I say “PSTN number” in this context, I really mean “any number not handled by OCS.” This could be an internal number on your PBX as easily as a PSTN number.

This post has been brought to you by RGSCOT.EXE – Ah, RGSCOT, you could have been so much more.