DMTF

Doug Makes Telephony Fun: Making Microsoft Unified Communications solutions less daunting since 2009.

Outbound PSTN Calling from an OCS Response Group

Outbound PSTN Calling from an OCS Response Group

  • Comments 12
  • Likes

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.

Comments
  • Great post Doug. Just saved my day this afternoon!

  • Would searching for the contact object in AD and assigning a policy to it work just as well?

  • @Jason: If you mean search by using one of the AD tools (like the Sites and Services snap-in) then, no. When you try to save the contact with the correct voice policy applied, you will get an error message.

    ADSIEdit might work if you know the DN of the policy you want to assign.

    Nick Smith also passed on to me this variation on the PowerShell script that assigns a voice policy to the contact by name:

    $UCPolicy = gwmi -q "select * from MSFT_SIPGlobalUCPolicyData where Name ='Local Calling'"

    $RGSContact = gwmi -q "select * from MSFT_SIPApplicationContactSetting where PrimaryURI='sip:infodesk@contoso.com'"

    $RGSContact.UCPolicy = $UCPolciy.PolicyDN

    $RGSContact.Put()

  • Not directly related, but how does the Dial-in Conferencing call-back feature from CWA apply a voice policy to control what PSTN area and country codes are valid for callback?

  • Hi,

    my 100$ question: what happens, if there is no such Default policy object (it was deleted for example)? Stuuupid developers..

  • @MikeD: The dial-in conferencing call-back feature from CWA selects the meeting organizer's voice policy for outbound routing.

    @Richard: Hmmm, good question. There's probably some method to get it back. (After all, it's just an AD object that could be restored.) But, I try not to build any configuration that relies on it anyway. So, maybe you're better off not having it.

  • Hi Doug,

    Hope you are well.  We have a strange behaviour here.  My customer has requested a response group and we have deployed it successfully with one exception.  Similar to above, calling externally doesn't work.  I have checked the number is correct and can be called from a user.  But this solution uses the default Policy & Usage for all users.  From reading the above I would have expected to have been blisfully unaware of the problem detailed above.  I wondered whether it was the fact that the RG doesn't have a location profile but then we shouldn't need one if the number entered is in E.164 format right?  Just wondering whether you have seen the same issue?  Would creating a non default policy and assigning it to our RG's may help?

  • hi,

    my outbound routing doesn't show any referrer URI (Referrer URI: <null>) and therefore is rejected, because the FRom Uri is used and is obiously not UC enabled:

    Caller not UC enabled.

    Stamping request from non UC enabled user

  • Hey,

    Any chance of getting an example of how you use this:

    $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()

    I cant figure it out and the default policy trick aint working for me.

    Thanks!

  • I am seeing  the same things as Dennis.  My configuration is setup with a route in the default policy as well as the policy i assigned to the RGS contact object.

  • Hey Doug - since WMI is gone in Lync, do you know of a way to assign a Voice Policy to a Lync RGS.

  • @Peter: If the SIP URI of your RGS workflow is helpdesk@contoso.com and the voice policy you want to assign it is RGSVoicePolicy, this PowerShell line will do it:

    Get-CsApplicationEndpoint sip:helpdesk@contoso.com | Grant-CsVoicePolicy -PolicyName RGSVoicePolicy

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment