We have CUCM 11.5 that is connected by sip trunk to a CUCME in a remote office. the Sip trunk is up and the remote office can call the head office but the head office can't call the remote office. i don't have access to the CUCME in the remote office but the dial-peer are pointing to all of our CUCM servers (confirmed it today). Is there any way i can debug calls passing through the sip trunk from the CUCM to see whats happening?
Below is a screenshot of the sip trunk query on RTMT. Notice the trunk on subscriber .222 (main call processing Server) is not in service and i can't think of how to bring it up.
Can you look at the SIP Trunk itself in CUCM and show the reason for the "Time not in service"?
You can run a trace for the Cisco CallManager Service on your servers, then place a call that is supposed to go over the trunk. The trace file will include the internal CUCM decision-making regarding the call, and the signaling (if any) that is sent/received over the trunk.
If you post the trace file here, we can take a look at it. Or, since you have RTMT you can look at the SIP Session Trace and generate a diagram which should give some indication of what the problem is.
OK, so now that I am looking at your screenshot more carefully I'm thinking that there is an IP problem of some sort (not on the allowed list, for instance, on the CUCME router) with the .222 communications. Let's start with the reason given on the trunk (in CUCM) for that server not connecting to the far end. It may be that a trace including a reset of the trunk may give us information about why as well.
So when you go to the trunk itself (Device > Trunk) it is showing "Full Service"? (Oh, sure, because it's only worried about the one IP on the far end. Duh on me.)
What CMG is associated with that trunk's device pool? (And is the .222 in it? Maybe listed first?) Also, do you have "Run on All Active Nodes" checked at the Route List pointing to the CUCME?
For whatever reason (firewall, trust list on the CUCME router, maybe dial peers) the CUCME does not want to connect with the .222 server. That is probably on the CUCME side, and I'd rather troubleshoot that end. But since you can't poke around over there we need to prevent .222 from trying to connect.
So, if the CMG for the trunk includes the .222 server make a new CMG and/or device pool without it. Also, while it is pretty much always a good idea to have "Run on All Active Nodes" checked on your route lists, for the route list that points to the CUCME router this may be one of the rare cases where you should not.
Let's give that a try and see where we get.
Sorry for the late reply, an emergency took me out of town.
we have a CMG group just for that sip trunk, I've reordered it all to no avail & I even removed .222 entirely but it wont just come up. There is no route list or group configured as far as i can see.
The next thing I would want to look at is a trace file of the Cisco CallManager service that includes a reset of the trunk. That will show the interaction of CUCM and CUCME with regards to the trunk. Can you provide that? If you are uncomfortable posting it publicly, you can send it to me in a PM and I'll look at it offline.