FROM number on inbound call not being normalized at FE server RRS feed

  • Question

  • We’re running into an issue at a customer site that I think (but not sure) may have started after applying the most current OCS R2 updates.  They have a direct SIP connection between Cisco CallManager and the mediation server.  The mediation server is configured to strip + for outgoing calls to CCM.  The problem is that incoming calls to OCS now display a non-normalized number and fail to RNL to display corresponding name.  Furthermore, attempts to callback the number by selecting it from Recent Contacts fail.

    Looking at the trace logs in both the mediation server and the front-end server, we see the following for the inbound call:

    ·         The SIP INVITE received by the mediation server from CCM has, as expected, a FROM header in the form of sip:4035551234@ccmipaddress.  (I’m using an example 10-digit North America number here)

    ·         The mediation server adds its location profile by changing the FROM header in the outgoing INVITE (to the front-end server) to sip:4035551234;phone-context=locationprofile@domain;user=phone

    ·         Note: The location profile used has the normalization rules required to normalize the number to +14035551234.  (but it doesn’t get normalized)

    ·         The front-end server receives the INVITE with the abovementioned FROM header.  But instead of normalizing the FROM number (as would be expected), it sends an INVITE to the MOC client with a PAI (P-Asserted-Identity) header set to sip:4035551234;phone-context=enterprise@domain;user=phone and the FROM header still contains sip:4035551234;phone-context=locationprofile@domain;user=phone

    ·         So the FROM number is not normalized, RNL for calling number fails, and the caller is displayed simply as 4035551234.

    ·         Also, 4035551234 is added to Recent Contacts.  If the user attempts to call from Recent Contacts, the call fails because the INVITE to the front-end server is directed to sip:4035551234;phone-context=enterprise@domain;user=phone and there is no route for non-E164 numbers.

    I believe that this was not an issue prior to installing the most recent OCS updates available via WSUS, but I can’t be certain.  Can you please shed some light on this or suggest areas to investigate?


    Friday, June 5, 2009 8:02 PM

All replies

  • Run a trace on your pool with the TranslationApplication item selected to see which normalization rule it's matching (if any).  I assume your normalization rule looks something like this:

    Pattern: (\d{10})
    Translation: +1$1

    Mike Stacy | Evangelyze Communications | http://www.evangelyze.net/cs/blogs/mike
    Sunday, June 7, 2009 12:51 PM
  • Found the problem.  And I think it's a bug. :-)
    We're allowing users migrated from a legacy PBX to continue to enter the offnet prefix (9), but not require it.  Instead of having 2 rules for every case, one with 9 prefix and one without, we're using the standard ? quantifier regex element.  So for 10-digit dialing, the pattern is ^9?([2-9]\d\d[2-9]\d{6})$ with translation +1$1.

    That works fine for client-side normalization.  And it works fine for inbound normalization of the TO header on INVITEs.  And they all behave as expected in RouteHelper.  The problem is with the FROM header on inbound signaling.  Normalization fails without any indication that it fails.  The only hint that it fails is observing in the traces that the FE server inserts a PAI (P-Asserted-Identity) header in the INVITE with the non-normalized number and phone-context=enterprise@domain.

    So the workaround was to not use the regex ? quantifier, and create 2 rules for each case -- one with 9 prefix and one without.

    I don't recall seeing this behaviour prior to the last round of OCS updates, but I might be wrong.


    Sunday, June 7, 2009 9:06 PM
  • I've seen improper behavior along these lines as well recently, so I'm also suspicious that there is an "undocumented feature" in the latest updates.  I haven't been able to narrow it down specifically but I have a couple cases where 9?1? didn't work as expected but using a ?: syntax worked.
    Mike Stacy | Evangelyze Communications | http://www.evangelyze.net/cs/blogs/mike
    Monday, June 8, 2009 1:24 AM