locked
Calls between OCS - Call Manager Express RRS feed

  • Question

  • I've set up OCS - Mediation Server - Call Manager Express and connected SIP phones directly to the UC500 that runs Call Manager. When I make a call from CME to OCS the call goes through, but sound only travels one-way. By that I mean that the Communicator client can hear what the person from the SIP phone is saying, but the other way around doesn't work. I'm also unable to make calls from OCS to CME, so the connection only seems to be working in one direction. Communicator is giving me a error 404, saying that there are no routing rules and when I look in the Event viewer it seems to be searching for a sipexternal, that it can't find.

     

    The SIP phones has extension like 2** and the expression for the route is ^\+(\d*)$ the normalization rule is ^(\d{3})$ and translation pattern +$1.

     

    I don't have any firewalls turned on, so that's not the problem. Do I have to create a DNS A record for sipexternal?

     

    I'm very much a newbie here, so the solution to this problem could very well be simple. Still hoping for some thoughts that could help me solve this.

    Friday, August 22, 2008 2:03 PM

All replies

  • Seems to me that you have a problem with DNS

    Do you have the sipinternaltls SRV Record configured?

    But that is not really your problem, that is only a lookup when the client does the logon process (not so important now)

     

    You should use the Enterprise Route Helper from the Resource Kit to see if your routes are configured fine

    http://www.microsoft.com/downloads/details.aspx?FamilyID=b9bf4f71-fb0b-4de9-962f-c56b70a8aecd&DisplayLang=en

     

    You must also check that the user you are testing with has the rights to use that route (Phone Usages)

     

    One way audio is many times firewall problems

    Make sure that your Mediation server can connect to CME

    Friday, August 22, 2008 9:49 PM
  •  

    My sipinternaltls DNS SRV Record looks like:

     

    Service: _sipinternaltls

    Protocol: _tcp

    Port Number: 5061

    Host offering this service: <FQDN of OCS Standard Edition Server>

     

    I can ping Call Managers IP address from all the servers (OCS, AD, Mediation Server), as well as from the client computers (XP with Communicator installed) - and that includes pinging the IP addresses of the phones (internal IP addresses, like 10.1.1.X). Call Manager (the external IP address, the data VLAN) is on the same subnet as OCS and Mediation Server - only the Voice VLAN with the SIP Phones has internal addresses in the network 10.1.1.0.

    Or do you by connection between CME and Mediation Server mean something else than ping?

     

    When I use Route Helper and manually add a Test Case (add a number, location profile, policy, expected translation, expected phone usage and expected route) the test shows "Pass". However, when i right click the test case and choose "Run selected test case in Ad-Hoc Tab" and choose the gateway test, it says "Outbound policy was not possible because a policy was not provided". A bit confusing, since it's the same number and all the only difference is if I do the test in AD-Hoc or under "Test cases".

     

    If I use the OCS snap-in and check the properties for the users (choose the configure button) it shows the correct policy if I look under  "Enable Enterprise Voice". I assume there is nowhere else to look?

     

    Could there be a problem with my SIP trunk configured on Call Manager or is the problem only on my Microsoft servers?

    Do I have to add the Call Manager users to AD when they are on the same subnet?

     

    Monday, August 25, 2008 12:07 PM
  • Hi Lisa,

     

    The CME configuration should be pretty straight forward. All you should need is a SIP trunk to the OCS mediation server. MTP resources are not an issue on CME like the full blown callmanager.

     

    SIP trunk

     

    dial-peer voice 206 voip
     description to OCS Mediation server
     destination-pattern 1206......

     session protocol sipv2
     session target ipv4:X.X.X.X

     session transport tcp
     dtmf-relay rtp-nte
     codec g711ulaw
      no vad
    !

    Depending on the version of IOS you may or may not need a inbound translation pattern to remove the + sign coming from OCS. Anything later than 12.4.(15xz) should be fine the plus sign is removed automatically.

     

    As for your inbound routing from OCS I suggest you do some reading on the technet resources for OCS Enterprise voice may help you better understand how the setup work if you havent done so already.

     

    http://www.microsoft.com/downloads/details.aspx?familyid=24e72dac-2b26-4f43-bba2-60488f2aca8d&laylang=en&displaylang=en

     

    Subnets are only an issue if you have firewalls and ACLs blocking your path somewhere other wise it shouldnet have an effect.

     

    Cheers

    Chris

     


     

    Monday, August 25, 2008 5:46 PM
  • Thanks for the tip about firewalls and ACL. I got the router with a config on it and the guy who hade configured it told me I shouldn't change anything in the auto generated firewall. He said it didn't do anything anyway, so I ignored it.

    Now I've changed som access lists to "permit any" and I got communication so that when the SIP phones calls the Communcator they both can hear each other. But what still doesn't work is calling from Communicator to the SIP phones. I still get and 404 error saying the routing policies are incorrect.

     

    I'm starting to think that also has to do with the Call Manager config, since I've checked and double checked my OCS config according to the Enterprise VoIP Guide. Or is it not possible for the Communicator to complain about the routing policies if the problem really is in Call Manager?

     

    But thanks a lot for the help. Made me realise I can't trust this guy Wink

     

    Tuesday, August 26, 2008 10:10 AM
  • Well, Communictor says it could be either

     

  • There are no routing rules on the Office Communications Server for the phone number you are attempting to call.
  • The contact’s address is invalid.

     

    So if there is something wrong with the CME config (that makes Communicator unable connecting to it) I suppose Communcator can say that the contact's address is invalid? Or am I wrong?

Tuesday, August 26, 2008 12:10 PM
  • I think you have a OCS routing problem. Keep using the route helper and recheck your rules for phone usage policy and the routes that go with them. OCS is saying there are no routing rules for the pattern you are entering so this has nothing to do with CME I would think.

     

    Cheers

    Chris

     

    Tuesday, August 26, 2008 2:50 PM
  • I've now deleted and added new policies, phone usage records, location profiles and routes about 4 times, and also according to different guides I've found on the Internet. Still the same respons in the Route helper. Is it possible for the problem to have to do with something else than just my policies? I mean, event viewer is talking about the DNS records and Communicator about the routing policies. Feels like ocs can't really tell what's wrong here.

     

    I'm hoping I'm not totally wrong with my deployment, I mean I assume I don't need an Access Edge server when I don't use a firewall and all the servers and CME are in the same subnet? When you deploy Mediation Server you have to add an A/V Edge Server or you'll get warnings about A/V Authentication Service.

    The Outbound routing component that is installed by default should make it possible to make calls between ocs-mediation server-cme or do I need something else?

     

    Or are'nt the normalization rule, translation pattern and target regular expression for my route ok?

     

    Communicator clients with phone number like 503 (504, 505..)

    Call Manager client with phone numbers like 207 (208, 209..)

    Route expression ^\+?(\d*)$

    Normalization rule: ^(\d{3})$

    Translation pattern: +$1

     

    Could the fact that I use virtual machines have anything to do with it? I mean it not supported, but it should still work.

     

    A lot of desperat newbie questions here..  

    Wednesday, August 27, 2008 2:54 PM
  • If you use Route Helper it should be clear where your problem is

     

    You actually need to use phone numbers on communicator clients the include the + sign for E.164 numbering

    Normalization should take care of number translation to E.164 (+ sign full numbers)

     

    Wednesday, August 27, 2008 4:51 PM
  • Yeah, I guess I didn't write it clear enough. My Line URIs are like tel:+503 and so on...

     

    I've now used Wireshark on Mediation Server. Don't really know how to use it, but if I trace traffic for the "external" interface (the one listening for traffic from CME) I get the response:

     

    First TCP and SIP messges sent to CME IP Address requesting an ACK and the I recieve an ICMP from CME, sent to the external interface of Mediation Server with the message: "Destination Unreachable. (Port unreachable)"

     

    So I assume there is no problem with my policies and phone usage records..  I mean Mediation Server sends data to CME, but it seem to get stuck there.

    Thursday, August 28, 2008 2:13 PM
  • Hi Lisa,

     

    Try running

     

    #term mon

    #debug ccsip message

     

    on the CME box and you should see the SIP traffic between CME and OCS. This will tell you if the SIP traffic is reaching the MCE router and whether you have an OCS problem or CME problem.

     

    Cheers

    Chris

     

    Thursday, August 28, 2008 2:17 PM
  •  

    Yeah it seems so. But I can't really understand why it's rejecting the call. Here is what I get when I do the debug:

     


    UC520#term mon
    UC520#debug ccsip message
    SIP Call messages tracing is enabled
    UC520#
    Aug 28 14:31:49.367: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    INVITE sip:+207@<CME IP>;user=phone SIP/2.0
    FROM: <sip:+503@media-dator.UC.ATEA;user=phone>;epid=98BFC978FE;tag=7cbe74f168
    TO: <sip:+207@<CME IP>;user=phone>
    CSEQ: 57 INVITE
    CALL-ID: f39f0725-c518-4718-8966-acb60a6b9055
    MAX-FORWARDS: 70
    VIA: SIP/2.0/TCP <Mediation Server IP>:3801;branch=z9hG4bK9e239ad7
    CONTACT: <sip:media-dator.UC.ATEA:5060;transport=Tcp;maddr=<Mediation Server IP>;ms-opa
    que=f51f536c6c3838d7>
    CONTENT-LENGTH: 308
    SUPPORTED: 100rel
    USER-AGENT: RTCC/3.0.0.0 MediationServer
    CONTENT-TYPE: application/sdp; charset=utf-8
    ALLOW: UPDATE
    ALLOW: Ack, Cancel, Bye,Invite
    v=0
    o=- 0 0 IN IP4 <Mediation Server IP>
    s=session
    c=IN IP4 <Mediation Server IP>
    b=CT:1000
    t=0 0
    m=audio 60096 RTP/AVP 97 101 0 8
    c=IN IP4 <Mediation Server IP>
    a=rtcp:60097
    a=label:Audio
    a=rtpmap:97 RED/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    Aug 28 14:31:49.379: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 100 Trying
    Via: SIP/2.0/TCP <Mediation Server IP>:3801;branch=z9hG4bK9e239ad7
    From: <sip:+503@media-dator.UC.ATEA;user=phone>;epid=98BFC978FE;tag=7cbe74f168
    To: <sip:+207@<CME IP>;user=phone>
    Date: Thu, 28 Aug 2008 14:31:49 GMT
    Call-ID: f39f0725-c518-4718-8966-acb60a6b9055
    Server: Cisco-SIPGateway/IOS-12.x
    CSeq: 57 INVITE
    Allow-Events: telephone-event
    Content-Length: 0
     
    Aug 28 14:31:49.379: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    SIP/2.0 404 Not Found
    Via: SIP/2.0/TCP <Mediation Server IP>:3801;branch=z9hG4bK9e239ad7
    From: <sip:+503@media-dator.UC.ATEA;user=phone>;epid=98BFC978FE;tag=7cbe74f168
    To: <sip:+207@<CME IP>;user=phone>;tag=AD46000-964
    Date: Thu, 28 Aug 2008 14:31:49 GMT
    Call-ID: f39f0725-c518-4718-8966-acb60a6b9055
    Server: Cisco-SIPGateway/IOS-12.x
    CSeq: 57 INVITE
    Allow-Events: telephone-event
    Reason: Q.850;cause=1
    Content-Length: 0
     
    Aug 28 14:31:49.383: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    ACK sip:+207@<CME IP>;user=phone SIP/2.0
    FROM: <sip:+503@media-dator.UC.ATEA;user=phone>;tag=7cbe74f168;epid=98BFC978FE
    TO: <sip:+207@<CME IP>;user=phone>;tag=AD46000-964
    CSEQ: 57 ACK
    CALL-ID: f39f0725-c518-4718-8966-acb60a6b9055
    MAX-FORWARDS: 70
    VIA: SIP/2.0/TCP <Mediation Server IP>:3801;branch=z9hG4bK9e239ad7
    CONTENT-LENGTH: 0
     
    Aug 28 14:33:03.655: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    REGISTER sip:<Mediation Server IP>:5060 SIP/2.0
    Via: SIP/2.0/TCP <CME IP>:5060;branch=z9hG4bK3FD2557
    From: <sip:207@<Mediation Server IP>>;tag=AD58224-1E0C
    To: <sip:207@<Mediation Server IP>>
    Date: Thu, 28 Aug 2008 14:33:03 GMT
    Call-ID: 2C498C1C-729E11DD-800DDBBA-8986616E
    User-Agent: Cisco-SIPGateway/IOS-12.x
    Max-Forwards: 70
    Timestamp: 1219933983
    CSeq: 1011 REGISTER
    Contact: <sip:207@<CME IP>:5060;transport=tcp>
    Expires:  3600
    Content-Length: 0
     
    Aug 28 14:33:03.659: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    SIP/2.0 480 Temporarily not available
    FROM: <sip:207@<Mediation Server IP>>;tag=AD58224-1E0C
    TO: <sip:207@<Mediation Server IP>>;tag=b96fe7e399
    CSEQ: 1011 REGISTER
    CALL-ID: 2C498C1C-729E11DD-800DDBBA-8986616E
    VIA: SIP/2.0/TCP <CME IP>:5060;branch=z9hG4bK3FD2557
    CONTENT-LENGTH: 0
    SERVER: RTCC/3.0.0.0
     
    Aug 28 14:36:03.659: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    REGISTER sip:<Mediation Server IP>:5060 SIP/2.0
    Via: SIP/2.0/TCP <CME IP>:5060;branch=z9hG4bK3FE2B6
    From: <sip:207@<Mediation Server IP>>;tag=AD84148-647
    To: <sip:207@<Mediation Server IP>>
    Date: Thu, 28 Aug 2008 14:36:03 GMT
    Call-ID: 2C498C1C-729E11DD-800DDBBA-8986616E
    User-Agent: Cisco-SIPGateway/IOS-12.x
    Max-Forwards: 70
    Timestamp: 1219934163
    CSeq: 1012 REGISTER
    Contact: <sip:207@<CME IP>:5060;transport=tcp>
    Expires:  3600
    Content-Length: 0
     
    Aug 28 14:36:03.663: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    SIP/2.0 480 Temporarily not available
    FROM: <sip:207@<Mediation Server IP>>;tag=AD84148-647
    TO: <sip:207@<Mediation Server IP>>;tag=87bf74c92
    CSEQ: 1012 REGISTER
    CALL-ID: 2C498C1C-729E11DD-800DDBBA-8986616E
    VIA: SIP/2.0/TCP <CME IP>:5060;branch=z9hG4bK3FE2B6
    CONTENT-LENGTH: 0
    SERVER: RTCC/3.0.0.0
     
    Aug 28 14:39:03.663: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Sent:
    REGISTER sip:<Mediation Server IP>:5060 SIP/2.0
    Via: SIP/2.0/TCP <CME IP>:5060;branch=z9hG4bK3FF1D89
    From: <sip:207@<Mediation Server IP>>;tag=ADB006C-F05
    To: <sip:207@<Mediation Server IP>>
    Date: Thu, 28 Aug 2008 14:39:03 GMT
    Call-ID: 2C498C1C-729E11DD-800DDBBA-8986616E
    User-Agent: Cisco-SIPGateway/IOS-12.x
    Max-Forwards: 70
    Timestamp: 1219934343
    CSeq: 1013 REGISTER
    Contact: <sip:207@<CME IP>:5060;transport=tcp>
    Expires:  3600
    Content-Length: 0
     
    Aug 28 14:39:03.671: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    SIP/2.0 480 Temporarily not available
    FROM: <sip:207@<Mediation Server IP>>;tag=ADB006C-F05
    TO: <sip:207@<Mediation Server IP>>;tag=cdb2aba4e2
    CSEQ: 1013 REGISTER
    CALL-ID: 2C498C1C-729E11DD-800DDBBA-8986616E
    VIA: SIP/2.0/TCP <CME IP>:5060;branch=z9hG4bK3FF1D89
    CONTENT-LENGTH: 0
    SERVER: RTCC/3.0.0.0

    Thursday, August 28, 2008 2:47 PM
  • Can you confirm what IOS version you are using?

     

    #sh ver

     

    Looks like CME is rejecting the call because your inbound call has the + sign on the number.Depending on the version of IOS your configuration may have to remove the +.

     

    Cheers

    Chris

     

    Thursday, August 28, 2008 4:08 PM
  • Microsoft Released a fix recently that makes it possible to remove the + from the OCS Side

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

     

    Thursday, August 28, 2008 4:14 PM
  • The IOS version: 12.4<11>XW, Synched to technology version 12.4<12.12>T.

     

    But I have configured som translation-rules, thought that would help. Maybe they are incorrect?

     

    voice translation-rule 11
     rule 1 /^\+\(...\)/ /\1/

    voice translation-rule 12
     rule 1 /^\(...\)/ /+\1/

    voice translation-profile from-ocs
     translate called 11

    voice translation-profile to-ocs
     translate calling 12

     

    dial-peer voice 2005 voip

    translation-profile outgoing from-ocs
     destination-pattern 2..
     session protocol sipv2
     session target ipv4:<Call Manager IP>

     session transport tcp
     dtmf-relay rtp-nte sip-notify
     codec g711ulaw

    dial-peer voice 2007 voip

    translation-profile outgoing to-ocs
     destination-pattern 5..
     session protocol sipv2
     session target ipv4:<Mediation Server IP>
     session transport tcp
     dtmf-relay rtp-nte sip-notify
     codec g711ulaw

    Friday, August 29, 2008 6:03 AM
  • Hi Lisa!
    Do you happen to have handy the document to setup the SIP trunk from CCM Express to OCS Mediation Server?

    I haven't found anything yet.

    Thank you beforehand!

    Friday, October 31, 2008 8:27 PM
  • From what I understand a SIP trunk is the same as the dial peer and in my case I've used two dial peers - one to and one for the traffic going from the CME. The dial peers has the parameters for the traffic (like protocol and transport type, destination pattern and so on) as well as the IP of the CME (and for the other dial peer is the IP of the OCS).

     

    Hope that explanation helps at least a little bit.

    Sunday, November 2, 2008 8:47 PM