locked
RNL inbound calls RRS feed

  • Question

  • Environment:
    OCS 2007 R2
    Mitel PBX
    NET Media Gateway
    All internal extensions are 4 digit are non-DID
    1 Mediation Server
    1 Front End Server
    1 Edge Server

    Address Book Normailzation:
    ^(\d{4})$
    $1

    Scenario:
    User1 (Mitel extension 1111) dials 2222 on her Mitel phone.
    User2 (OCS extension 2222) is presented with a toast which has the extension 1111 listed within.

    TelURI for User1 is not configured.
    User1's AD object has the telephone number field populated by 1111 
    User2 is enabled for Enterprise Voice.  tel:2222
    User2's AD object has the telephone number field populated by 2222
    When User2 selects User1's contact card in OCS she see's 1111 as the work number.

    I've attempted to use
    ^(\d{4})$
    $1;phone-context=dialstring
    in the address book normalization rules but that doesn't appear to resolve the reverse number lookup issue.

    Can you please explain exactly how the address book works with the OCS client to successfully perform RNL?
    Thursday, May 7, 2009 9:55 PM

Answers

  • Issue is resolved.  At some point yesterday it just started functioning.   I'm not sure what cause it to start working.  It was pretty funny actually, I placed a call to Microsoft PSS to troubleshoot the issue and when I attempted to reproduce the issue so the tech could see what I was experiencing, RNL worked.   In discussions with the PSS tech he confirmed what I thought the RNL process was.

    1. "TelephoneNumber" attribute populated with non-DID extension number.  For example 1074.
    2. OCS Address Book Server connects to Active Directory and pulls information on certain attributes (http://technet.microsoft.com/en-us/library/bb894585.aspx) then stores this information in the OCS SQL back end database.  This process can be manually performed by running "abserver.exe -regenur" on the Front End server.  Review the OCS event log on the front end server to verify that the user data replication is complete.  You'll see it attempt replication for multiple directory partitions and domains.
    3. After the user replication process is complete, the information is stored in the OCS back end database, but not in the address book files on the OCS address book share.  The process of updating the address book share is performed by the address book server by default at 1:30am each morning.   This process can be manually performed by running "abserver.exe -syncnow" on the Front End server.  Review the OCS event log on the front end server to verify that the address book synchronization is complete.  You'll see a "Synchronization Pass Summary" in the event log which provide information on the synchronization process.
    4. Once the updated address book files are on the address book share, the client has access to them, but communicator doesn't automatically download these files unless certain circumstances apply.   (http://technet.microsoft.com/en-us/library/bb894482.aspx)   To get around this synchronization schedule you can delete the galcontacts.db file on the client's workstation (http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=17)
    5.  Once an updated GalContacts.db exists on the client device, open up the galContacts.db file with notepad and search for the extension number that you expected to be there for RNL.  If the extension number is not listed in the galcontact.db file RNL will not function for that user.
    6. Login to communictor.  Have a PBX user call the OCS user.  Verify that RNL is functioning.  The OCS user should see a toast at the bottom of the screen which has the resolved user name at the top and the caller's extension at the bottom.

    At this point everything is functioning as expected, but throughout this process I was unable to find a way to log the RNL process that occurs on Communicator.   I turned on logging, but didn't see any relevant information.  If anyone has any suggestions around being able to log the RNL details in communicator I would be greatly appreciative.

    There is a different process which is used for server side RNL.  When the mediation server receives a call from a PBX user it'll attempt to perform RNL against the msRTCSip-Line attribute.  I haven't looked at this process in detail so I won't comment on it at this time.

    Cheers,
    B
    • Marked as answer by ME5555 Wednesday, May 13, 2009 6:27 PM
    Wednesday, May 13, 2009 6:27 PM

All replies

  • You must check Invalid_AD_Phone_Numbers.txt for numbers that were not normalized correctly
    Then adapt your Addressbook normalization so that it resolves to a E.164 number
    Then have your gateway send the numbers in E.164 number format
    - Belgian Unified Communications Community : http://www.pro-exchange.be -
    Monday, May 11, 2009 11:12 PM
  • All numbers in the Active Directory (Telephone Number Attrib) have been standardized to a format of dddd.   Invalid_AD_Phone_Numbers.txt does not contain any numbers which failed normalization.    Is there any way to log on the server or client side what's occuring during RNL?  I've used OCSLogger on the Front End server and Mediation server but I don't know what to look for.
    Tuesday, May 12, 2009 10:32 AM
  • Issue is resolved.  At some point yesterday it just started functioning.   I'm not sure what cause it to start working.  It was pretty funny actually, I placed a call to Microsoft PSS to troubleshoot the issue and when I attempted to reproduce the issue so the tech could see what I was experiencing, RNL worked.   In discussions with the PSS tech he confirmed what I thought the RNL process was.

    1. "TelephoneNumber" attribute populated with non-DID extension number.  For example 1074.
    2. OCS Address Book Server connects to Active Directory and pulls information on certain attributes (http://technet.microsoft.com/en-us/library/bb894585.aspx) then stores this information in the OCS SQL back end database.  This process can be manually performed by running "abserver.exe -regenur" on the Front End server.  Review the OCS event log on the front end server to verify that the user data replication is complete.  You'll see it attempt replication for multiple directory partitions and domains.
    3. After the user replication process is complete, the information is stored in the OCS back end database, but not in the address book files on the OCS address book share.  The process of updating the address book share is performed by the address book server by default at 1:30am each morning.   This process can be manually performed by running "abserver.exe -syncnow" on the Front End server.  Review the OCS event log on the front end server to verify that the address book synchronization is complete.  You'll see a "Synchronization Pass Summary" in the event log which provide information on the synchronization process.
    4. Once the updated address book files are on the address book share, the client has access to them, but communicator doesn't automatically download these files unless certain circumstances apply.   (http://technet.microsoft.com/en-us/library/bb894482.aspx)   To get around this synchronization schedule you can delete the galcontacts.db file on the client's workstation (http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=17)
    5.  Once an updated GalContacts.db exists on the client device, open up the galContacts.db file with notepad and search for the extension number that you expected to be there for RNL.  If the extension number is not listed in the galcontact.db file RNL will not function for that user.
    6. Login to communictor.  Have a PBX user call the OCS user.  Verify that RNL is functioning.  The OCS user should see a toast at the bottom of the screen which has the resolved user name at the top and the caller's extension at the bottom.

    At this point everything is functioning as expected, but throughout this process I was unable to find a way to log the RNL process that occurs on Communicator.   I turned on logging, but didn't see any relevant information.  If anyone has any suggestions around being able to log the RNL details in communicator I would be greatly appreciative.

    There is a different process which is used for server side RNL.  When the mediation server receives a call from a PBX user it'll attempt to perform RNL against the msRTCSip-Line attribute.  I haven't looked at this process in detail so I won't comment on it at this time.

    Cheers,
    B
    • Marked as answer by ME5555 Wednesday, May 13, 2009 6:27 PM
    Wednesday, May 13, 2009 6:27 PM