locked
OCS 2007 R2 ignoring certain normalization rules on the server side RRS feed

  • Question

  • Hi everyone,

    I'm working on an OCS 2007 R2 configuration, and I'm having some issues with phone number normalization...

    Basically, because of limitations on the media gateway (old version of Cisco CM) and IT department policies here which don't allow me to modify it's configuration on certain areas, I'm force to have OCS "denormalize" phone numbers before they are dispatched to the media gateway. So, I need the mediation server to send the media gateway the numbers already formatted as they would be dialed internally (for instance, remove "+1" and add "9" before external number to get to the PSTN). I realize this type of configuration is far from ideal, but it's pretty much the only option I got currently...

    I've setup different normalization rules for this, and everything seemed to be working fine on the client side with office communicator 2007. A number such as "+1 555 555 5555", for instance, is changed to "95555555555" by the client and it reaches the media gateway correctly. Calls work without issues there.

    My problem appears when normalization needs to happen on the server side, such as when using call forwarding, simultaneous ringing or the forward missed calls features. I noticed that, although calling these kind of numbers from the client worked correctly, those other features didn't worked with the same numbers.

    I did some testing with the route helper, which allows to test normalization rules processing on the client and server side. It looks like when normalization is processed on the server side, if the number starts with "+" OCS will skip any normalization and directly send the original number to the gateway. The client side always processes the normalization rules, even if the number starts with "+".

    So, basically my question would be if there's any way to have numbers that start with "+" go through normalization when processed on the server side (as the client side does). I tried the WMI setting for stripping the + sign on the mediation server (which I need anyways because this gateway doesnt support that character), but that didn't help with this problem...

     

    Thanks in advance,

    Juan G

    Wednesday, October 20, 2010 12:38 PM

Answers

  • This behavior is by-design.  When OCS sees the leading + character it assumes the number has already been normalized into the proper RFC3966 (+E.164) format and does not attempt to further normalize the number. 

    This is why is important to properly normalize the numbers prior to sending to OCS.  You really should be using the Media Gateway to handle the normalization of number patterns so that numbers handed off to each system (OCS and the PBX/PSTN) in their native formats.

    Also, the WMI setting for stripping the + is only processed on outbound calls, which is why it did not make any difference in your testing of inbound calls.


    Jeff Schertz, Microsoft Solutions Architect - Polycom | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    • Marked as answer by Juane2001 Friday, October 22, 2010 12:38 PM
    Thursday, October 21, 2010 2:37 AM

All replies

  • I am having a similar problem where simultaneous ring doesn't normalize the number.  This started happening about 1 month ago.  Security Update or Patch ???

    Looking forward to a resolution.

    Thank You,
    Eric

    Wednesday, October 20, 2010 11:08 PM
  • This behavior is by-design.  When OCS sees the leading + character it assumes the number has already been normalized into the proper RFC3966 (+E.164) format and does not attempt to further normalize the number. 

    This is why is important to properly normalize the numbers prior to sending to OCS.  You really should be using the Media Gateway to handle the normalization of number patterns so that numbers handed off to each system (OCS and the PBX/PSTN) in their native formats.

    Also, the WMI setting for stripping the + is only processed on outbound calls, which is why it did not make any difference in your testing of inbound calls.


    Jeff Schertz, Microsoft Solutions Architect - Polycom | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    • Marked as answer by Juane2001 Friday, October 22, 2010 12:38 PM
    Thursday, October 21, 2010 2:37 AM
  • Thanks Jeff, unfortunately I was expecting that... but since the normalization was working on the client side I thought that maybe there was a hope of having it worked out on the server side.

    If anyone faced a similar situation and worked around it before, help would be greatly appreciated.

    Thursday, October 21, 2010 1:32 PM
  • Ericc,

    Did you apply any patches on OCS recently (besides windows update)? I recommend testing the numbers that are giving you problems with the route helper on both client and server side mode, and see if you are getting different results on rules processing. If not, you are facing a different problem.

    Thursday, October 21, 2010 1:37 PM
  • Juane,
    OCS is current with all OCS Updates but only via Windows Update

    When I run RouteHelper and enter the 10 digit number both client and server nomalize properly and add the +1

    But when the calls goes from Mediation to our PBX Gateway the +1 is missing and the call is rejected as Invalid Address.

    Two repeatable cases

    1. Simultaneous Ring Succeeds
    OCS User A calls OCS User B
    OCS User B Rings at Desk and is configured to Simultaneous Ring a Cell Number
    OCS sends call with OCS User A's Number to OCS User B's Cell Number
    Cell Rings and Call can be answered
    No Issue, This works as expected

    2. Simultaneous Ring Fails
    External Caller calls OCS User B
    OCS User B Rings at Desk and is configured to Simultaneous Ring a Cell Number
    OCS sends call with External Callers Number to OCS User B's Cell Number
    Cell Never Rings
    Call to Cell Fails

    -Confirmed with SIP Provider that they will allow call out to spoof from number as External Caller
    -Traces on Case 1 show that Mediation passes a fully normalized number of User B's Cell number
    -Traces on Case 2 show that Mediation is not passing a fully normalized number of User B's Cell number
    -Checked WMI value on Mediation for RemovePlusFromRequestURI is NULL

    Thanks for your help

    Eric

     

     

    Thursday, October 21, 2010 6:20 PM
  • Do any of the Normalization pattern contain a '?' character in them?  There is a known bug in OCS where in cetain scenarios (like call forwarding) the ? causes the normalization to fail.
    Jeff Schertz, Microsoft Solutions Architect - Polycom | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Friday, October 22, 2010 11:59 AM
  • Ericc,

    Based on what you are describing, it seems like yours is a different problem from what I've been facing. Jeff's advice about the bug with "?" on regular expressions is worth a shot. I'm afraid I don't have anything else to suggest besides double checking if there might be something wrong on the PBX gateway... I recommend you open up a new thread with your issue in the forums to see if someone else can help.

    Friday, October 22, 2010 12:38 PM
  • So my nomalization rules have no ? in them

    but my Route Patten to the Mediation server is

    ^\+?(\d*)$

    That might be it, but how do I correct it?

    Eric

    My Question has been moved here

    http://social.technet.microsoft.com/Forums/en/ocsvoice/thread/967e5f9c-67a5-4523-a5be-6360e8c69551

    Friday, October 22, 2010 3:48 PM