locked
Caller ID Match to AD Record Cisco CUPS 6.x and OCS 2007 RRS feed

  • Question

  • I currently have OCS configured and working with Cisco CM 6 and CUPS 6.  I am trying to work through all the variations with number normalization in AD.  I have no problems making outbound calls but getting the record to match on incoming calls is proving difficult.

     

    Here is a snippet from the Communication Log showing an incoming call from 8322566007

     

    <DeliveredEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
     <monitorCrossRefID>a80b7b3c</monitorCrossRefID>
     <connection>
      <callID>0_a80a537c</callID>
      <deviceID typeOfNumber="dialingNumber" bitRate="constant">tel:7105;phone-context=dialstring;device=SEP0011215A1E7C</deviceID>
     </connection>
     <alertingDevice xmlns:AA="http://www.w3.org/2001/XMLSchema-instance" AA:type="SubjectDeviceID">
      <deviceIdentifier typeOfNumber="dialingNumber" bitRate="constant">tel:7105;phone-context=dialstring;device=SEP0011215A1E7C</deviceIdentifier>
     </alertingDevice>
     <callingDevice>
      <deviceIdentifier typeOfNumber="dialingNumber" bitRate="constant">tel:8322566007;phone-context=dialstring</deviceIdentifier>
     </callingDevice>
     <calledDevice>
      <deviceIdentifier typeOfNumber="dialingNumber" bitRate="constant">tel:7105;phone-context=dialstring</deviceIdentifier>
     </calledDevice>
     <lastRedirectionDevice>
      <notRequired xmlns:AA="http://www.w3.org/2001/XMLSchema-instance" AA:type="Empty"/>
     </lastRedirectionDevice>
     <localConnectionInfo>alerting</localConnectionInfo>
     <cause>normal</cause>
    </DeliveredEvent>

     

    I have tried the following formats in AD (Running abserver.exe -regenUR between changes and deleting GalContacts.db from the client each time)

     

    +8322566007, +18322566007, 8322566007

     

    The contact name never shows up when the call is ringing or after answered.  I suspect it has to do with the ";phone-context=dialstring" at the end of the dialingNumber.   

     

    Any ideas?

     

     

    Tuesday, June 10, 2008 11:53 PM

All replies

  • Progress

     

    I was able to get this function working!!!!

     

    I cleared my Company_Phone_Number_Normalization_Rules.txt file and have started with just these lines.

     

    (\d{4})
    $1;phone-context=dialstring

    (\d{10})
    $1;phone-context=dialstring

     

    Now I get a match on incoming calls. 

     

    Now I still have a problem with dialing out from MOC.  If you call the number from a contact it shows the contact name fine.  However, if I type in the number manual and dial it does not find a match.  The trace from communicator for an outbound call is the following:

     

    <DeliveredEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
     <monitorCrossRefID>a810826c</monitorCrossRefID>
     <connection>
      <callID>0_a80a537c</callID>
      <deviceID typeOfNumber="dialingNumber" bitRate="constant">tel:7405;phone-context=dialstring</deviceID>
     </connection>
     <alertingDevice xmlns:AA="http://www.w3.org/2001/XMLSchema-instance" AA:type="SubjectDeviceID">
      <deviceIdentifier typeOfNumber="dialingNumber" bitRate="constant">tel:7405;phone-context=dialstring</deviceIdentifier>
     </alertingDevice>
     <callingDevice>
      <deviceIdentifier typeOfNumber="dialingNumber" bitRate="constant">tel:7105;phone-context=dialstring</deviceIdentifier>
     </callingDevice>
     <calledDevice>
      <deviceIdentifier typeOfNumber="dialingNumber" bitRate="constant">tel:7405;phone-context=dialstring</deviceIdentifier>
     </calledDevice>
     <lastRedirectionDevice>
      <notRequired xmlns:AA="http://www.w3.org/2001/XMLSchema-instance" AA:type="Empty"/>
     </lastRedirectionDevice>
     <localConnectionInfo>alerting</localConnectionInfo>
     <cause>normal</cause>
    </DeliveredEvent>

     

    Where 7105 is the calling device and 7405 is the called number.  It's the same format as the incoming call which now works. 

     

    Any ideas on why this won't work on outbound?  Does it really need the + (E.164) format?

     

    One more thing.  It does match when the call is answered on the far end.  So the only thing remaining is to have MOC show the info when the call is ringing and before dialing. 

     

     

     

    Wednesday, June 11, 2008 1:01 AM
  • Hi,

    I also have a hell with integrating CUPS to OCS. With Avaya AES, it went quite "smooth" (after the 3rd rebuild-and-start-from-the-very-beginning) because at least it has a guide. But what about the CUPS-to-OCS integration guide?

    That infamous "ccmigration_09186a00808aea28.pdf" .... I wouldnt like to share my comments about such kind of quality of a documentation.
    Friday, June 13, 2008 2:16 PM
  •  

    What does your gateway see?  Does it see the sip message coming into te gateway?  If not, then you have a routing issue for outboundnumbers.  Your dial plan is not configured correctly. 

     

    Remember that the company normlizatoin files is for normalizing numbers in communicator and the enterprise routes is for routing numbers to gateways (and normalizing them).

     

     

    None of this easy so check the basics first.

    Monday, June 16, 2008 8:17 PM
  • The reason you have to put this

     

    (\d{4})
    $1;phone-context=dialstring

    (\d{10})
    $1;phone-context=dialstring

     

     

    in the company file is becuase you are not sending a normalized nuymber (i.e. a number with a + in front of it).  If you could send a +, OCS sees that as a normalized number and will try to match a number in AD to it.  But since you are sending 7405;phone-context=dialstring the client would have to normalize it.  The only true inbound normalization happens on the OCS mediation server.

    Monday, June 16, 2008 8:20 PM
  • I know all these details quite well Smile

    My problem is about the syntax used in Line URI for the user:

    1) why do you need the ";phone-context=dialstring" after the number?
    2) it is possible to put the  "+"  sign before the number? Can CUPS handle the conversation
    between the extension, and the whole DID E.164 format number?
    Monday, June 16, 2008 8:41 PM
  • 1) The additional information in the line uri is for identification on the gateway.  It is what it is.  Not sure why it is, but it is.

    2) I don't believe cups can handle a + in the number.  Certainly call manager 6.x and earlier cannot.  I hear call manager 7 will be able to and will be able to create a SIP direct connection to OCS.  I know that the MS engineers who support the product have a difficult time with CUPS.  There are so many options for the connection.  Putting the plus sign before the number won't give you anything.  What are you hoping to accomplish?

     

    Tuesday, June 17, 2008 4:02 AM
  • I would like to get caller-identification get working.

    Right now, if somebody internally from the office calls me, I get the pop-up:
    only the extension number visible.

    I would expect, that this extension or any caller-number is matched to the Line-URI of other OCS-RCC users in AD (or to my contacts stored in outlook), and if it can find this number during the lookup, it should show the user name instead of this single extension number. What I think the problem is, that Line-URIs are administered in the following way:

    tel:<extensionnumber>;phone-context=dialstring

    So if an incoming call comes, with the caller number 1234, OCS looks this string in AD:   tel:1234

    But in AD the following string is found under my testuser1: tel:1234;phone-context=dialstring  and I have the feeling, these are no identical to each other -> OCS wont think that testuser1 is the one calling me -> will display extension number instead of user name.

    In Avaya's approach: you dont have any additional string, only the number itself in AD; and this number can be the full E.164 DID number. You have opportunity on the avaya RCC middleware (called AES server) to manipulate the incoming/outgoing call numbers in the similar way, as you can do it when using Enterprise Voice with 3rd party media gateways. The result? You have valid E.164 numbers coming in and leaving the system, so OCS is happy to have everything available as it likes it, and the rest of the system is able to convert those E.164 numbers into their own format before passing it to the PBX.
    Tuesday, June 17, 2008 8:38 AM
  •  

    Reverse number lookup doesn'thavep until the call is answered.  You will not see RNL during the toast (Popup).  You are looking at the wrong place for RNL.  RNL uses the phone number on the general page of the User's properties in Active Directory User's and Computer.  If the Cups server sent down +1234;phone-context=dialstring  then communicator would see this as a normalized number and search the local address book (that is generated from AD) for anyone who has 1234 in their phone number property.  But since CUPS is sending 1234;phone-context=dialstring  this is not an already normalized number. So Communicator will need to normalize the number and won't try a direct match to the extension 1234.  You would have to have a normalization rule to normalize 1234 to 1234;phone-context=dialstring  in order to ger RNL to work. 

     

    Something you should keep in mind.  Microsoft chose E164 for international compatability.  If you have the ability to send down a normalized number (i.e. with a + in front), then it will make your life easier.  If not, you have to work around the system to get RNL to work.  This isn't an Avaya product and you must conform to OCS standards.  An E.164 number begins with a + and that is what OCS is looking for.  Another thing to keep in mind is that this is Microsoft's first venture into the voice phone system arena.  Avaya has been around a long, LONG time.  As the product matures and SIP matures, I am sure things will become easier.

    Tuesday, June 17, 2008 1:08 PM
  • Ok, I understand your view, you are right with RNL to happen after call is connected.

    On the other hand: did you manage to make RNL work in the CUPS system? What about missed call notification emails: are they also resolved to a "username"instead of the phone number itself?
    Tuesday, June 17, 2008 1:43 PM
  • If you can help me in this case, please contact me anytime: my email address is rpasztor AT geomant DOT com

    I would like to hear your version, how you accomplished this kind of integration successfully. Thanks a lot!
    Friday, June 20, 2008 8:53 AM
  • Hi John,

    Could you please clarify, what was the format of phone number in AD when you got inbound calls to work?
    +7105 or 7105?
    PS. Are you sure, that this translation pattern should be w/o leading "+":

    (\d{4})
    $1;phone-context=dialstring
    Wednesday, July 16, 2008 2:39 PM
  • Hi

     

    RNL must work at the ringing event, not at the established event.

    You missunderstand the normalization process and RCC needs:

    -for CUPS to work, you definitly need the Tel URI in this format: tel:extension;phone-context=dialstring

    -for the RNL to work, you can have what you want in you AD telephoneNumber attribute, if you have the corresponding rule in the Company_phonenumber_normalization_rules.txt file

     

    For example, if you have in telephoneNumber attribute this format for your internal users: + 33 1 2345 6789 with space between digit groups, you will need a rule to convert this format in the format extension;phone-context=dialstring, which will allow RNL to work. In this case you need this rule (pattern/normalization result couple):

    \+33\s1\s2345\s(\d{4})$

    $1;phone-context=dialstring

     

    You don't need to have a + sign in front of the normalized rule, as long as you add phone-context=dialstring behind. If you don't, you won't see these contacts in Communicator search.

     

    If you receive external caller number prefixed by the external line prefix (0 or whatever), you will need to include this to you rules to match any existing contact in format +336xxxxxxxx (in AD or Outlook):

    \+336(\d{8})$

    006$1;phone-context=dialstring

     

    Do the same if you have your contacts in 10 digits, or space between digit groups, ...

     

     

    Wednesday, July 16, 2008 6:49 PM
  • Nkv,

    thanks for the clarification. Let me summarize the above things, to check if I understand you correct.

    Your example shows a situation, when an OCS RCC user would like to dial a E.164 number, like
    + 33 1 2345 6789. This number is administered exactly the same format in AD, as the work phone number for another OCS user in his company. When the first user click-and-dial, this + 33 1 2345 6789 number will be converted by OCS server (using the company_phonenumber_normalization_rules.txt file) to the following format:

    \+33\s1\s2345\s(\d{4})$

    $1;phone-context=dialstring


    and the result is:
     tel:6789;phone-context=dialstring

    During the RNL look-up, OCS will be able to match this string to the another user's Line URI, and will ring the other user's communicator without using the PBX phone.

    However, I am interested mainly in the other direction: if receiving an incoming call from the Cisco side. An incoming call  comes from 1234 (that is a 4 digit internal extension), that 4 digit-only number is visible on the Cisco IP phone display.

    This same 4 digit-only number pop-ups in communicator also, without being able to display the username for this caller. What I would like to achieve, is to match this 4 digit number to the username, who is calling me from internally. So to make this work, we should put a normalization rules similar to this:

    (\d{4})
    $1;phone-context=dialstring

    if I am right?

    This will convert the caller number for all 4 digit incoming calls into the very-same OCS administered Line URI format. Note: Of course this rules assumes, that all 4 digit internal extensions are OCS RCC users. But what happens if some 4 digit extensions are not administered as OCS RCC users? In this case, they would be needed to convert into the E.164 format, that will match the work phone number parameter in AD, to have successfull RNL for these users also.
    Thursday, July 17, 2008 9:18 AM
  • Any comments are greatly aprreciated, thanks.
    Friday, August 1, 2008 9:26 AM
  • Richard,

     

    Unfortunately the example you gave is not accurate.  OCS normalization rules (both ABS and location profile rules) only apply to outbound calls.  You cannot normalize the numbers of inbound calls.

     

    Friday, August 1, 2008 2:24 PM
    Moderator
  • What you say is mostly correct.  However, you did not mention that ABS normalization rules apply to RNL on the client for a non-normalized number.

    Friday, August 1, 2008 2:48 PM
  • Mike,

    after my previous experiences, mediation IS able to normalize incoming calls, if they are not in E.164 format (you can check that the feature is available from OCS Reskit Routehelper application:ad-hoc test \ gateway test: type a non-normalized number.

    Back to my original issue: ABS rules.txt file should also normalise in-bound calls, as the OCS Reskit book says such a scenario, however it does not tell details about it.
    Tuesday, August 5, 2008 8:28 AM
  • Richard,

     

    Did you ever get the caller ID Name issue resolved?  I have a similar problem with CUPS/ OCS and CUCM.

     

    R

    Thursday, January 29, 2009 9:30 PM
  • Hi,

    unfortunately not. I am still insterested in a working solution with exact examples ;)
    Monday, March 16, 2009 12:28 PM