OCS & PBX Integration - Direct SIP, Cannot make call from OC client RRS feed

  • Question

  • Hi guys,

    I have deployed OCS 2007 standard version in our lab, and it seems work fine.

    We have successfully configured RCC function towards Ericsson MX-ONE Telephony Server, now we want to try Direct SIP (Dual Folk) integration.

    We installed Mediation Server and setup SIP route between OCS and MX-ONE, now we can make call from MX-ONE extension to OC client, and both sides can hear each other.

    However, when I try to dial an extension number of MX-ONE from OC client, nothing happened. I configured Location file, Voice Policy and Route on OCS Global Voice Properties. I'm not sure what settings have been missed, anyone can give me some comment about this?

    Any suggestion will be appreciated.


    Friday, October 31, 2008 9:42 AM

All replies

  • This is probably something to do with your normalization rules and outbound routes. Are these configured to normalize a PBX extension and pass it to the PBX correctly? Try adding or removing the + sign before the call gets sent to the PBX.What format is the number that is sent to the PBX?

    Jamie Schwinn

    Friday, October 31, 2008 12:51 PM
  • Hi Jamie,

    Thanks for your reply.

    I have created a Location Profile, Voice Policy and Route via OCS Administrative tool.

    To verify if this works, I downloaded VoIP Voice Set and logon one user to make call. I specified 1 called number and selected the Location Profile I created, then click 'dial' button, the IP Phone registered on the PABX system rang.

    It seems that the location profile and route settings are correct. However, when I logon the same account with UC, try to dial the same number, the call fails.

    I compared the SIPStack trace of the 2 cases and found:
    1. Successful call trace:
     Start-Line: INVITE sip:3400;phone-context=MXTestProf@ljc.test.com;user=phone SIP/2.0
    From: <sip:3499@ljc.test.com>;epid=C3CE835C93;tag=c398cb1d34
    To: <sip:3400;phone-context=MXTestProf@ljc.test.com;user=phone>

    2. Failed call with UC:
    From: <sip:3499@ljc.test.com>;tag=21d4611ded;epid=67562a2a0c
    To: <sip:3400;phone-context=unknown@ljc.test.com;user=phone>

    Seems the Mediation Server cannot locate the Location Profile named MXTestProf! But I specified this location profile in the Mediation Server configuration tab.

    Any idea why the location profile I created cannot be used?

    Thanks a lot and best regards,
    Monday, November 3, 2008 7:04 AM
  • Just add some new information:

    I tried to use UC to call PABX extension 3400 for many times, sometimes the call failed, sometimes the call can be setup successfully.

    More weird, when I tried to call another extension 3401 for many times, the call setup always failed :-(

    I checked the SIPStack Trace and found sometimes the Location profile can be used to normalize the called number 3400, but all failed to normalize 3401. The location profile still seemed could not be used stably.

    Any suggestion would be appreciated.

    Best regards,
    Monday, November 3, 2008 9:40 AM
  • What does the associated normalization rule look like for that number format?


    Monday, November 3, 2008 2:35 PM
  • Hi Jeff,

    I just use the below normalization rule to simply normalize PABX internal numbers:
    Phone pattern regular expression:
    \d <Any digits>
    Translation pattern regular expression:
    $& <Just copy the input numbers>

    Strangely, the problem disappeared this morning ...

    I'm not sure why it disappeared, I have done 3 operations:
    1. Upgrade UC client to the latest hotfix;
    2. Disabled 'Company_Phone_Number_Normalization_Rules.txt' address book, where I added a regular expression when I did the RCC testing;
    3. Re-synced the address book by execute the command 'ABServer.exe -syncNow';

    Maybe this has something to do with the Address Book Service?

    Thanks a lot.
    Tuesday, November 4, 2008 3:00 AM
  • Since you re-ran the -syncNow, and that process automatically runs overnight then I'd bet that the ABS normalization rules were the culprit.


    Tuesday, November 4, 2008 1:19 PM