Unity Call Flow to CUCM with Transfer to Alternate Contact Number

[Bob_IA]

I inherited a 2-node Unity Connection cluster and a 2-node CUCM cluster which have the SCCP connections between them.  I'm trying to understand how the Unity servers determine how to pass Transfer to Alternate Contact Number calls to the CUCM cluster. I see the call come in the PSTN SIP trunk on my CUCM Subscriber and then on to Unity, but when they press a number for Transfer to an external 1-888 number it wants to use the CUCM Publisher, which in our current telco connectivity configuration means callers have issues with outbound audio/DTMF being recognized and can't select options on the external entity's call handler.  If I can get it to register with the CUCM Subscriber then the call flow should be "correct" and allow 2-way data.  Eventually we'll put in SBCs to remove the limitation, but this is the "get it working" version for now. 

I did try changing the priority for the Unity ports to CUCM, and the order of the servers in the Port Grouping to no effect.  If anyone has some insight I'd appreciate it.  Found it harder to find the info so far, so even a reference doc would be handy.

Thanks, Bob

[Brad Magnani · Accepted solution]

Hi @Bob_IA
Unity will check the phone system configured on the object doing the transfer and use the port group associated, to place that outbound call.  You'll want to make sure your server list in the SCCP Port Group (ex: sub1,sub2) match the exact order of the servers in the CM Group assigned to your VM ports (via the Device Pool assigned).  If you make changes in CUC, or CUCM in that area, it's not a bad idea to both restart the Port Group and if you still continue to see the transfers go to the wrong CUCM node, you can restart Conversation Manager.  This normally isn't necessary though, I'd be curious to know how you confirmed the transfers out of CUC are going to the publisher despite the pub being removed from the port group on CUC.   

[Bob_IA]

Okay, so I will confirm the listing order on both sides as I hadn't considered that.  I didn't remove the Publisher from the Unity List, just reversed their priority (Making the Publisher 1 and the Subscriber 0).  I will say I made changes just to the Unity side and then restarted the Conversation Manager only.  I can make my changes and restart both entities/services in the morning before we get busy. 

The way I was seeing the traffic was with RTMT in Trace and Log Central's calllogs monitor; just had it pointed at the Publisher or Subscriber and ran the same call and key press actions. 

I sure to appreciate the input!

[Maren Mahoney · Accepted solution]

First, in the Port Group for your SCCP ports under "Servers" are only the call processing nodes (and not the Publisher) listed? If the Publisher is listed and is first, then outbound connections will use that. Only call processing nodes should be listed in the Port Group.

Also, it is best practice to list the call processing nodes from the CallManager Group associated with the ports' Device Pool listed as 1-2-3 on the Port Group Servers in CUC and wait for the ports to re-register. And I agree with @Brad Magnani that after a change is made to the servers on the Port Group restarting the Conversation Manager is needed.

If you changed the priority, did you also reset both the SCCP ports in CUCM *and* reset the Port Group in CUC?

If all of this is okay, then we need to look deeper.

Maren

[Bob_IA]

With our 2-node CUCM both the one Publisher and one Subscriber are listed in the Unity Port Group; the Publisher having the 0 priority and and Subscriber at 1.  I had flipped their priority, found no change so I reverted.  I'll do that flip again, restart the Conversation Manager and reset the Port Group.  I suspect we have the Publisher in there for failover, that setup comes from the days of a 3rd party running our system >6 years ago so that's just a guess by me.  

Much obliged!

[Maren Mahoney]

If both your Pub and your Sub are call processing nodes, then they can (and should) both be in the Servers list. Whichever is listed first in the CM Group in the DP should be the 0 server and the other the 1 server.

If the outbound calls work when processing through the Sub, but not the Pub, the answer may be in CUCM and not in CUC. CUC doesn't really care from its end, and I presume your SCCP ports are all configured identically.

On your router-gateway-cube (which do you have?) are you using a single set of dial-peers with a server-group listing both CUCM nodes, or do you have two separate sets of dial-peers listing the Pub and the Sub separately? If they are separate, are they configured identically for things like DTMF relay?

What about the trunk on the CUCM side to the gateway? Do you have more than one gateway and therefore more than one trunk and if so are they configured identically?

Do the Pub and the Sub have access to the same Media Resources (via an MRG/MRGL structure), or are your media resources wide open? If they are wide open, do you have the same media resources available on both? (I'm pondering if there is a DTMF-relay issue that the Pub might be trying to use an MTP where the Sub does not need one.)

In the end, if we are unable to find the culprit we would need you to pull the trace files for a working and for a non-working call so we can determine what the problem is. Trace files will point us to the problem.

Maren

[Stefan Mihajlov · Accepted solution]

@Bob_IA 

Unity Connection doesn’t really “choose” Publisher vs. Subscriber the way CUCM trunks do — it uses its SCCP port groups. Each port group has a list of CUCM servers, and Unity will register each SCCP port with the first server in the list that’s reachable. When Unity then needs to place a transfer call, it seizes a port that’s registered, so if those ports are tied up on the Pub you’ll see all transfers hairpinning there.

To fix the behavior short-term, make sure in Cisco Unity Connection Administration → Telephony Integrations → Port Group you’ve got the Subscriber listed first in the server list, then reset the port group so all Unity ports register to that Subscriber. That way new transfer attempts will originate there instead of the Pub. If you want redundancy, leave both nodes in the list, but put the one with the working SIP path at the top.

Longer term your plan is right — once an SBC is in place you won’t care which CUCM node initiates the call. For now though, ordering the CUCM servers in the Unity Port Group is the lever you have.

Best regards,
Stefan Mihajlov

Mark this post as Helpful if it helped you, and Accept as Solution if it resolved your question.

[Bob_IA]

Thanks everyone, I was able to get the Subscriber to be the first choice for Unity and the call now hits it as first choice.  Seems like I must have a DTMF issue as well, because now the one external destination that has a voice recognition system works when it didn't before, but the number presses aren't getting there.  I'm guessing it's an In/Out of Band issue, but for the question I had you all were great!