locked
Mediation Server Requirement? RRS feed

  • Question

  •  

    Basic question, but with the ever changing features of current IP-PBXs and OCS, I need to ask this...

     

    I understand when a Mediation server/gateway is required when connecting to TDM PBXs.  However, now that the new 952785 patch has been released, when are Mediation servers required if IP-PBXs support direct SIP connectivity?

     

    Considering that direct SIP Connectivity is being established between a CUCM publisher/subscriber, when is a Mediation server required?

    • In RCC, I'm fairly confident that a Mediation server is not required.
    • In Enterprise Voice with no PBX integration, is a mediation server still required?
    • In Enterprise Voice with PBX integration, is a mediation server still required?

    If we can get away from deploying a Mediation server, than is it accurate to say that route failover can be achieved by add two or more routes per policy which are defined in the Global Voice properties?  Will this actually work without mediation servers in place?

     

    Please don't point me to the Enterprise Voice Deployment guide, because I have read that.  I would just like a straight answer!

     

    Thanks in advance,

    Keenan

     

     

     

    Friday, September 26, 2008 7:16 PM

Answers

  • RCC: Not required

    Enterprise Voice without PBX Integration: Required (Unless you have one of the soon-to-be-released advanced gateways from Audiocodes and the like)

    Enterprise Voice with PBX Integration: It Depends

     

    In the Enterprise Voice with PBX Integration scenario you have two options within Communicator with regard to how you make your calls (New options appear in the UI).

    1. You can initiate the call from your phone. This is RCC and does not require a Mediation Server
    2. You can initiate the call from Communicator. This is Enterprise Voice and does require a Mediation server

    So you can do it either way. If users will be chained to their desk and always near a handset they could always use the phone to initiate calls and so a Mediation Server will never be required. If they are mobile and will log in through an Edge server then they will have no option but to initiate calls through Communicator and so mediation will still be required.

     

    As for route failover, you will need one Mediation server per gateway.

     

    By the way, CUCM 7 recognises the + sign so that hotfix is not necessarily required for version 7. And when you do install the hotfix be aware you also have to go in to the configuration file and disable the +, just installing the hotfix doesn't do this by itself.

    Friday, September 26, 2008 9:34 PM

All replies

  •  

    Direct SIP terminates from an IP PBX at the Mediation server, so it is still a requirement.  The only change that 952785 implemented was removal of the '+' e.164 requirement.

     

    A Mediation server converts standard G711 to Microsoft RTAudio, converts signalling from SIP 5060 or SIP TLS 5061 to MTLS inside the OCS environment and several other things.

     

    RCC does not require a Mediation server.

    Friday, September 26, 2008 7:27 PM
  • Thanks for the quick reply Matt. 

    Hopefully this will clear up others confusion as well, as I have seen references all over the place in the forum!

    Take care!
    Friday, September 26, 2008 7:42 PM
  • RCC: Not required

    Enterprise Voice without PBX Integration: Required (Unless you have one of the soon-to-be-released advanced gateways from Audiocodes and the like)

    Enterprise Voice with PBX Integration: It Depends

     

    In the Enterprise Voice with PBX Integration scenario you have two options within Communicator with regard to how you make your calls (New options appear in the UI).

    1. You can initiate the call from your phone. This is RCC and does not require a Mediation Server
    2. You can initiate the call from Communicator. This is Enterprise Voice and does require a Mediation server

    So you can do it either way. If users will be chained to their desk and always near a handset they could always use the phone to initiate calls and so a Mediation Server will never be required. If they are mobile and will log in through an Edge server then they will have no option but to initiate calls through Communicator and so mediation will still be required.

     

    As for route failover, you will need one Mediation server per gateway.

     

    By the way, CUCM 7 recognises the + sign so that hotfix is not necessarily required for version 7. And when you do install the hotfix be aware you also have to go in to the configuration file and disable the +, just installing the hotfix doesn't do this by itself.

    Friday, September 26, 2008 9:34 PM
  • Simon - Thanks for the explaination.

    As for the Enterprise Voice w/PBX integration, when you mentioned that new options appear,can the user actually select between the two examples you gave above?  This good info... In addtion, am I correct that the
    Enterprise Voice w/PBX integration configuration is not supported with a Cisco IP-PBX solution?  I ask this, because I seem to remember reading this in other posts.

    I am aware that the E.164 standard will be supported in the CUCM 7 release.  I am also aware that CUCM 7.1 is supposed to support dual forking with RCC.  Hopefully it is actually released in 7.1!

    As for your reference on how to disable the '+', the documentation factor is horrible.  I've had the hotfix installed for about a week now and it works like a charm!  Thank goodness for the forums!

    Thanks again!

    Friday, September 26, 2008 10:29 PM
  • Yes the user can change between the modes. New options materialise within Communicator to allow you to choose Phone or Computer as your calling device when PBX integration is enabled.

     

    Enterprise Voice with PBX Integration is just another way of saying RCC with dual-forking. So as of today it's not supported but appears to work fine in any case.

    Saturday, September 27, 2008 2:40 PM
  • Hi Simon,

    Enterprise Voice with PBX Integration definitely does give you the option of using phone or computer to make the call, but I have yet to see it actually work with CCM / CUPS. In production, when you choose "computer" as the preferred calling device, the calls always fail. Only choosing "phone" works, which is essentially just RCC.

     

    Have you seen it work in production where making a PSTN call with the computer as the device actually works? Unless I uncheck the "pbx integration" box, i've never seen it succeed. Although I belive this will change with CCM v 7.

     

    Regards,

    Matt

     

     

    Monday, September 29, 2008 6:08 PM
  •  

    Yes I have it working fine at my current customer. CUCM 6.1.2 and CUPS 6.0.4, with users configured for Enterprise Voice with PBX Integration. PSTN calls are working with either Phone or Computer as the calling device. So far as I know I didn't do anything special to get it working, didn't even realise it was a problem for others.

     

    If we couldn't have got this working then OCS wouldn't have been a good solution as users connected through the Edge server wouldn't have been able to make PSTN calls properly.

     

    I'm happy to share configuration settings etc. to help you get it working. Where should I start looking?

    Monday, September 29, 2008 9:11 PM
  •  

    I'm curious about your connection between UCM and OCS.  Are you using an SBC/IP2IP gateway, T1 back to back or direct sip trunk?

     

    We are using a direct sip trunk which is working great.  The only issue we are currently seeing is between an OC client outside the network receiving a call from Cisco or PSTN (which comes through Cisco).  The issue is currently being looked at by Microsoft as an issue between the mediation server and A/V edge server.  Are you aware of any special firewall rules you had to configure on that part?  Microsoft said we needed to open 60,000 to 64,000 between the mediation server and DMZ A/V edge, but that did not make any difference.

     

    We also had to force all calls going to the SIP trunk's defined device pool/region to g711 even though we have xcoders that can convert.  It would seem that the SIP trunk requires an MTP, and Cisco perhaps cannot assign both an MTP and xcode resource to the same call.

     

    Thanks!

    Matt

    Tuesday, September 30, 2008 1:26 PM
  • Simon,

     

    Can you give us a highlevel overview of your configuration? 

     

    Are you using a direct SIP connection between CUCM and the mediation server (as Matt asked above)?

     

    Thanks,

    Keenan

     

     

     

    Tuesday, October 7, 2008 5:14 PM
  • Hi Matt,

     

    If you look at 6.x documentation it says you can have xcoders and MTPs on the same call. I imagine you would require them to both be in the same media resource list or group allocated to your SIP trunk. The documnet below describes the ability to do both on a single call.

     

    http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_0_1/ccmsys/a05trans.html

     

    Cheers

    Chris

    Wednesday, October 8, 2008 2:57 PM
  • Great link, thank you for sharing.  I see where it says:

     

    Cisco Unified Communications Manager supports MTP and transcoding functionality simultaneously. For example, if a call originates from a Cisco Unified IP Phone (located in the G723 region) to NetMeeting (located in the G711 region), one transcoder resource supports MTP and transcoding functionality simultaneously.

     

    So according to this, a single MTP resource gets enacted to act as both xcode and supplementary services MTP.  That would require a hardware MTP obviously (software MTP cannot xcode) which is not a problem in this case.  I'll have to do more tracing and stats to get to the bottom of that.

     

    What is interesting in this same post, it states that the WS-X6608 can do both MTP and XCode, but does not state this for NM-HDV (pretty old post, don't see anything on newer hardware).  That of course doesn't mean that it cannot perform both simultaneously, but it also doesn't mean that it can.  In this instance, we are using a 2851 with MTP resources.
    Wednesday, October 8, 2008 4:21 PM
  •  

    So this is what I found out.

     

    Older MTP hardware (i.e., NM-HDV and VPDMs) cannot perform both MTP and xcode on the same call. 

     

    I enabled a 2851 with PVDM2-32 as a xcode device and it is performing both MTP and xcode. 

     

    Looks like it will need newer hardware.

     

    How does this pertain to OCS?  Well, if your Cisco deployment is centralized with many remote offices, you don't want calls across your wan coming uncompressed to get to your mediation server.

    Friday, October 10, 2008 7:14 PM
  • Hi Simon,

    Can you tell me what you have

    1) in the OCS users line uri

    2) in call manager, the end user's phone number

    3) in call manager, the DN assigned to the phone

     

    I've found that if I put in +1234 as the line uri, i can log in just fine and make MOC calls, but RCC doesn't work

    If I put in 1234 as the line uri, I can log in and do RCC, but no MOC calls. I figure it's related to the + sign somewhere, but I've tried changing it in various spots w/ no luck. Let me know what you think, thanks!

     

    Regards,

    Matt

     

     

    Monday, October 13, 2008 8:18 PM
  • 1) tel:1234

    2) 1234

    3) Line [1] - 1234 in DTBHAL1_PT

     

    Also the server URI is in the format sip:user@callmanager.domain.com

     

    Everywhere I've read goes on about OCS not working unless you include the + in the line URI but for whatever reason it seems to work fine without it for me. The users four digit extension numbers are populated in AD in the IP phone field(without the plus) and Call Manager uses the LDAP sync to read this field and populate the 'Telephone Number' field.

     

    On the Mediation server I have installed the hotfix and changed the config file that strips the + from outbound calls. Wireshark confirms this bit is working by checking in the SIP request.

     

    On call manager I added the following application dial rules, 441 being the area code:

     

     Name, Description, Number Begins With, Number of Digits, Total Digits to be Removed, Prefix With Pattern
     Strip + ,OCS + Sign Strip, +1441, 12, 1 
     Strip +2, Strip digit rule 2, +, 11, 1, 9011
     Strip +3, Strip rule 3, +, 13, 1, 9011

     

    So with all this together bothh RCC and Enterprise Voice calls are working fine.

    Friday, October 17, 2008 12:42 PM
  • Yes it is a direct SIP trunk, using non-secure SIP trunk profile with blank route pattern and blank partition.

     

    Friday, October 17, 2008 12:45 PM
  • Hi Simon,

    Thanks for the update. I have found that, using the exact same configuration you have, I get the following results:

     

    1) log in - PASS

    2) make PSTN call using "Phone" as preferred device - PASS

    3) make MOC - to MOC calls - PASS

    4) make PSTN call using "Computer" as preferred device - FAIL

     

    As soon as I change the line URI to +1234, I get these results:

    1) log in - PASS

    2) make PSTN call using "Phone" as preferred device - FAIL

    3) make MOC - to MOC calls - PASS

    4) make PSTN call using "Computer" as preferred device - PASS

     

     

    It is very, very odd that you can have a line URI without a plus and make a call with "Computer" selected as the preferred device. I wonder if that's related to the new fixes you've deployed? On the notes for one of them I noticed that it said that OCS now supports "private" numbers. I'll apply the fixes and see. Thanks!

     

    Regards,

    Matt

     

     

     

    Friday, October 17, 2008 3:27 PM
  • This is the Mediation hotfix I'm talking about http://support.microsoft.com/kb/952785/ but a Windows update on all OCS servers should do the trick.

     

    What is the SIP error message when you try to make the PSTN call using Computer? Can you post a network sniff from the Mediation server during the failed call and I will compare it to mine during a success?

     

    On the Mediation server config where you can configure the Gateway and OCS listening addresses have you tried making them both the same address. I found that because I only had a single NIC in the server with two IP addresses bound that this caused PSTN calls to fail. Making both the same address (bad, I know) or installing a second NIC would fix this.

     

    One other thought, do you have the latest Communicator version, 2.0.6362.76

    Friday, October 17, 2008 6:53 PM
  • This patch is not publicly available, you will have to open a ticket with Microsoft to obtain the 952785, 952780 and 952783 patch (all part of this same fix).

     

    952780 installs on the mediation server, 952783 goes on the front end server(s), and 952785 is for communicator.

    Friday, October 17, 2008 7:44 PM
  • I never had to do that. The Mediation server hotfix that strips the + sign appears when you do a Microsoft update.

     

    In any case, there is no need to open a support call, here is the publicly available link:

     

    http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=952785

     

    Just change the kb number to whatever you need and that will access the relevant hotfix. I had to use these links for the new Communicator version and, for some strange reason, to get the Live Meeting adm file.

     

    But like I say, just running Microsoft update on all my OCS servers seems to do the trick.

     

     

    Friday, October 17, 2008 9:41 PM
  • Hey all,

    Originally those hotfixes weren't available to the general public, but you can get them via Windows Update now.

     

    Simon: the errors that I get are not even @ the mediation server, the client doesn't even try to dial the number. This has been standard behavior on the OCS client for a long time: not letting any user without an E164 number make an Enterprise Voice call. The front end server stops it from even happening.

     

    All users with the +E164 have always been able to dial fine every time I've done an integration - it's just if I try to put a user in w/out the + in the tel URI.

     

    I've been putting off those patches for a while since I already had a workaround for the cisco / OCS + sign thing. But maybe I'll do that. Like I said, the "private numbers" thing may be what is now allowing the users to not have a + in the tel URI. I'll let you all know what I find.

     

    Regards,

    Matt

     

     

    Friday, October 17, 2008 9:47 PM
  • Before the patches were released, I was able to enter non E.164 standard Tel URI entries for our test users (i.e. 1234) .  I then had to play with the normalization rules under the location profile.  I basically had it configured to not append a "+".  For example So ^(\d{4})$ --> $1.  After that, I was able to successfully dial out to CUCM.

     

    Simon, even though you have the patches, are you appending the plus in you normalization rules (you should, as this is a best practice)? 

     

    Since the patches have been released, I am fully compliant with E.164 numbers and dialing out.  However, I have not made the switch to Enterprise Voice w/PBX integration.

     

    Matt, if you do apply the patches, let us know how it goes.  I am curious where the "bug" is in this scenario.

     

    Keenan

    Friday, October 17, 2008 9:58 PM
  • I spent many hours fiddling with the OCS normalisation rules, but in the end I decided it was easier to handle this at Call Manager, so now the only normalisation rule I use is a default one that passes everything to CUCM unaltered, exactly as the user enters it in Communicator. So I am not adding a + in OCS rules or at CUCM. On CUCM I have a bunch of rules to add in a 9 or an international access code and handle 911 variations but nothing that adds a +.

     

    I know this is bad karma but it seems to work well. It is just a single site so this cunning tactic would probably fall apart in a larger implementation.

    Friday, October 17, 2008 10:06 PM
  • Hey all,

    I applied the patches & no luck. When I tried to make a "computer" call with tel:4736 as my line uri it failed as usual. The error logs for the OC client showed this:

    Code Snippet

     

    ERROR :: HRESULT failed: 80ee0012 = ((HRESULT)0x80EE0012L). invalid phone context

    INFO  :: Function: TEL_URL::Initialize
    ERROR :: HRESULT API failed: 80ee0012 = ParseTelUri(pszTelUri, ulTelUriLen)
    ERROR :: ParsePAssertedIdHeader unable to parse [tel:4736] as sip/tel uri

     

     

    So it didn't like that I had just tel:4736 as my URI due to the "phone context". With plain old RCC, I was able to specify "phone-context=dialstring", but when you do EV w/ PBX integration you can't specify "phone-context", the OCS gui errors out.

     

    But now I was onto something, so I used ADSIEDIT to manually edit the msRTCline (or something like that) for my user object to read: tel:4736;phone-context=dialstring.

     

    Then I logged out of OC and logged back in. Tried "computer" call & it succeeded! Tried "phone" call and it succeeded too!

     

    So maybe this is a bug in the OCS Console?? Not allowing you to specify the phone-context attribute?

     

    In anycase, I was glad to at least have a workaround.

     

    Regards,

    Matt

     

    Thursday, October 23, 2008 1:46 AM