CUCM: Call forward from hunt pilot cross-site, recipient unable to transfer back when answering forwarded call

[Scott McAndrew]

Hi all.

I have an extremely irritating issue that I'm hoping someone can offer some advice on?

In our setup, we have two sites (let's say SiteA and SiteB for this discussion), each has a local H.323 gateway and devices registered to our main cluster. Both sites have a hunt pilot that has a full DDI number. The way they're set up is when one hunt pilot is dialled, they forward to each other on busy or no answer. Incidently, the regions are set up so the calls use G.729 (which I can confirm does work, and all our Cisco phones support G.729).

So the call flow is:

DDI >>> HuntPilot SiteA >>> CFwd busy/no ans. >>> HuntPilot SiteB

DDI >>> HuntPilot SiteB >>> CFwd busy/no ans. >>> HuntPilot Site A

Everything appears to work well, except when a call forwards from SiteA to SiteB and the call is answered in SiteB, the user is unable to transfer or hold the call. Strangely enough, when it's the other way around, it works fine!

I noticed that there was an alarm recorded on RTMT saying that media resources were exhausted, and so thinking it might be this, I downloaded the SDI files at that time. The alarm indeed seem to relate to this behaviour as I could see the call hit SiteB's hunt pilot, call forward to SiteA, be answered and then try to allocate an MTP.

So I configured IOS MTP (software) resources for each site with for codec "g729r8" thinking it may be needed to hold the call since it's g729 (and CUCM's MTPs are configured as G.711). These resources have registered and are in the local site's MRG/MRGL.

This did not solve the issue and so I took a closer look at the trace, it's showing unexpected results for the regions for "SideA" and "SideB". SideA is showing as the region of HQ, and SideB correctly showing as SiteA's region. Looking further through I can see that a CUCM (G.711) MTP resource was attempted to be allocated, and then the regions checked between them, but again showing SideA region as HQ (which is what the MTP in question is in as well).

I just can seem to fathom where the system is getting the region for HQ for SideA (maybe explaining why my newly configured G.729 MTPs are not being attempted?). I've verified that the handset which answered the call is in SiteA's device pool (and region, MRGL etc). I've also verified that what I believe should be "SideA"'s region (SiteA's H.323 gateway), that gateway is correctly in SiteA's device pool, region and MRGL etc.

I've tried to re-create the problem, registering two handsets in their respective device pools and creating two new hunt groups with the same behaviour. What differs in this test is that I call the hunt pilots internally and so an H.323 gateway is not involved. This all works fine. I've been able to test calling into SiteB's gateway and as expected, this all works fine. Unfortunately I've so far been unable to allocate a DDI in SiteA to re-create exactly, the issue.

Before my head explodes can anyone offer any thoughts at all on what could be happening?

Thanks in advance!

Scotty

[Scott McAndrew]

Managed to resolve the issue. The site in question had an old intercluster trunk (as it was previously Call Manager Express). This was still configured with the IP address of the gateway. So incoming calls from that gateway were being treated by Call Manager as an incoming intercluster trunk call. This ICT was in the wrong device pool (so wrong MRGL) and had the option "media termination point required". As we have change management I decided not to remove for now, but to change the MRGL to where I had configured the IOS software G.729 MTP. Now transferring and holding calls that come into that gateway (which divert to another site) is working!

I found this out by checking the CDR records, it stated the calling device as a trunk, so as soon as I knew where to look, it was relatively easy to resolve.