locked
SIP trunk between OCS and Cisco Unified Communications Manager RRS feed

  • Question

  • Hello everyone,
                          
                           I was wondering if anyone has gotten direct SIP trunking to work between OCS and Cisco Unified Communications Manager (previously known as Call Manager). I am trying this in my lab and  running into some configuration issues. The setup is:
     
    MOC Client User (Extension 4000 specified in AD) ----> OCS Standard Edition server ----> OCS Mediation Server <--- SIP Trunk ---> CUCM ---> IP Phone Extension 7000
     
    Problem we are experiencing: When MOC client dials IP phone extension 7000 , the call fails. In the sniffer captures, I see that it sends the digit string across as +7000. Is there a way to strip the + directly in OCS?

    More details on our configuraton:

    Within the OCS Voice properties

    In the Location profiles tab, we have created a profile with the following:

    Phone pattern regular expression is ^(\d*)$

    Translation pattern regular expression is  +$1


    Under routes tab,  Target regular expression specified is ^\+?\d*$


    Thank you in advance for all help. I have already reviewed the OCS Enterprise Voice planning guide and looked at previous posts on this discussion board.


    Thursday, August 2, 2007 8:33 PM

All replies

  • The CCM doesn't know how to handle the "+",,, so it must be removed ahead ot the CCM.. I would think the Mediation server could remove it,,,if not then I'm sure the Cisco IPIP gw can strip it out...Not the ideal way,,,but it will work

    Thursday, August 2, 2007 11:32 PM
  • Try it without the "+" in your translation pattern. The translation pattern should then look like this $1.

     

    Friday, August 3, 2007 10:33 AM
  • I have everything set up according the OCS docs and the Cisco CUPS docs.  The only thing i'm missing is the ability to use TLS between the two servers.  I am not able to get the Root CA from the cups server and therefore cannot add it to the trusted list of CA's on the OCS server. 

     

    However, when i run the connection over TCP it is fine.  I am not worried about encryption right now.  When i open my MOC client, i get the error:

     

    No Phone System Connection.

     

    I can't figure out why.

     

    Please help!

    Friday, August 10, 2007 12:13 AM
  • First check is to run the troubleshooter in CUP,,, Make sure all the expected items are green checks..

     

    Obviously, correct those failed items..

     

    Check the domain of the proxy within cups.. Must match the domain on the defined users for the telephony integration.

     

    Need to know if all the clients have the same error or if one or two come up without the error..

     

    Don't forget to make sure that the user profile in the A/D has the Communications checked and then move over to advanced and make sure the domain in the URI is the same as your proxy setting above...

     

    Are you having to use a + before the number to enable the MOC to display the contact info?... Which version of OCS did you install?

    Friday, August 10, 2007 1:34 AM
  • First, CUPS is used with OCS for third party call control of a Cisco IP phone. This does not give you the ability to make a phone call directly from a MOC client and any configuration in CUPS will not effect this function.

     

    Second:

    The $1 may not work in the RTM version of OCS and you may require the use of an IP - IP GW with anything beyond beta when talking to a Callmanager Cluster to get around the E164 issue of the + sign.  If any one needs a sample config of a IOS IP-IP GW please let me know and I will post.

     

    Cheers

    Chris

     

    Friday, August 10, 2007 3:14 PM
  • Yes, I need it badly. Would you post it please?

    Saturday, September 8, 2007 7:06 AM
  • Hi,

     

    Here is a configuration for an IOS IP-IP GW to be able to integrate to CallManager 5.1 using SIP and to CallManager 4.2.3 using H323, (this could also be a SIP connection but Cisco's cut at SIP in 4.2.3 may cause issues). 12.4.9T4 IOS IP-IP GW feature set is required for this configuration.

     

    voice service voip

     media flow-around

     allow-connections h323 to sip

     allow-connections sip to h323

     allow-connections sip to sip

     redirect ip2ip

     h323

      h225 timeout setup 20

      h245 tunnel disable

      h245 caps mode restricted

     sip

       rel1xx supported "rel100"

    !

    dial-peer voice 900 voip

     description  outbound to CCM5.1

     destination-pattern +T

     session protocol sipv2

     session target ipv4:192.192.19.19

     session transport tcp

     dtmf-relay sip-kpml

     codec g711ulaw

     no vad

    !

    dial-peer voice 65120 voip

    description outbound to OCS

     destination-pattern 142578851[23].

     session protocol sipv2

     session target ipv4:192.192.19.17

     session transport tcp

     dtmf-relay sip-kpml

     codec g711ulaw

     no vad

    !

    !

    dial-peer voice 902 voip

     description outbound to CCM 4.2(3) H323

     preference 1

     destination-pattern +T

     session target ipv4:192.192.192.22

     dtmf-relay h245-alphanumeric

     codec g711ulaw

     no vad

    !

    !
    dial-peer voice 101 voip
     description inbound dial peer
     session protocol sipv2
     session transport tcp
     incoming called-number .
     dtmf-relay rtp-nte digit-drop
     codec g711ulaw
     no vad
    !
    gateway

     

    Ensure IP routing is also enabled.

    Let em know if you have any problems.

    Cheers

    Chris

     

    Monday, September 10, 2007 2:52 AM
  • Hi,

     

    In OCS RTM version you have to normalized your telephone number on AD using E.164 format. If you don't do it, you can not see the associeted phone number over any OC's contact.

     

    E.164 format put the "+" before the telephone number.

     

    If you want to make a call from OC (RTM version) by CCM using E.164 format number you have to put something between OCS Medition Server and CCM 5.0 to translate the number without +

     

    I'm looking for a Cisco's documents that confirm me it doesn't support "+" telephone numbers and what I have to do to send an E.164 telephone number format to CCM 5.0. Any one have something like this?

     

    Monday, September 17, 2007 9:50 PM
  • Hi...

     

    You can take this to the bank,,,

     

    Cisco CUCM will not support the + in an E.164 number...The only place where that can be stripped off is in the Application dial rules, which is for things like CTI gateway control (CUP) ..This is true up to and including the 6.xx loads

     

    Monday, September 17, 2007 10:10 PM
  •  

    Hi,

     

    for stripping of the '+'-sign, you can place an openser between the mediation and cisco uc manager.

    Reg,

    Dieter

    Tuesday, September 18, 2007 11:13 AM
  • Hi,

     

    Cisco  Callmanager does not currently support E164 number format and there for will not support the Plus +. My previous post in this thread is a work around to this problem. The IP-IP GW using a Cisco router will support the + and be able to forward the call to the callmanager in a format that callmanager will accept. Until Cisco Callmanager supports E164 number format you can could also try differnet translation formats although this may or may not work. The IP-IP GW will work for certain though.

     

    Cheers

    Chris

     

     

     

    Wednesday, September 19, 2007 10:01 PM
  • Hi all,

    There is a very simple way to strip off the + in CallManager:

     

    On your SIP trunk between callmanager and OCS, go to the inbound routing section. You will see a box that says "significant digits". If you put 10 there, it takes the right-most 10 digits of the outgoing call, leaving the plus sign out. So, +1312-555-1212 becomes 312-555-1212. If this is supposed to route to the PSTN (which apparently it is) then you would also need to fill in a "9" or something in the "Prefix DN" field in your SIP trunk.

     

    It took me a while to figure this out. I was playing with normalization rules & what not for a long time. Then I decided to just strip it in CallManager - it turned out to be the easiest thing by far.

     

    I have this working no problems at all with OCS RTM and call manager 5.1.

     

    One thing to note: this will allow OCS to call +1XXXXXXXX numbers that are destined for the PSTN. If you want to be able to send calls over to CallManager to ring people's 4-digit extension, that's a different trick.

     

    There's a fair amount to it, but essentially, you would need to use a normalization rule in OCS to prepend a routing code to 4 digit numbers, like adding 88 to a 4-digit number to make it 88-1212. Then you would need to create a translation pattern in callmanager that strips the 88 and sends the call on to the 4-digit number. You'd need to make sure that the SIP trunk has that translation in its calling search space.

     

    Hope this helps.

     

    Regards,

    Matt

     

     

    Wednesday, September 19, 2007 10:12 PM
  • If you want to strip the + or rather never add a + in the OCS, make a route in the Voice properties looking like this:

    ^\d*$

     

    and the OCS wont add a + to the number. The general route usually includes a +.    ^\+(\d*)$

     

    It might be that you want to handle "internal calls" in the Cisco different than calls out of the Cisco from OCS. Make a rule in the location profile for internal calls (outside OCS inside Cisco)

    In my case with 5-digit extensions

    ^(\d{5})$

    $1

     

     

    Remeber to sign-out the communicator and sign-in before you try new rules.

     

    Regards

    /Torbjörn

    Thursday, September 20, 2007 9:04 AM
  • Hi,

     

    This may also cause problems with calling 911 which is less than ten digits and international calls which is greater than 11. 911 calling is sometimes forgotten in these situations but should always be at the for front of any dialing plan (unless of course you want a law suit on your hands). 911 in our OCS dial plan would not move out to our Callmanager infustructure without the + sign.

     

    What would be better is that Cisco Callmanager actually supported the plus sign and these work arounds werent required. If you have access to Cisco SE or account manager this is a question I would be putting to them to get this into the next release of Callmanager.

     

    Cheers

    Chris

     

    Thursday, September 20, 2007 2:17 PM
  • Hello everybody,

    we are interested in this kind of integration of OCS with CUCM, using SIP trunking.
    Anyone available to share his/her considerations about the results?

    Any major issues or relevant constraints?

    Are all OCS functions and services interworking properly in your scenarios?

    I mean hold, trasfer, deflect, conf. call, forking... do they work good between MOC users
    and Cisco IP Phone users?

     

    No way to integrate Presence and IM in this way, correct?

     

    Thanks

    Marc

    Thursday, September 20, 2007 3:12 PM
  • Hi,

    I totally agree the ultimate fix is for CallManager to support E.164 with the +. And I also agree that using significant digits to strip the + doesn't work in all cases.

     

    However -  if you just want to be able to pass most PSTN calls to CallManager, it does work. International calls don't but, but all the rest I've been able to get working, even 911.

     

    And another poster pointed out that you can use a normalization rule that never adds a + to numbers: this works well when users are entering in a new number to call. But - if you are trying to click on a contact in your contact list, the ABS service will have already converted their numbers to the +1 format.

     

    So even if you have a normalization rule that doesn't add the +, you still need to strip it out in CCM for those auto-normalized numbers.

     

    Bottom line - Cisco: please accept the +!!

     

    Regards,

    Matt

     

     

     

    Thursday, September 20, 2007 6:48 PM
  • Hi Matt,

     

    Good post. You are right about that a straight trunk connection will accept most calls not all due to accepting only 10 digits to remove the +. At the moment I am working on using translation patterns in an IP-IP GW so that all calls will go through to Callmanager with out the +. This is what we are planning to deploy with at the company I work at. So it works in two ways in that it will have the MTP's on the same router as the IP-IP GW to remove the plus. The other problem I have found is that Mediation server can only accept one IP address for the PSTN gateway. Not so great when you have 8 callmanager subscribers deployed. Kinda limits redundancy even if you deploy a second Mediation server. With IP-IP GW you can at least have multiple dial-peers to go to more of your subscribers.

     

    Just a quick question though are you using RTM code?

     

    Cheers

    Chris

     

    Thursday, September 20, 2007 8:27 PM
  • Hi Chris,

    Yep - using RTM code. Very good point about the redundancy with the dial peers. I think your's is the only good solution right now: strips the + and provides redundancy all at once.

     

    Regards,

    Matt

    Friday, September 21, 2007 7:05 PM
  • Hi Matt,

     

    So myy last post I talked about working on translation patterns (well its really translation rules and profiles in an Cisco router for this purpose). Here is the config I got to work:

     

    !
    voice translation-rule 101
     rule 1 /^\+1\(..........\)/ /\1/
     rule 2 /^\+1011\(.*\)/ /011\1/
     rule 3 /^\+\(911\)/ /\1/
    !
    !
    voice translation-profile 101
     translate called 101
    !
    Then apply the profile on an outbound dial peer pointing at your callmanagers. This will strip the +1 or + from your outbound called numbers. Just apply this logic to any set of digits that have the + you need to remove it from. I have tried and tested this configuration with 5.x sip trunk and 4.2(3) h323 gateway configurations. You could also apply these translations on inbound dial peers as well.

     

    Cheers

    Chris

    Friday, September 21, 2007 10:14 PM
  • Hi,

     

    I got the SIP Trunk working with the CM and OCS. The only problem that i have now is to get external incoming call to reach OCS extension. The incoming call will drop everytime it reach the OCS extension. I dont have this problem for incoming call from CM extension.

     

    Anyone can help me to get this working? Thanks.

    Monday, October 8, 2007 9:46 AM
  • Hi Lee,

     

    It sounds like you have the basic setup right. Couple of things to check. Does the call ever reach the SIP trunk to OCS. If you look in the OCS log do you see the incoming call and OCS rejecting it. This may tell you if you have miss configured the tel uri or that the incoming called number to OCS  doesn’t match the dial string you have configured in the tel uri. So for instance in Callmanager you have the full ten digits routing to OCS and in the tel uri you have only the 6 digit extension configured. Stuff like that.

     

    When you say external incoming call are you refering to the PSTN or Callmanager extension to OCS because later you say you dont have a problem for incoming call from CM ext. So I am a bit confused there.

     

    Chris

     

    Monday, October 8, 2007 3:49 PM
  •  

    Hi Chris,

     

    I didn't see any log on the OCS server when the call is drop. Are you refering to the Communicator Log? I have my tel uri as +60377128070. CM will only send 8070 to OCS Ext. I dont have any issue for OCS Calling to OCS, OCS calling to PSTN, OCS Calling to CM and CM Calling to OCS. Only problem is from PSTN calling to OCS.

     

    Lee

    Tuesday, October 9, 2007 6:43 AM
  • Hi Lee,

     

    This realy sounds like a Callmanager routing problem since everything else works. If you are routing from the PSTN through Callmanager to OCS I would check the in bound calling search space on the PSTN gateway in Callmanager and ensure it has the partition from the OCS route pattern is in the CSS. If this is a direct connect of a PSTN gateway to a mediation server maybe installing wireshark on your mediation server to see if you are recieving inbound packets from you gateway could be a good start.

     

    Cheers

    Chris

     

    Tuesday, October 9, 2007 4:11 PM
  • Hi Chris,

     

    I'm trying to get my IP-IP Gateway running but I have still problems. Do you have a complete config of an IP-IP GW you can provide?

     

    Thanks,

    Regards,

    Mike

     

    Monday, March 3, 2008 2:34 PM
  •  

    Hi Mike,

     

    Here is a copy of an IP -IP GW configuration setup to be the MTP for you callmanager cluster as well. I would recomend that you use the IP-IP GW as the MTP  as the RTP has to flow through the IP-IP GW anyway and you will need an MTP if you plan on talking to Cisco endpoint that are anything other then SIP endpoints. I have some translation patterns here that represent the split area codes in Seattle so dont let that confuse you. You may or maynot need to have this for your free area calling codes. Also I have included the dail peers so you can do H323 GW to a callmanager 4.2.3 (mtp required on gateway setting in CCM) cluster or SIP trunk to a Callmaanger 6.1(uncheck MTP required in CCM trunk setting). We are using a normalisation rule for 911 to 0911 to avoid number pattern conflicts in OCS with E164 so that may seem odd also. Let me know if you have any questions. There are also mutiple dail peers to for the same destination pattern to go to different subscribers to have a little redundancy. Using the preference command to form a hunt group you can set which callmanager subscriber you want the call to go to in order.

     

     

    !
    voice-card 0
     dspfarm
     dsp services dspfarm
    !
    !
    !
    voice service voip
     allow-connections h323 to sip
     allow-connections sip to h323
     allow-connections sip to sip
     supplementary-service h450.12
     
    !
    !
    !
    !
    voice translation-rule 101
     rule 1 /^\+1\(425.......\)/ /\1/
     rule 2 /^\+1\(206.......\)/ /\1/
     rule 3 /^\+1\(360.......\)/ /\1/
     rule 4 /^\+\(425.......\)/ /\1/
     rule 5 /^\+\(206.......\)/ /\1/
     rule 6 /^\+\(360.......\)/ /\1/
     rule 7 /^\+1\(253.......\)/ /\1/
     rule 8 /^\+\(253.......\)/ /\1/
     rule 9 /^\+1\(..........\)/ /1\1/
     rule 10 /^\+0\(911\)/ /\1/
     rule 11 /^\+\(.*\)/ /011\1/
    !
    !
    voice translation-rule 103
     rule 1 /^\(206.......\)/ /+\1/
     rule 2 /^\([2-9].........\)/ /+1\1/
     rule 3 /^\(...........\)/ /+\1/
    !
    !
    voice translation-profile 101
     translate called 101
    !
    voice translation-profile 103
     translate calling 103
    !
    !
    !
    sccp local FastEthernet0/0
    sccp ccm XX.XX.XX.XX identifier 1 version 5.0.1
    sccp ccm XX.XX.XX.XX identifier 2 version 5.0.1
    sccp
    !

    !
    sccp ccm group 1
     description SCCP CCM group
     bind interface FastEthernet0/0
     associate ccm 1 priority 1
     associate ccm 2 priority 2
     associate profile 101 register MTPXXXXXXXXXXXX
    !
    dspfarm profile 101 mtp
     codec g711ulaw
     maximum sessions software 200
     associate application SCCP
    !
    !
    !
    dial-peer voice 99999 voip
     description to OCS mediation server
     translation-profile outgoing 103
     destination-pattern 1425........
     session protocol sipv2
     session target ipv4:XX.XX.XX.XX
     session transport tcp
     dtmf-relay rtp-nte
     codec g711ulaw
    !

    !
    dial-peer voice 902 voip

    Description to callmanager 4.2.3 cluster
     translation-profile outgoing 101
     preference 4
     destination-pattern +T
     session target ipv4:XX.XX.XX.XX

     dtmf-relay h245-alphanumeric
     codec g711ulaw
     no vad
    !

    dial-peer voice 101 voip
     description to Callmanager 6.1 route 1
     translation-profile outgoing 101
     preference 1
     destination-pattern +T
     session protocol sipv2
     session target ipv4:XX.XX.XX.XX
     session transport tcp
     dtmf-relay rtp-nte sip-notify
     codec g711ulaw
     no vad
    !
    dial-peer voice 102 voip
     description to Callmanager 6.1 route 2
     translation-profile outgoing 101
     preference 2
     destination-pattern +T
     session protocol sipv2
     session target ipv4:XX.XX.XX.XX
     session transport tcp
     dtmf-relay rtp-nte sip-notify
     codec g711ulaw
     no vad
    !
    dial-peer voice 911 voip
     description to Callmanager 6.1 route 1
     translation-profile outgoing 101
     preference 1
     destination-pattern +0911
     session protocol sipv2
     session target ipv4:XX.XX.XX.XX
     session transport tcp
     dtmf-relay rtp-nte sip-notify
     codec g711ulaw
     no vad
    !
    dial-peer voice 912 voip
     description to Callmanager 6.1 route 2
     translation-profile outgoing 101
     preference 2
     destination-pattern +0911
     session protocol sipv2
     session target ipv4:XX.XX.XX.XX
     session transport tcp
     dtmf-relay rtp-nte sip-notify
     codec g711ulaw
     no vad
    !
    dial-peer voice 101 voip
     description inbound
     preference 1
     session protocol sipv2
     incoming called-number .
     dtmf-relay rtp-nte
     codec g711ulaw
    !
    !

    Good luck.

    Cheers

    Chris

    Monday, March 3, 2008 5:24 PM
  • This thread has been extremely useful, but I still can't make a call from OCS -> CallManager 5.1.  I can make calls from CallManager to OCS without issue, however.  When calling a CallManager DN (for instance, +2730), I receive a 404 error from MOC.  My router translation rules and dial-peers duplicate much of what I've read directly above (and have been tested for accuracy) and my CallManager SIP trunk is configured with all defaults.  I have no Presence server involved.  My mediation server route regex is ^\+(\d*)$ and the normalization phone pattern is ^(\d{4})$ with translation to +$1.  Is there something simple I'm overlooking?  If you need more details of my configuration, I can certainly provide them.

     

    Thank you!

           Chris

    Thursday, March 6, 2008 10:49 PM
  •  

    Hi VoIPnom

     

    You had already integrated CCM 6.0 and OCS 2007 successfully. Can you tell me how to do that?

    I am also connecting CCM 6.0 to OCS 2007. My topo is:

    IPPhone---CCM 6.0---RouterGW2811---Mediation Server---OCS2007-MOC.

    IP Phone can call to MOC and the call is ok. But when MOC call to IP Phone, IP Phone is ring, I press answer button in IP Phone, MOC is still calling status. The call is not happening.

     

    I don't know why . Please help me.

    Thank


    Wednesday, March 19, 2008 7:50 AM
  • You can set the # of significant digits to 4 in the CUCM trunk config and that will strip the "+"...This does work pretty well all things considered..

     

    Thursday, March 20, 2008 4:19 AM
  • I want to try to address a few of the problems people are having and try to help.

    Hi Rollcage & Inhaho,

    The rules and everything I have above is designed for ten digit dial and unless you have the correct normalization rule to normalize your 4 digit extension into 10 digit appending +1 to it doesn’t do anything and you’re probably sending CM a number pattern it can’t match to anything. Unless your in the Seattle area I wouldn’t copy exactly what I have above, removing +1 from calls going to CCM should be for local free call area codes and removing just the +  for LD. The fact that inbound works from call manager proves that you have issue with call routing rules and normalization. Its okay to have four digit extension but you will need to do three things. Build the right normalization rule in OCS and build the correct dial peers and translations in the ip-ip gw to CallManager. What I would recommend is to make OCS pass +2XXX using ^(2\d{3})$ normalize with +$1 then at the IP-IP GW remove the + with a translation rule like: “ rule 4 /^\+\(2...\)/ /\1/” to remove the + from your 4 digit extension.  Hope this helps. You can check at the ip-ip gw to see what digits you are passing using the command Debug ccsip message. This can help you see what you are passing. Also on the SIP trunk in Callmanager ensure you have the correct Calling search space on the inbound routing to ensure the trunk will accept the incoming calls to either a phone on CCM or if the call is just tandeming through CallManager to the PSTN. Voice routing can certainly be difficult to understand if you are new to it.

    Hi Voretl,

    Yes this is fine as long as users don’t try to call 911, LD, Local, international or any other number that doesn’t fit the 4 digit extension profile basically making OCS a nice intercom. Not what I think these guys are after and certainly with a bit of effort much more can be done than just abbreviated dialing.

    Cheers

    Chris

     

    Thursday, March 20, 2008 3:31 PM
  • VoIPnorm,

    Thanks for your advice of turning on debugging, it quickly helped me realize that my outbound to CallManager dial-peer had issues.  Turns out my configured destination pattern of +T was the issue.  I switched it to "2..." and wala!, immediate success.  For others out there, I'll include pertinent parts of my router config below.  My configured user line uri's are "tel:+25**" (where ** are digits matching the rest of the given phone number).  My CallManager phones are all 2[0-4,6-9]** numbers.  My mediation server route regex is ^\+(\d*)$ and the normalization phone pattern is ^(\d{4})$ with translation to +$1.  My CallManager SIP trunk has no special configuration beyond basic defaults.  I have no CallManager Call Search Spaces configured in this lab environment.

     

     

    voice translation-rule 101
     rule 1 /^\+\(.*\)/ /\1/
    !
    voice translation-rule 103
     rule 1 /^\(.*\)/ /+\1/
    !
    voice translation-profile 101
     translate called 101
    !
    voice translation-profile 103
     translate calling 103

    !

    dial-peer voice 900 voip
     description outbound to CCM5.1
     translation-profile outgoing 101
     destination-pattern 2...
     session protocol sipv2
     session target ipv4:XX.XX.XX.XX (CallManager IP)
     session transport tcp
     dtmf-relay rtp-nte sip-notify
     codec g711ulaw
     no vad
    !
    dial-peer voice 2500 voip
     description outbound to OCS
     translation-profile outgoing 103
     destination-pattern 25..
     session protocol sipv2
     session target ipv4:XX.XX.XX.XX (OCS listening address for gateway traffic)
     session transport tcp
     dtmf-relay rtp-nte
     codec g711ulaw

     

     

    Thursday, March 20, 2008 6:08 PM
  • Hi Rollcage,

     

    glad to help you out. Having the router act as an MTP for your setup will also work well and is something you will need for DTMF tones when dialing into a conference bridge and having to dial a pin to enter your conference or for telephone banking etc. Let me know if you need more help setting up for 10 digit dialing or international etc for your OCS users.

     

    Cheers

    Chris

    Thursday, March 20, 2008 8:10 PM
  •  mann81 wrote:

    I have everything set up according the OCS docs and the Cisco CUPS docs.  The only thing i'm missing is the ability to use TLS between the two servers.  I am not able to get the Root CA from the cups server and therefore cannot add it to the trusted list of CA's on the OCS server. 

     

    However, when i run the connection over TCP it is fine.  I am not worried about encryption right now.  When i open my MOC client, i get the error:

     

    No Phone System Connection.

     

    I can't figure out why.

     

    Please help!



    Mann81, can you please tell me, which are "OCS docs and the Cisco CUPS docs"? Where Can I get them?
    Tuesday, April 8, 2008 2:18 PM
  • Hi Norm, can you tell me whether you were able to get RTP to flow in both directions when making calls in both directions?

     

    What I am seeing is that I can make a call from OCS endpoint to Cisco enpoint and get media.  If I call from Cisco to OCS it looks like there is a connection on the devices, but you don't here each other...

     

    I have session transport set to TCP, should I see from an Ethereal trace that the RTP is TCP based and not UDP, because I am seeing UDP for both call types.

     

    I have CUCM6.1 and connecting to a mediation server that is running in a VMWare image.

     

    Thanks in advance - Mike

    Wednesday, April 9, 2008 9:31 AM
  • Hi Mike,

     

    You will probably need to give me a bit more info on your set up. If I was to guess at your problem, and this is a guess with the little info you have provided, that you may have not configured MTP resources in callmanager for your SIP trunk. Like I said it was just a guess. I always recommend a IOS based resource for this as the callmanager software MTP can cause voice quality issues. There are a couple of things you can do to find out whether media is getting to the mediation gateway using a network sniffer on the mediation. Also you can enable logging on the mediation server to check the SIP call flow and RTP flows using the OCS logging tool using the MMC on the mediation server. Hope this helps. Let me know a bit more about your config and I may be able to help some more.

     

    Cheers

    Chris

    Thursday, April 10, 2008 4:01 AM
  •  

    Hi Chris, thanks for the reply.

     

    What we have in our lab is CUCM 6.1 ---> IPIPGW (SIP Trunk) ----> OCS Mediation server.  The CUCM SIP trunk has MTP turned on, and the MRG that has MTP resources derived from the IPIPGW (Cisco 2811) assigned to the MRGL.

     

    I place a call between the OCS endpoint to the Csico IP endpoint (7970G), and it works fine.  If I place the call from the Cisco to the OCS endpoint I can see that media flows between the endpints (Ethereal trace) and the mediation server, but there is no audio presented to the handset (dead-air).

     

    I have tried using media flow through, flow around, changing codecs, etc... without any luck.  I'm also a little confused with the media between endpoints and Mediation server being UDP.  I thought the Microsoft codec used TCP based media transport???

     

    I can attached my IPIPGW config if it helps???

     

    Ta - Mike

    Tuesday, April 15, 2008 3:15 AM
  • Hi Mike,

     

    THis is an interesting situation that it works one way and not the other. If you can see the media reach the IP-IP GW and then on to the mediation server it sounds more like a OCS issue you may have. You may want ot turn logging on at the mediation server and the client as a starting point. Microsoft have released a voip troubleshooting guide that may help as well. For SIP trunk to CUCM you can do flow around but the media is going to pass through the IP-IP GW regardless since you have the MTP resources there. You want the dial peers to OCS to look like the following:

     

    dial-peer voice XXXX voip

    description to OCS mediation server

     translation-profile outgoing XXX

     destination-pattern 555.......

     session protocol sipv2

     session target ipv4:X.X.X.X

     session transport tcp

     dtmf-relay rtp-nte

     codec g711ulaw

    !

    UDP for RTP is fine. TCP is used for SIP in OCS which isnt always the case for other vendors like Cisco. THey can support UDP or TCP for SIP. RTP uses UDP due to the real time nature of the protocol as it cant afford to wait for retransmissions, error correction etc that TCP uses.

    Not sure if this a problem with your IP-IP GW but you can post it if you want to. I have seen a no audio problem with firmware for the tanjay so if that is the device you test with you may want to upgrade the firmware or use MOC to test with. Hope this info helps. The IP-IP GW setup is usually pretty straight forward and if you havent rebooted the IP-IPGW since first configuration I would also do that as they can act odd when configured for the first time till after reboot. Link to the OCS VoIP trouble shooting guide is below:

     

    http://www.microsoft.com/downloads/details.aspx?FamilyID=7b490758-ef9a-4442-9f0f-a5aeb4935c46&displaylang=en

     

    Cheers

    Chris

    PS post back and let me know how you go.

    Tuesday, April 15, 2008 6:40 AM
  • Hi to those that have read this thread,

     

    I have been working on the configuration of IP-IP GW for interop of Cisco Callmanager to OCS for some time now thought I would just update some issues that have been discovered through the testing and pilot activity.

     

    Simultaneous ringing and call forward all

    IP-IP GW currently does not support 183 Session progression messages with no SDP or the use of the 181 “call is being forwarded”. This has the following effects:

    Simultaneous ring when no logged onto MOC – No ring back on the calling end, calls may prematurely end due to a failure for the PSTN receive session progression messages dropped by the IP-IP GW

    Call forward all- due to no support for 181 and 183 session progression messages on the IP-IP GW call forwarded calls may fail due to the PSTN gateway interface not receiving notification of a session progress.

    This problem may also occur using ISR as a T1 gateway. There is a workaround but I am not able to release the details. Please talk with your local MSFT representivite whether the workaround is suitable for your deployment.

    IOS routing behavior changes in 12.4(15xz) compared to 12.4(9t6)

    IOS changes on inbound routing of the (+) sign may require changes to the configuration stated in this document. Later IOS version beyond 12.4(9t6) no longer require the use of inbound translation rules to remove the (+) sign and it is removed by default. This change in behavior will still require the use of translation rules to append the (+) sign on inbound calls to OCS for number name resolution in the address book if the address book has been normalized.

    Example dial peer for 12.4(15xz). Translation profile can be used to remove or add digits depending on the desired inbound requirement of CUCM

    !

    dial-peer voice 905 voip

     description to Callmanager

    destination-pattern 1[2-9]..[2-9]......

     session protocol sipv2

     session target ipv4:X.X.X.X

     session transport tcp

     dtmf-relay rtp-nte sip-notify

     codec g711ulaw

     no vad

    !

     

     12.4(9t6) and earlier

    !

    dial-peer voice 901 voip

     description to Callmanager

     translation-profile outgoing 101

    destination-pattern +T

     session protocol sipv2

     session target ipv4:X.X.X.X

     session transport tcp

     dtmf-relay h245-alphanumeric

     codec g711ulaw

     no vad

    IOS 12.4(15xz)

    Versions of Cisco IOS before 12.4(15xz) do not support re-invite messages from Callmanager or OCS and will drop calls when the re-invite is issued. The use of the command “midcall-signaling passthru” overcomes this limitation and is only available in 12.4(15xz) and beyond.

    Option-ping command available in the 12.4(15xz) removes the need to extend TCP session timers by refreshing sessions before they reach the default 5 minute expire time. If the TCP timer expires mid call signaling (e.g. on-hold) may cause calls to be prematurely terminated by the IP-IP GW. For IOS earlier the following commands allow the extension of TCP timer beyond the default of 5 minutes.

    sip-ua

     timers connection aging 30

    Hope this information helps anyone testing with the IP-IP GW configuration.

     

    Cheers

    Chris

    Saturday, June 28, 2008 8:34 PM
  • Hi, thanks for the info. I was a bit puzzled when I first started debugging the translations to find that the + character was handled difrerently.

     

    I also have an other issue though, The IOS gateway I am using is not MGCP controlled and I wondering how I should be configuring this environment.

     

    I am currently testing on my home lab with a 1760 and have a wierd problem. When I uncheck "MTP required" on the trunk profile in CCM, the calls to OCS always fail due to the "content-length" header being removed from the INVITE from the IOS gateway to the medation server. Maybe his is a bug on the base 1760 code I dunno, I will have to test on a 28xx with ip2ip gw code. The mediation server won't accept an invite from the gateway without a valid "content-length" header. it is sent by CCM to the gateway (With a value of 0) but it being stripped by the GW for the 2nd INVITE.

     

    When CCM has "MTP required" unchecked, it goes like this

    - CCM sends INVITE (Without SDP) to IOS GW which includes "content-length:0"

    - IOS GW sends INVITE (Without SDP) to OCS Mediation server WITHOUT "content-length" header

    - Mediation server rejects connection due to missing content-length header value.

    - me sad :-(

     

    Maybe a bug ?

     

     

    Anyway, I guess my question is as follows...

     

    What would you think is the recommended configuration for CCM -> IOS GW -> OCS Mediation Server when using a non MGCP controlled gateway and not using the CCM MTP (ie. MTP required unchecked for trunk)

     

    cheers

     

    Mark

    Monday, August 18, 2008 12:42 AM
  • Hi Mark,

     

    This is not an issue I have come across before and was very suprised to read it. Depending on the callmanager version some things can work better than others. For CCM 4.2.3 configuring the link to the IP-IP GW as a H323 GW with MTP required. For CCM 5.x and 6.x configured as a SIP trunk with mtp required is not nessacary but MTP resources will still need to be available for the trunk as any communicatiosn with a non SIP device will require it (such as a H323 GW or a skinny phone). This is done through using the correct media resources list that has IOS MTPs available. I would recommend congifuring the MTP resources on the IP-IP GW it self in software as follows:

     

    !
    sccp local FastEthernet0/0
    sccp ccm X.X.X.X identifier 2 version 4.1
    sccp ccm X.X.X.X identifier 1 version 4.1
    sccp
    !
    sccp ccm group 1
     description SCCP CCM group
     bind interface FastEthernet0/0
     associate ccm 1 priority 1
     associate ccm 2 priority 2
     associate profile 102 register MTP_4.2.3

    !
    dspfarm profile 102 mtp
     codec g711ulaw
     maximum sessions software 100 ( this number can vary depending on router size. of 1760 probably 20 would work)
     associate application SCCP

    I would also recommend using the following IOS version 12.4.15xz1 or 12.4.20t. I have never tried it on a 1760 but this does work on a 2811. No DSP hardware resources are required on the gateway as the MTPs are using the cpu of the router to get the job done.

     

    Hope this helps.

     

    Cheers

    Chris

    Monday, August 18, 2008 1:07 AM
  • Hi Chris, thanks again. In my case, I wanted to keep the configurations completely separate and not involve the Call manager at all if possible (Apart from routing the call down the trunk of course)

     

    Is there a way to have a gateway based MTP but not registered to CCM that would still support what we are doing ?

     

    Would it be fair to say that no matter what I try and do, I need to enable the "MTP required" option in the trunk config of CCM. Is there a way for the gateway as assign the MTP when the INVITE passes through it to the next hop 

     

    Apart from that, I think my real problem is the the stripping of the content-length on the second leg as a call first to the mediation server from CCM works fine. Might need to raise a TAC case for it.

     

    cheers

     

    Mark

    Monday, August 18, 2008 2:17 AM
  • Hi Mark,

     

    I dont think there is any way around having MTPs registered to the callmanager. Its just the way callmanager works as the MTP provides help with transfer, hold and SIP DTMF. Like I said in my previous post for versions 5.x and 6.x you do not need to have the MTP required selected but you do need to have MTP resources registered and available for the SIP trunk for communication to skinny phones and any gateway that isnt using SIP. CCM 5.x and 6.x will decide if they need a MTP for a particular session without it being required. If you are using CCM 4.x MTP required is mandatory. I think if you raise a tac case they may record it as a bug but more than likely they will tell you, you need MTPs. I have never done this configuration without them and at the moment I am supporting a 300 user pilot with enterprise voice and its working just fine with MTPs configured on the IP-IP GW.

     

    Good luck with your configuration, hope you get the answer your looking for.

     

    Cheers

    Chris

     

    Monday, August 18, 2008 2:27 AM
  • So for those interested in doing a SIP trunk directly from Callmanager to OCS this may be of interest. The following KB article describes the new mediation server patches that remove the the + sign from outbound calls to IP-PBX that doesnt support it:

     

    http://support.microsoft.com/kb/952785

     

    Good luck with your configs.

     

    Cheers

    Chris

    SYMPTOMS

    By default, Microsoft Office Communications Server 2007 Mediation Server uses a plus sign (+) to prefix E.164 numbers in the Request Uniform Resource Identifier (URI) for outgoing calls. However, certain private branch exchanges (PBXs) do not accept numbers that are prefixed by using a plus sign (+). Therefore, an outgoing call may not be routed correctly. Additionally, the "From" headers for incoming calls from certain PBXs do not comply with Requests for Comments (RFC) 3966, "The tel URI for Telephone Numbers." In this case, Office Communicator does not resolve the number to the correct user.
     

    RESOLUTION

    To resolve this issue, follow these steps:
    1. Install the update package for Communications Server 2007 Mediation Server that is dated August 2008. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
    952780 (http://support.microsoft.com/kb/952780/) Description of the update package for Communications Server 2007 Mediation Server: August 2008
    2. Install the update package for Communications Server 2007 that is dated August 2008 on computers that have the following roles:
    Standard Edition Server
    Enterprise Edition Server – Front End
    Proxy Server
    Director Server
    Edge Server
    Forwarding Proxy
    For more information, click the following article number to view the article in the Microsoft Knowledge Base:
    952783 (http://support.microsoft.com/kb/952783/) Description of the update package for Communications Server 2007: August 2008
    3. Install the update for Communicator 2007 that is dated July 2008 on Communicator 2007 clients. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
    954439 (http://support.microsoft.com/kb/954439/) Description of the update for Communicator 2007: July 2008
    Thursday, August 21, 2008 5:26 PM
  • Hi Chris, I have tested now with a 2811 & 12.4(21) with a MTP (Which is successfully registered to CCM) and selected in the MRGL in the SIP trink config.

     

    I still get media passing through the subscriber (as a b2bua really) and I have no idea why. I assume you have done a packet capture, do you not get any RTP passing through the subscriber. Is your RTP direct from your Cisco phone to thew gateway and then to the mediation server ?

     

    I get this RTP flow...

     

    7970 SIP phone -> Subscriber -> Gateway -> Mediation server

     

    When I would expect to see 7970 SIP phone -> Gateway -> Mediation server

     

    I get the same problem when I use the gateway in between CCM and Asterisk. Direct trunk to asterisk creates direct RTP path from phone to Asterisk, if I put the gateway in between, then the media also pases through the subscriber too. I'll have to dive into the SDP a bit deeper and really try and figure out is going on.

     

     

    any thoughts ?

     

    Mark

     

     

     

    Mark

    Friday, August 22, 2008 9:34 AM
  •  

    Earlier in this thread it was mentioned that the only reason for a Cisco ISR (or some similar IP-IP gateway) was to strip off that leading zero.  Does this mean that this patch will allow Call Manager to talk directly to OCS via SIP and vice versa?  Did I miss something?
    Monday, August 25, 2008 3:05 PM
  • Hi Mark,

     

    Not sure why you would get the RTP stream passing through your callmanager. Ensure you MRGL doesnt have the Callmaanger MTP resources in there is all I can think of. Ensure the only MTP resources you have in there is the IP-IP GW. There is no reason once you have the ISR MTP in the NRGL that the RTP should flow through the callmanager. Since you are using a later version of Callmanager ensure that you do not have mtp required on your SIP trunk. 5.x and 6.x do not require you have this option selected. Your MRG setup is the only thing I can think of without more info.

     

    Cheers

    Chris

     

    Monday, August 25, 2008 4:47 PM
  • Hi Ryan,

     

    You not missing anything. This is a new patch from MSFT that allows you to do a SIP trunk to an IP PBX that doesnt support RFC 3966. AKA Callmanager 5.x & 6.x. not sure about 4.2.3. I havent seen any documentation on the subject as yet just the patch.

     

    So this is not just for the IP-IP GW solution but any gateway that was supporting the link between Callmanager and OCS for the removal of the + sign. The bonus with the use of the ISR was in a high call volume enviroment it also acts as MTP resources which is a requirement in a Callmanager enviroment that supports a variety of protocols such as skinny, h323 mgcp  SIP etc. So now you can do a straight trunk to OCS but you may still require MTP resources.

     

    Hope this helps make it a little clearer for you:-)

     

    Cheers

    Chris

    Monday, August 25, 2008 4:54 PM
  • Hi Chris, thanks for your reply. The problem with your suggestion of "ensure that you do not have mtp required on your SIP trunk" is that takes me back to my original problem. With this unset, the IP-IP gateway creates an invalid second leg by not including the "content-length" header attribute and without this the miedation server promptly rejects the invite.

     

    I did some more testing with Askerisk also, whever I enable MTP on the trunk, all media passes through the Subscriber, when I disable, all media paths are expected.

     

    I have Cisco looking into the gateway issues regarding the creation of the invalid second call leg that the mediation server is rejecting (Due to no "content-ength" in SIP invite from the IP-IP gateway to the mediation server)

     

    cheers

     

    Mark

    Monday, August 25, 2008 9:32 PM
  • Hi Mark,

     

    What you are seeing is really strange. I have a pilot with 300 people with the following configuration:

     

    CCM 6.1 SIP trunk no mtp required-----> IP-IP GW (2851)-----> OCS

     

    Everything is working fine. I have a dedicated MRG with nothing but the onboard MTP from the IP-IP GW in the there thats then applied to the SIP trunk. Like I said 5 & 6.x will alocate MTP's when required so no need to select the required mtp. Good lusk with finding your answer and let us know what happens.

     

    Cheers

    Chris

     

    Tuesday, August 26, 2008 3:00 PM
  • Hi Chris, yes was strange indeed. It seems to be working fine now after I changed from INT VOICE/VIDEO, IPIPGW, TDMIP GW AES to INT VOICE/VIDEO GK, IPIPGW, TDMIP GW AES, LI 12.4(20)T 

     

    Even in a multi hop configuration (Which is part of my design), as long as I have this gateway being the last one before the mediation server, it reinserts the missing content-length header and all works ok.

     

    What IOS image are you running btw ?

     

    Thanks for your help..

     

    cheers

     

    Mark


     

    Tuesday, August 26, 2008 11:12 PM
  • Hi Mark

     

    In our pilot we are using 12.4.9t6 but we have tested with 12.4.20t which seems to work okay as well.

     

    Cheers

    Chris

    Thursday, August 28, 2008 2:14 PM
  • Hi Mark

     

    In our pilot we are using 12.4.9t6 but we have tested with 12.4.20t which seems to work okay as well.

     

    Cheers

    Chris


    Hi there,

    anyone having experiences with Cisco CallManager 6.1.2.1121-1 and OCS R2 direct SIP integration (without using Cisco IP-IP GW, so Mediation talks directly to CallManager and vice versa)?

    R2 supports by default the cropping of "+" sign for outbound calling (via WMI settings, check documentation) so that may not be an issue, if sending numbers with "+" prefix towards CCM.
    I have a scenario, where we use internal extensions prefixed with the "+" sign for OCS LineURI attribute, because the CCM is not configured with E.164 dialplans.

    OC -> Cisco IP phone calls are working fine, that proves that cropping of "+" is correct.

    However calling from Cisco IP phone to OCS calls are strange: MOC user cannot answer the call, no matter how many times he click the Answer. The mediation wireshark trace shows that multiple INVITEs are coming from CCM for the same call. If MOC user rejects the call, mediation sends the SIP REJECT message; but that may be ignored on cisco side, after some time a new INVITE is sent towards the mediation, call is still ringing in MOC. The only way this call can be cancelled, to hangup the call on the Cisco phone. Are we missing some basic setting turned on/off in CCM? Thanks, Richard
    Wednesday, April 1, 2009 9:31 AM
  • Hi Richard,

    The cropping of the + sign does have to be turned on in R2 it is not on by default. Something to check on your CCM is that MTPS are defined within CCM and that the trunk has them as required. All types of issues can arise without MTP's set to required although it may work without this setting in place its something worth trying. You may want to make sure the MTP preferred code is set to g711ulaw as well.

    Cheers

    Chris


    http://voipnorm.blogspot.com/
    Monday, April 13, 2009 3:32 PM
  • Hello,
    I have additional question regarding translation rule in similar configuration:
    Hello,
    In our environemnt (OCS 2007 & Cisco Call Manager 6.1), I want to apply normalization rule, that would put away starting + and change it with 0.
    Let me explain our situation. On our media gateway we have rule, that cuts away + when calling to cisco call manager. That is ok.
    We have problems when user click on number from Outlook contact that has format +386....when this number reaches Cisco Call manager, number looks like 386... That is not ok. I would like rule, that change +386.... to 00386.
    I don't know how to write rule that would change staring +.

    And idea?

    Thanks in advance.

    Regards,
    Tuesday, August 4, 2009 4:30 PM
  • Hi Rok,

    I would leave everything in the OCS environment in an E164 format. The change you are talking about should be able to be achieved using translation patterns in CUCM. A translation pattern could easily change any inbound number that starts with 386 and put 00 in front of it. The most difficult part of this is ensuring you use Calling search spaces in CUCM correctly to get the desired affect.

    Cheers
    Chris

    http://voipnorm.blogspot.com/
    Saturday, August 15, 2009 7:04 AM