Does anyone have procedures for creating a SIP trunk between Cisco Call Manager 6.1 and MIC 2.4? I found an I3 manual for CIC 3.0 to CUCM 6.1 and followed the steps that seem to apply but I just get a busy signal when trying to call via call manager. According to Dialed Number Analyzer the call is routing out this trunk but still just getting busy signal. Thanks!

Have you checked this thread, and post by Dimitrije http://community.inin.com/forums/showthread.php?4832-SIP-trunk-between-IC-3-0-and-CCM-4-2 Does this fit to you? Regards

Assuming that guide came from testlab.inin.com, then it should be sufficient for hooking up MIC 2.4 to CUCM 6.1. Keep in mind that since IC 2.4 didn't go through the Cisco SIP IVT, Cisco will decline support with that version of IC software. That being said, I've seen a few folks test it out and it has worked well for them. Are you sure you have both transports set to TCP? I don't think CUCM supports UDP, and that was the common default for MIC 2.4 installs. If that's not the problem, you may need to break into the SIPEngine log to see how IC is responding. Are there any Access Control settings on the SIP Line(s) that might prevent the CUCM from connecting?

We do SIP trunking to several Dialogic PIMGs and DIMGs however this is the first time connecting to Call Manager. Since we use SIP extensively for PIMGs I don't suspect it is and access problems... I see the SIPEngine log on the server however in Trace Config I don't see a category to turn these logs up. Do these fall under another category in trace config?

Access Control Rights, if setup, specifically grant and deny access to different devices by their IP Address. If you've setup Access Control Rights for your DMG devices, then you've probably inadvertently restricted any other devices. FWIW, this is not the recommended configuration for MIC. The recommended line configuration is discussed in the attached PDF (chapter 7). Also, DMGs use UDP by default - so if all of your SIP lines are setup for UDP, and CUCM is using TCP, we won't be able to hear the incoming INVITE, and CUCM will timeout. SIPEngine is a topic in the TSServer Subsystem.

I've already setup Grant Rights for the Call Manager servers on MIC so I don't think that is it and everything is set for TCP...

Here is what I'm seeing in the SIPEngine. Why would MIC send a Forbidden responce or denied? SIPTCPHandlerIO::MsgReadComplete(): remote=134.156.3.241:34862, message= INVITE sip:1025@172.18.4.70:5060 SIP/2.0 Date: Wed, 30 Dec 2009 18:43:50 GMT Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, PUBLISH From: "Dave Brinker" <sip:7476@134.156.3.241>;tag=3993488b-c445-47b8-8d76-a05b0a3b9477-36756341 Allow-Events: presence Supported: timer,replaces Min-SE: 1800 Remote-Party-ID: "Dave Brinker" <sip:7476@134.156.3.241>;party=calling;screen=yes;privacy=off Content-Length: 0 User-Agent: Cisco-CUCM6.1 To: <sip:1025@172.18.4.70> Contact: <sip:7476@134.156.3.241:5060;transport=tcp> Expires: 180 Call-ID: 440ebc80-b3b19f66-25-f1039c86@134.156.3.241 Via: SIP/2.0/TCP 134.156.3.241:5060;branch=z9hG4bK242231bac7 CSeq: 101 INVITE Session-Expires: 1800 Max-Forwards: 70 SIPTCPTransport::findOrCreateConnection(): found TCP address=134.156.3.241:5060 by address SIPTCPTransport::send(): transmit to 134.156.3.241:5060 SIP/2.0 403 Forbidden To: <sip:1025@172.18.4.70>;tag=242112 From: "Dave Brinker" <sip:7476@134.156.3.241>;tag=3993488b-c445-47b8-8d76-a05b0a3b9477-36756341 Via: SIP/2.0/TCP 134.156.3.241:5060;branch=z9hG4bK242231bac7 CSeq: 101 INVITE Call-ID: 440ebc80-b3b19f66-25-f1039c86@134.156.3.241 User-Agent: ININ/2.400.10.12901 Content-Length: 0 SIPTCPHandlerIO::handle_write_stream(): Transmitted (347/347) to 134.156.3.241:5060 SIPTCPHandlerIO::MsgReadComplete(): remote=134.156.3.241:34862, message= ACK sip:1025@172.18.4.70:5060 SIP/2.0 Date: Wed, 30 Dec 2009 18:43:50 GMT From: "Dave Brinker" <sip:7476@134.156.3.241>;tag=3993488b-c445-47b8-8d76-a05b0a3b9477-36756341 Allow-Events: presence Content-Length: 0 To: <sip:1025@172.18.4.70>;tag=242112 Call-ID: 440ebc80-b3b19f66-25-f1039c86@134.156.3.241 Via: SIP/2.0/TCP 134.156.3.241:5060;branch=z9hG4bK242231bac7 CSeq: 101 ACK Max-Forwards: 70 SIPTCPHandlerIO::MsgReadComplete(): Ignoring ACK from denied IP=134.156.3.241:34862 SIPTCPHandlerIO::MsgReadComplete(): remote=134.156.3.241:34862, message= INVITE sip:1025@172.18.4.70:5060 SIP/2.0 Date: Wed, 30 Dec 2009 18:43:57 GMT Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, PUBLISH From: "Dave Brinker" <sip:7476@134.156.3.241>;tag=3993488b-c445-47b8-8d76-a05b0a3b9477-36756346 Allow-Events: presence Supported: timer,replaces Min-SE: 1800 Remote-Party-ID: "Dave Brinker" <sip:7476@134.156.3.241>;party=calling;screen=yes;privacy=off Content-Length: 0 User-Agent: Cisco-CUCM6.1 To: <sip:1025@172.18.4.70> Contact: <sip:7476@134.156.3.241:5060;transport=tcp> Expires: 180 Call-ID: 483ada00-b3b19f6d-26-f1039c86@134.156.3.241 Via: SIP/2.0/TCP 134.156.3.241:5060;branch=z9hG4bK25222c3915 CSeq: 101 INVITE Session-Expires: 1800 Max-Forwards: 70 SIPTCPTransport::findOrCreateConnection(): found TCP address=134.156.3.241:5060 by address SIPTCPTransport::send(): transmit to 134.156.3.241:5060 SIP/2.0 403 Forbidden To: <sip:1025@172.18.4.70>;tag=242748 From: "Dave Brinker" <sip:7476@134.156.3.241>;tag=3993488b-c445-47b8-8d76-a05b0a3b9477-36756346 Via: SIP/2.0/TCP 134.156.3.241:5060;branch=z9hG4bK25222c3915 CSeq: 101 INVITE Call-ID: 483ada00-b3b19f6d-26-f1039c86@134.156.3.241 User-Agent: ININ/2.400.10.12901 Content-Length: 0 SIPTCPHandlerIO::handle_write_stream(): Transmitted (347/347) to 134.156.3.241:5060 SIPTCPHandlerIO::MsgReadComplete(): remote=134.156.3.241:34862, message= ACK sip:1025@172.18.4.70:5060 SIP/2.0 Date: Wed, 30 Dec 2009 18:43:57 GMT From: "Dave Brinker" <sip:7476@134.156.3.241>;tag=3993488b-c445-47b8-8d76-a05b0a3b9477-36756346 Allow-Events: presence Content-Length: 0 To: <sip:1025@172.18.4.70>;tag=242748 Call-ID: 483ada00-b3b19f6d-26-f1039c86@134.156.3.241 Via: SIP/2.0/TCP 134.156.3.241:5060;branch=z9hG4bK25222c3915 CSeq: 101 ACK Max-Forwards: 70 SIPTCPHandlerIO::MsgReadComplete(): Ignoring ACK from denied IP=134.156.3.241:34862

Probably need to turn up SIPEngine tracing, and check out the SIPEngine log. Feel free to email it to me and I can take a look too. andyg@inin.com

I was able to get the SIP trunk working for voice, for some reason we had to change the port from 5060 to 5061, no rhyme or reason just worked. However I cannot get fax working over this SIP Trunk. It appears that Communite hangs up on the call when I try doing fax. Any ideas? Thanks, Dave

I believe there are known issues with Cisco and T.38. I don't think it can work.

Is there an SCR in 2.4 or 3.0 to fix this? Also are there other known problems with CUCM to MIC SIP trunking I need to watch out for? Thanks, Dave

IC 2.4 was not SIP IVT tested with Cisco - so Cisco will not officially support the integration. Check testlab.inin.com for more details on the SIP IVR tests performed with CUCM. For the purposes of what is certified, MIC is based on the CIC codebase. So, MIC inherits the certification from CIC - but only of the same version. To that end, Cisco won't officially support an MIC SIP integration until MIC 3.0 is released - and then, only to versions of CUCM that CIC has been IVT certified with. There are no SCRs to resolve any faxing issues with CUCM and T.38 to the best of my knowledge. I believe the issues are on the Cisco side, but I'm not 100% certain.

I openned a case with Cisco and they are stating that Software SIP on Call Manager does not support T.38 and that I have to setup a MTP (Media Termination Point) on a gateway to support T.38. Any idea if this has been tried elseware or is this a waste of my time?

I have no idea if that will work. I'd run it through Avtex to see if they can dig up any info. They probably have more field experience with this stuff than I do.

I have Cisco Tac working on the problem and they are pointing at MIC as the problem. Is there an engineer at I3 that can work with me on this? Since Cisco is probably to #1 IP phone system I suspect it would be benificial for I3 to support this intergration as well as for me. Below is the description of the problem. So far Avtex has need been able to help. Regarding your fax solution and our WebEx we were able to determine that we are not seeing any T38 packets being seeing from the fax server which initiates the t38 switchover with a ReINVITE. Topology ************** Signaling Fax --> MGCP (PRI) --> CUCM (MGCP/SIP Trunk) --> Fax server Media Fax --> MGCP (PRI) --> MTP (172.18.155.250 port 16464) --> Fax Server The following packet capture was taken from the MTP device which has been set to allow T38 packets to transmit and receive faxing signals (t30) to the MGCP gateway which terminates the PRI circuit. The following pictures shows one way audio to the MTP resource for the initial call flow which negeotiates a (G711ulaw codec) (See Attachment) The following is the MDCX from CUCM after the fax device sends ReINVITE to CUCM to switchover to t38. This is the MGCP message and response of the port and t38 codec. Mar 18 13:49:49: MGCP Packet received from 134.156.3.241:2427---> MDCX 2459334 S1/DS1-3/7@gob1-cmm.mnpower.com MGCP 0.1 C: D00000000239241d000000F58000019c I: A52F X: 7 L: a:image/t38 M: sendrecv R: D/[0-9ABCD*#], FXR/t38 S: Q: process,loop v=0 o=- 42287 0 IN EPN S1/DS1-3/7@gob1-cmm.mnpower.com s=Cisco SDP 0 t=0 0 m=image 16464 udptl t38 c=IN IP4 172.18.155.250 a=X-sqn:0 a=X-cap:1 image udptl t38 <--- Mar 18 13:49:49: 1/3:23 (1004957) 619210440 fr-entered=10(ms) Mar 18 13:49:49: MGCP Packet sent to 134.156.3.241:2427---> 200 2459334 OK v=0 c=IN IP4 172.19.21.206 m=image 17312 udptl t38 a=X-sqn:0 a=X-cap: 1 audio RTP/AVP 100 a=X-cpar: a=rtpmap:100 X-NSE/8000 a=X-cpar: a=fmtp:100 192-194,200-202 a=X-cap: 2 image udptl t38 <--- We are not seeing any RTP being sent from the Fax Server to the MTP resource for either the initial call or the t38 switchover. The packet capture is also not seeing the SIP messaging as well. Please work with your fax server vendor to provide root cause of why we are not seeing audio or t38 data to the MTP resource (172.18.155.250 port 16464)