locked
Outbound routing from OCS RRS feed

  • Question

  • We have two gateway/mediation servers:

    How does OCS determine which mediation server to send the call to the gateway when making an outbound call (not to another OCS user)? 

    How can I determine which mediation server is providing the path from a specific ocs client to the Gateway for trouble shooting purposes? 

    Can specific users/extensions be configured to use a specific Mediation server for outbound traffic (Client to Gateway)?

    Example:  OCS user x123 calls PBX user x987, call routes from OCS client to mediation server to gateway to QSIG trunk to PBX extension.

     

    Thanks

     


    Rich Pederzani Telecom Engineer
    • Moved by Ben-Shun Zhu Tuesday, November 16, 2010 7:05 AM incorrect queue (From:Capacity Planning & Performance)
    Monday, November 15, 2010 9:18 PM

Answers

  • Rich,

    When you have multiple Mediation servers (which are not configured for fault-tolerance) you need to define two separate Routes in the OCS Voice properties.  From here you have two options:

    1. Set unique phone patterns on each to define what numbers are reachable behind which Mediation server.  This would be used in the case that one route goes to the PSTN (all undefined numbers) and another goes to an internal-only PBX.

    2. Create unique Phone Usage policies and place different sets of users in them and have two Routes with the same phone pattern but each pointed to a different Mediation server.  This might be used in the case you were migrating from a PBX based PSTN connection to a SIP Trunk based solution and want to only put a subset of users (e.g. pilot users) on the new SIP trunk.

    3.  OK, there's a third :) Regarding the fault-tolerant setup I mentioned you can define a single routes which has both mediation servers assigned as gateways which would ultimately point back to either the same PBX or different PBXs, but then both go to the PSTN.  In this scenario OCS will use round-robin to select which gateway to send each call. It is true load-balancing with fault-tolerance as a heart-beat looks for the return of a failed gateway.


    Jeff Schertz, Microsoft Solutions Architect - Polycom | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    • Proposed as answer by Pankaj.Rai Tuesday, November 16, 2010 8:07 PM
    • Marked as answer by RPederzani Tuesday, November 16, 2010 8:20 PM
    Tuesday, November 16, 2010 2:40 PM

All replies

  • Rich,

    When you have multiple Mediation servers (which are not configured for fault-tolerance) you need to define two separate Routes in the OCS Voice properties.  From here you have two options:

    1. Set unique phone patterns on each to define what numbers are reachable behind which Mediation server.  This would be used in the case that one route goes to the PSTN (all undefined numbers) and another goes to an internal-only PBX.

    2. Create unique Phone Usage policies and place different sets of users in them and have two Routes with the same phone pattern but each pointed to a different Mediation server.  This might be used in the case you were migrating from a PBX based PSTN connection to a SIP Trunk based solution and want to only put a subset of users (e.g. pilot users) on the new SIP trunk.

    3.  OK, there's a third :) Regarding the fault-tolerant setup I mentioned you can define a single routes which has both mediation servers assigned as gateways which would ultimately point back to either the same PBX or different PBXs, but then both go to the PSTN.  In this scenario OCS will use round-robin to select which gateway to send each call. It is true load-balancing with fault-tolerance as a heart-beat looks for the return of a failed gateway.


    Jeff Schertz, Microsoft Solutions Architect - Polycom | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    • Proposed as answer by Pankaj.Rai Tuesday, November 16, 2010 8:07 PM
    • Marked as answer by RPederzani Tuesday, November 16, 2010 8:20 PM
    Tuesday, November 16, 2010 2:40 PM
  • very informative. thanks
    ------Exchange, OCS------
    Tuesday, November 16, 2010 8:08 PM
  • This was exactly what I needed.  thank you
    Rich Pederzani Telecom Engineer
    Tuesday, November 16, 2010 8:26 PM