MOC sees incoming call from CallManager, but can't actually answer the call RRS feed

  • Question

  • We just installed a mediation server for ocs 2007 r2, and we have created a sip trunk in call manager to tie the two systems together. It seems as though they are talking to each other, because when I dial the number (the number that I configured for a test user within the user's ocs properties), the communicator client sees the call. When I click the button to Answer Incoming Call, though, it just keeps ringing, and after about 10 seconds, it stops and tells me the call could not be connected, and the phone dialing in goes to a fast busy.

    Are there any basic things we may have overlooked here?
    Tuesday, May 12, 2009 1:05 PM

All replies

  • It could be a few things.  See if this post helps you out:


    That was written for CM 7 but 6.x is identical and earlier versions aren't much different.
    Mike Stacy | Evangelyze Communications | http://www.evangelyze.net/cs/blogs/mike
    Wednesday, May 13, 2009 5:53 AM
  • Mike,

    We did just your blog post as a guide. It was very helpful, but it didn't go into much detail about the configuration on the OCS side of things. I am almost certain this is a problem with my routes and/or my normalization rules. I have a number assigned to a test user (this user is 73175, and other test users will be 7xxxx), and I just want it to be able to dial into a MOC client. The sip trunk seems to be configured properly, but my error logs indicate problems with the route.

    I've read through several blogs about the normalization rules, but I haven't come across anything extremely clear as to what I should do. Could you give me some direction on how I should have my route configured? I'm not looking for anything fancy, I just want the MOC client to accept the call  and be able to make outgoing calls to/from callmanager.


    Wednesday, May 13, 2009 12:59 PM
  • ok, i have an update, but still not fully working. I am able to call one of our cisco voip phones and talk to the person on the other end just fine. when dialing from a voip phone to the number assigned to my test OCS user, it dials that user's MOC client. Like I mentioned in a previous post here, I click the notification to answer the call, and it appears to be trying to establish the phone call, but it stops after 4 rings and the voip phone then gives a fast busy signal. I have turned on logging in Communicator, but it does not provide any logs for this event.

    I have run the logging on the OCS server, particularly the SIPStack log. When making a call from MOC to a phone, I get this info (this is the shortened version, of course):

    TL_INFO(TF_PROTOCOL) [1]07C8.0C54::05/13/2009-19:09:22.954.000006a6 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
    Instance-Id: 00000E17
    Direction: outgoing;source="local"
    Message-Type: response
    Start-Line: SIP/2.0 101 Progress Report
    From: "Wolverine"<sip:wolverine@testmail.gtri.gatech.edu>;tag=9482d69169;epid=3f42cad54e
    To: <sip:76800;phone-context=dialstring@testmail.gtri.gatech.edu;user=phone>
    CSeq: 1 INVITE
    Call-ID: 351b152d405f4a0297b9ca412a69ddea
    Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF73DD7913742A9A8F1FCEFF8BAD2694F8", srand="2DD9993C", snum="162", opaque="882793C2", qop="auth", targetname="sip/atatlisdocsr2.core.gtri.test", realm="SIP Communications Service"
    Content-Length: 0
    Via: SIP/2.0/TLS;ms-received-port=1794;ms-received-cid=8000
    ms-diagnostics: 12006;reason="Trying next hop";source="atatlisdocsr2.core.gtri.test";PhoneUsage="CN={C491D082-9CD3-4A41-9A79-9DCEE38670EB},CN=Phone Route Usages,CN=RTC Service,CN=Services,CN=Configuration,DC=gtri,DC=test";PhoneRoute="all";Gateway="atatlisdocs04.core.gtri.test:5061";appName="OutboundRouting"
    Server: OutboundRouting/
    Message-Body: –

    TL_INFO(TF_COMPONENT) [0]07C8.16B4::05/13/2009-19:09:22.954.000006a7 (SIPStack,CRecvContext::ProcessCompletion:RecvContext.cpp(155))( 0000000004ECC050 ) Received 2026 bytes
    TL_INFO(TF_COMPONENT) [1]07C8.16B4::05/13/2009-19:09:22.954.000006a8 (SIPStack,CRecvContext::ProcessCompletion:RecvContext.cpp(155))( 0000000004ECC050 ) Received 59 bytes
    TL_INFO(TF_CONNECTION) [0]07C8.16B4::05/13/2009-19:09:22.954.000006a9 (SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(161))$$begin_record
    LogType: connection
    Severity: information
    Text: Connection established
    Peer-FQDN: atatlisdocs04.core.gtri.test
    Peer-Name: atatlisdocs04.core.gtri.test
    Connection-ID: 0xAE00
    Transport: M-TLS

    Worth noting is the From: and To: lines. When I trace the phone call in the opposite direction, when calling from phone to MOC, I get the following lines in the log in many places. It is almost like my MOC client, when I attempt to answer the call, is looping around to itself and never establishing the connection with the incoming call.

    TL_INFO(TF_PROTOCOL) [0]07C8.0A1C::05/13/2009-19:39:07.316.00000b18 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
    Instance-Id: 00000ED9
    Direction: outgoing;source="local"
    Message-Type: request
    Start-Line: BENOTIFY sip:;transport=tls;ms-opaque=f92fe4152e;ms-received-cid=BB00 SIP/2.0
    From: <sip:wolverine@testmail.gtri.gatech.edu>;tag=BE180080
    To: <sip:wolverine@testmail.gtri.gatech.edu>;tag=ce7479ae5e;epid=3f42cad54e
    CSeq: 6 BENOTIFY
    Call-ID: 6aa21dc407954bd0a0092fc9f472e68a
    Via: SIP/2.0/TLS;branch=z9hG4bKE0EA9E62.34628EBA1D3CD92B;branched=FALSE
    Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF70CC317B097853EAF58BF6BA6B8287F2", srand="FB741E48", snum="18", opaque="C1248446", qop="auth", targetname="sip/atatlisdocsr2.core.gtri.test", realm="SIP Communications Service"
    Max-Forwards: 70
    Content-Length: 5744
    Require: eventlist
    Content-Type: application/vnd-microsoft-roaming-self+xml
    Event: vnd-microsoft-roaming-self
    subscription-state: active;expires=46553
    Message-Body: ----****MESSAGE BODY DELETED****----
    Wednesday, May 13, 2009 7:47 PM
  • Hi Paul,

    Couple of points. Best bet is to run the logging on the mediation server and the front end for your issue. The mediation server may give you better insight into what is going on. Second is Mike's Blog entry (which is pretty good by the way) doesnt talk about how to setup MTP resources in CUCM. You must have an MTP resource available for the call to work. Just having the MTP required selected on the trunk wont make it work.  There are a number of options here and you may want to build the required media resource groups and lists to allocate to the trunk to ensure you use the correct resources. The options I am referring to are place the MTP on CUCm or using a hardware resource like a router. Now, using a router doesnt require DSP's for MTP's like transcoding or conferencing so you can configure the router to use software MTP resources just fine. Better yet if your load is small enough configuring the MTP's on your CUCM boxes will work also.

    The fact your client rings but you can not answer suggests to me you have your routing working and its another part of the configuration. Hope this helps.

    Thursday, May 14, 2009 3:52 AM
  • Will logging (using the logging tool) from the mediation server produced any different results? I assume the logging tool pulls from the entire ocs environment.

    Chris, I ran your info by our CallManager guy, and he said things are correctly in place according to what you stated.

    And, like you said, this appears to be an issue not related to routing, since the MOC client is getting the call. It almost seems like a problem with the MOC client itself, or some communication between it and the front-end (or maybe the mediation server).

    Outgoing calls seem to be intermittent also. this morning i could not make a call to a phone from MOC, and an hour ago i could. i specifically did not change anything to see if it would start working again, and it did. now it is not working again, and the OutboundRouting log shows this:

    TL_INFO(TF_COMPONENT) [0]0DDC.0F4C::05/14/2009-15:14:49.126.000000c9 (OutboundRouting,OutboundRoutingDispatcher.PrepareRequest:outboundroutingdispatcher.cs(651))( 0000000002B1EBED )Next hop not found.
    TL_INFO(TF_COMPONENT) [0]0DDC.0F4C::05/14/2009-15:14:49.126.000000ca (OutboundRouting,OutboundRoutingDispatcher.ReRouteRequest:outboundroutingdispatcher.cs(898))( 0000000002B1EBED )Cannot reroute request: Routes available, but no next hop available

    Also the Application log for Communicator on my local machine tells me "Temporarily cannot route" and "The peer actively refused the connection".
    Thursday, May 14, 2009 3:31 PM
  • Hi Paul,

    Absolutly you will see different messages on the mediation server compared to the front end. The Mediation server will provide you a direct reference of what is going on between your two enviroments which sounds like where the problem lies. I am pretty sure if you can gather the logs from the mediation people in this forum may be able to provide you a clearer idea of what is going wrong.

    The hit and miss behaviour is a bit strange though. Just to make sure, do you have any firewalls between the two enviroments. Just a thought.

    Thursday, May 14, 2009 4:09 PM
  • I'm not sure if this was the direct cause of not being able to find callmanager, but i had 2 nic's active on my mediation server, and everything was configured for just one of them. it may have been trying to use the secondary nic. i disabled the nic i wasn't wanting to use, and tried to dial a phone from MOC and it worked. *maybe* that will solve that problem.

    now, as for the logging, now i remember why i didn't take a logging session from the mediation server. while logged into the mediation server, if i right-click on the mediation server in the OCS Admin snap-in (or the pool, for that matter) and start a logging session, the SIPStack log option is not available to me. if i am logged into the front-end server and start a logging session, i have the SIPStack option. Is this normal behavior. Does anyone else see something similar?
    Thursday, May 14, 2009 4:53 PM
  • Paul,

    I think you discovered your own issue. You need two nics active on the mediation server each with their own IP address. Only the Nic that is configured for communicating with OCS should be registered in DNS. The other Nic should be configured for talking with the CUCM.

    Thursday, May 14, 2009 7:40 PM
  • hmm, i hope that is the case. can i ask you to clear things up a little bit?

    i had 1 nic active, In the mediation server's properties, i had both the Communications Server listening IP address and the Gateway listening IP address set to this ip address, as it was the only option to select. in this scenario, calls from MOC to CUCM worked. Calls from CUCM to MOC rang, and when I clicked Answer Call in MOC, it just timed out.

    now, i have enabled the second nic again, It now shows up in both of those pulldown menus. I changed the Comm. Server listening IP to 5.203, restarted medation services, and i could not dial out. i changed it back and, of course, outbound calling works again. should i change the gateway listening ip address, and then get with our CUCM guy to change the settings in CUCM to connect to OCS with that new IP?
    Thursday, May 14, 2009 7:53 PM
  • The trunk address in CUCM and the gateway listening address on the mediation server are going to have to be set to be the same. So under the trunk configuration in CUCM you Cisco guy will need to change the trunk address to your new medaition server address.

    So Gateway listenign address (not registered in DNS) also configured on CUCM as the trunk address OCS listening address (registered in DNS)

    To stop the nic registering in DNS you will have to go into the NIC properties and unselect the register in DNS check box.

    Hope this clears it up.

    Thursday, May 14, 2009 9:00 PM
  • my 2 nics are now active. the mediation server's OCS Listening address is (port 5061), and the Listening address for gateway traffic is (port 5060). I set to not register in dns. The CUCM sip trunk is set for

    I'm getting the same results as before. I'm still able to call out of MOC, but it rings 4 times and times out when dialing from voip phone to MOC.

    Are there any particular logs I should try? This could also be something basic and silly that I have overlooked (I've had a few of those moments in the process of deploying OCS!)
    Friday, May 15, 2009 1:20 PM
  • You still need to run the logging tool on the medation server. Not sure why you cant select the SIP stack but without this it is really going to limit your ability to find out what is going on. You coudl talk with the Cisco guys about running a log on the CUCM if the medation server isnt going to work for you.




    Friday, May 15, 2009 4:46 PM
  • I'm not sure why SIPStack doesn't show up. I think this is simply a problem with MOC talking to OCS, because all routing from CUCM seems to be working properly.

    I went back to the documentation on technet for ocs 2007 r2 (which is impossible to find, btw), and I looked at the Deploying Enterprise Voice section. One of the prereq's was this:

    All edge servers are deployed and operational in your perimeter network, including Access Edge Server, Audio/Video Conferencing Edge Server, Web Conferencing Edge Server, and a reverse proxy.

    We do not have any edge servers deployed. The warning messages I saw in the Mediation server settings about not having an AV Edge server didn't seem to indicate that my calls would not work, though. We are doing everything internal right now. Would the fact that we don't have any edge servers make a difference, though? To be honest, I am not quite sure why we need an edge server, if (for now) we just want the functionality on our internal network.
    Friday, May 15, 2009 5:34 PM
  • You can ignore the edge warnings bascially unless you want to install the service. My best advice for you would be capture a call from CUCM using the tracing tools available on CUCM and see what it comes back with.

    Friday, May 15, 2009 7:01 PM