CallManager & Mediation Server - OCS RTM RRS feed

  • Question

  • Hi all!!
    We have some problems with the connection between CallManager 5.1 and the Mediation Server.

    We  installed a lab with a pool of one Server, and a different machine for the Mediation Server (All of them Virtual Machines). The Mediation Server we installed, only has one NIC, so we're using it for incoming/outgoing calls. The configuration is the following:

    Matching URI:  Domain: test.net
    Next hop
    Port: 5060
    Authorized Hosts: (The only checked option is 'Throttle as Server')

    Mediation Server
    Communications Server listening IP address:
    Gateway listening IP address:

    Office Communications Server next hop:
    FQDN:      laboOCS.test.net
    Port:      5060

    PSTN Gateway next hop
    IP address:
    Port:      5060

    We have configured a Location Profile, Phone Usage Record, Normalization Rule, Policy and Route. The users are enabled for 'Enterprise Voice' , and their telephone numbers normalized (E.164) in Active Directory.


    Situation 1:
    When we run the 'Validation Wizard' on the Front End, and have the communication between the Front End and the Mediation Server configured to use port 5061, the wizard reports the following error on the route pointing to the Mediation Server:

     Checking Static Routes
     Failure [0xC3FCOODJ] -- Next Hop: Not trusted for Routing

    Situation 2:
    But when we changed the port to 5060 (Which is the configuration shown before) and the communication to TCP, the Validation Wizard reports 'Success'

    Situation 1 and Situation 2:
    On the other hand, in the 'Checking Listening Addresses' section, the wizard reports 'MTLS Transport: None Found' in both situations.

    So, any communication, no matter it begins from an Office Communicator Client or a CallManager IP-Phone, the call is not successfull.

    Thanks in advanced!


    Thursday, September 20, 2007 8:53 AM

All replies

  • Another thing I forgot to mention is that we have another lab installed with the PublicBeta and the integration between the Mediation Server and CallManager 5.1 works correctly without installing a gateway between. I don't know if in the RTM something has changed about this (In the Production Environment we will install the gateway, but to validate the funtionality, we are not using it until we get one).


    Thanks again!

    Thursday, September 20, 2007 9:14 AM
  • Hi milok1,


    Going by what I have seen in our system and talk from MS SE the RTM version may work slightly differnet from the beta as fas as E164 format goes and use of the + sign. Check a couple of the other threads for discussion on this subject. You may to do a work around to remove the plus sign from the incoming calls to callmanager. Hope this helps.





    Thursday, September 20, 2007 3:28 PM
  • Hi Chris!

    I checked the E164 format in the primary numbers configured in Active Directory and they are fine.


    We have made some changes in the OCS configuration (The Validation Wizard doesn't report errors) , and now we are able to initiate a call from a Cisco IP-Phone to Communicator, but not from Communicator to the Cisco IP-Phone.


    I also installed Ethereal on the Mediation Server, and saw that the IP packets from CallManager to the Mediation Server are fine, but those which goes from the Mediation Server to the CallManager have 'Checksum Errors'.


    Any Ideas?


    Thanks in advanced Smile

    Friday, September 21, 2007 12:13 PM
  • Is Mandatory to install a third party gateway between CallManager 5.1 and Mediation Server in the OCS RTM?... Because as i mentioned in a thread below, with the Public Beta it works.



    Friday, September 21, 2007 12:53 PM
  • Hi milok1,


    I have seen this before but darn if I can remember what causes it. You could try setting the Callmanager SIP trunk to talk only TCP if it isnt already. Dont think that is the issue but its worth checking.Other than that I may need some more info.


    What is the callmanager seeing?




    Friday, September 21, 2007 3:47 PM
  • Hi,


    You definitely don't need a 3rd party gateway between CCM 5.1 and OCS RTM.


    In your original post you stated:


    Matching URI:  Domain: test.net
    Next hop
    Port: 5060
    Authorized Hosts: (The only checked option is 'Throttle as Server')


    But I'm not sure where you configured this? That type of config on the front end is usually for setting up an Edge Server, not a mediation server. You don't need to configure anything like a next hop or authorized host on the front-end server at all for a mediation server to work.


    1) Your front-end server should be listening for SIP traffic on port 5061 - you need to make sure of that that in your f/e configuration.

    2) Your mediation server's next hop gateway should be the fqdn of your OCS pool name and it should be using 5061, for sure.

    3) your mediation server's PSTN gateway should be the IP address of call manager, using port 5060

    4) You need to have a CallManager SIP trunk pointing to the IP of mediation on port 5060

    5) the checksum errors in ethereal are not a problem: see http://www.ethereal.com/faq.html#q11.1

    6) Make sure that your inbound Calling Search Space on your CCM SIP trunk is set to something that is able to dial extensions and outside numbers

    7) make sure that your users are configured with the voice policy you created, not the default voice policy


    Can you post more info about your sip trunk's config? that may be where the problem is. Also, can you post about your location profile, normalization rules, usage records, routes and policy?





    Friday, September 21, 2007 6:37 PM
  • Hi!... here is the CallManager SIP Trunk Configuration that we have in our lab environment:



    Product:     SIP Trunk
    Device Protocol:    SIP
    Device Name*     Trunk_OCS
    Device Pool*     CUCM51_DP
    Call Classification*    Use System Default
    Media Resource Group List   MRGL_CUCM51
    Location     Hub_None
    AAR Group     < None >
    Packet Capture Mode*    None
    Packet Capture Duration    0

    Media Termination Point Required   (Marked)
    Retry Video Call as Audio    (Marked)
    Transmit UTF-8 for Calling Party Name   (Unmarked)
    Unattended Port     (Unmarked)



    MLPP Domain     < None >




    Significant Digits*    All
    Connected Line ID Presentation   Default
    Connected Name Presentation*   Default
    Calling Search Space    ALL51_CSS
    AAR Calling Search Space   < None >
    Prefix DN     < None >
    Redirecting Diversion Header Delivery - Inbound (Marked)


    Calling Party Selection*   Originator
    Calling Line ID Presentation*   Default
    Calling Name Presentation   Default
    Caller ID DN     < None >
    Caller Name     < None>
    Redirecting Diversion Header Delivery - Outbound (Marked)


    Destination Address*
    Destination Address is an SRV    (Unmarked)
    Destination Port^*    5060
    MTP Prefered Originating Codec*   711ulaw
    Presence Group*     Standard Presence Group
    SIP Trunk Security Profile   < None >
    Rerouting Calling Search Space   < None >
    Out-Of-Dialog Refer Calling Search Space ALL51_CSS
    SUBSCRIBE Calling Search Space   ALL51_CSS
    SIP Profile*     Standard SIP Profile
    DTMF Signaling Method*    No Preferences


    The SIP Trunk is configured to use port 5060 (TCP), so apparently it's not the problem.

    We also have configured a simple DialPlan: 


                        One Location Profile: "DefaultLocation"

    One Normalization Rule: "DefaultNormalization": ^[\d{4}] --> $1
    One Policy:  "DefaultPolicy"
    One Phone Usage: "DefaultUsage"
    One Route:  "DefaultRoute"         Pattern           Phone Usage         Gateways

                                                     ^[\d{4}]           DefaultUsage          Server02 (Mediation Server)



    We did some tests with OCSLogger (Running from the Front-End) and found the following errors, after trying to begin a conversation from Office Communicator to an IP-Phone (CallManager):


    TL_INFO(TF_PROTOCOL) [0]0554.0E6C::09/24/2007-17:21:36.322.000009bf (SIPStack,SIPAdminLog::TraceProtocolRecord:1224.idx(122))$$begin_record
    Instance-Id: 0000009F
    Direction: outgoing;source="local"
    Message-Type: response
    Start-Line: SIP/2.0 503 Service unavailable
    From: "user06"<sip:user06@test.net>;tag=3e8c944366;epid=944f170d6d
    To: <sip:user06@test.net>;tag=4CB42E82FB730D9A52C6E57DAB4949A1
    CSeq: 1 SERVICE
    Call-ID: ac253aabc96d46b5ac394143db0c72c2
    Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFFA65E052ED0EFF479844BA98A1C46D15F", srand="AC856F18", snum="23", opaque="8BF5E5FF", qop="auth", targetname="sip/SERVER01.test.net", realm="SIP Communications Service"
    Content-Length: 74
    Via: SIP/2.0/TLS;ms-received-port=2265;ms-received-cid=200
    ms-diagnostics: 2019;reason="Report error service is not available";source="SERVER01.test.net"
    Retry-After: 54
    Content-Type: application/msrtc-fault+xml
    Message-Body: <Fault>


    It's like the Front-End (SERVER01.test.net) is not able to service the request. All services are up and running.

    Thank you!!!




    Monday, September 24, 2007 6:00 PM
  • Hi Milok,

    I saw that you didn't configure a SIP Trunk Security Profile. You need to do that. In the Sec Profile you configure the incoming Port (5060) from the OCS Mediation Server
    Monday, September 24, 2007 7:10 PM
  • Good catch . Another problem I found was with RTM code when a + sign wasnt in the normalisation pattern it would not route the dialed number correctly in OCS.


    I suggest the following as a test of this:

    Change your normalisation pattern to the following-

    ^[\d{4}] --> +$1

    Then change your significant digits on the Callmanager SIP trunk to-


    Then see if four digit extensions will route to Callmanager. This will negate the +.


    Of course this will only do for 4 digit extensions but it may help to see what the problem is. From there you can either build normalisation rules to expand your numbers to a full ten digits to route to callmanager and set the significant digits to 10 to help with removing the +. That way you will be able to dial US numbers but things like 911 and international will still be a problem.





    Tuesday, September 25, 2007 3:12 AM
  • Wondering if you were able to resolve your situation.


    I want to add that I also noticed a difference on how the E.164 is being handled.  In the RTM Mediation server I had to place the incoming 10 digit normalization rule first Stick out tonguehone Pattern:  ^(\d{10})$ Translation: +1$1. Otherwise the calls were not being completed.  In the previous release, the normalization rule was lower on the list.  It took me a minute to realize that the order was causing the call failures, because the set up was working in our test environment.







    Friday, January 11, 2008 8:57 PM
  • There seems to be significant digits challange with the CUCM 6.x trunk.  When Significant digits is set to 'all' calls from MOC to CUCM endpoints fail 100% of the time.  When the field is set to 4 digits only 4 digit extensions can be dialed from MOC. When set to 12 digits, only 12 digit numbers can be dialed.  Attempted to create two SIP trunks pointing to same mediation server with different significant digit settings - poor results.


    Any ideas?  Translation rules on the CUCM could be quite messy to account for the dial plan that spans multiple locations.


    Best Regrads,



    Thursday, August 14, 2008 7:34 AM
  • Hi Paul,


    So this is all related to the incoming call to callmanager carrying the + sign. Callmanager will not accept the + sign and will drop the call. So by varying your significant digits you are changing when the + will and wont be present. If you take a ten digit number and you add the plus its 11 digits. If you set you SIP trunk to 10 as the significant digits it will get through, if you set it to 11 it wont as the plus will come through and callmanager will drop it. This happens on all version of Callamanger and is not expected to be work until Callamanger 7.0 when direct connect to callmanager to OCs will be supported. The only way to work around this with the OCS RTM code is an intermediate device like an IP-IP GW or some form of back to back PSTN setup.


    OCS -----IPIP GW--------CUCM    or   OCS-------PSTN GW --PSTN GW---------CUCM


    Hope this helps.





    Thursday, August 14, 2008 2:05 PM
  • Hi Paul,


    My view may be subjective (because i represent a gateway vendor :-)), but i did want to make mention that we have quite extensive experience with OCS <> CUCM integration. Trying to get the true integration without an IP to IP gateway is very messy and completely unmanageable (this has been the general consensus from customers i've worked with...)

    The inclusion of the right gateway not only enables the clean intergation between the 2 systems, but it also allows for certain features to be used (i.e. reverse number lookups for calling party numbers, E.164 translations when trunking to and from CUCM, Faxing into Exchange UM, etc etc).


    In case you are interested, the gateway in question is the VX series from N.E.T (www.net.com). We have presence globally, so let me know and i can place you in contact with the right technical resource for a chat.





    Thursday, August 21, 2008 1:08 AM
  • Hi Paul,


    You may be interested in this KB article. It talks about patches that are available for OCS that helps with removing the + for interop to IP-PBX that doesnt support it. This is pretty new and I havent explored the details but this will solve a lot of the problems with trunking from CUCM directly to OCS. Although you will still need MTP resources for your trunk on the CUCM side for proper functionality.






    Thursday, August 21, 2008 5:35 PM
  • Thanks for the info.


    We patched the servers last week but the RemovePlusFromRequestURI configuration file was no where to be found so I am not sure what the patch really did. In the end we created two Normalization rules and routes for 4 digit dialing. One that strips the + going out that matches an accomanying route without a + to the CUCM extensions.  The second Normalization rule and route with the + was formated to accept only OCS extensions allowing the CUCM phones to dial OCS extensions that require a +. 


    This breaks click to dial functionality for 4 digit extensions homed to CUCM as ABS Normalization rules format AD numbers with a + sign in front or they won't appear in the click to dial drop down. But we can dial the number manually in MOC.





    Friday, August 22, 2008 8:24 PM
  • Your not the first person i have seen say they couldnt find the file after they had applied the patch which according to the KB article will need to be changed. I would ask MSFT whats going on there as it sounds like a glitch in their plan.




    Tuesday, August 26, 2008 3:44 PM
  • The documentation is limited in regards to the RemovePlusFromRequestURI.

    Take a look at the post below.  It has updated information on the RemovePlusFromRequestURI file.  Just as a reference, I ended up creating two files both of which contain the same XML information:

    MediationServerSvc.exe.config   and...
    RemovePlusFromRequestURI.xml (I am pretty sure MediationServerSvc.exe.config is the way to go... I was just playing around with the xml file).


    Tuesday, September 9, 2008 8:09 PM