CUC Unable to transfer to an external number after Caller Input

[Joseph Rivera-Santiago]

We have a set of call handlers that direct calls based on caller input, i.e.:

1. Call external # for Office
2. Greeting plays
3. Caller chooses Option 1
4. Gets transferred to 2nd level call handler
5. Caller chooses Option 6
6. It then should get transferred to an external contact number

-Instead it plays the transfer greeting, "Please wait while I transfer your call", MOH plays, and then dead silence.

It does not ring, then you are forced to hang it up.  It's like the call gets sent (to the SIP router I am guessing), but never gets there or gets terminated on that end.

All other options within the handlers work (transferring to an internal extension, and transfer to an additional call handler)

Any help would be greatly appreciated, or any ideas on where else to troubleshoot.

[Nadeem Ahmed]

can you please tell what is the exact call fllow topology and dtmf method which you are using in your enviornment ?

1) how your CUC integrated with CUCM ? SIP or SCCP?

2)  How many GW what signalling is being used (MGCP/SIP/h.323)

3) how you are connected to PST (PRI/FXO/SIP)

Br,
Nadeem Ahmed

[Joseph Rivera-Santiago]

We have a 2851 CUBE for SIP, DTM is set to RTP-NTE

CUC is integrated to CUCM through SCCP

H.323 signalling

SIP connection to our PSTN provider

[lorenz84gDD]

try with a debug ccsip messages on the cube this way you can tell if the call gets there

[Joseph Rivera-Santiago]

When doing that and looking at the legs through Translator X, I am only seeing the call coming from my cell phone to the SIP.

I think the issue is CUC is unable to reach or transfer to the VM Pilot extension, as it is also failing to transfer from internal extensions.

For example:

User A - extension 10168

AutoAtt Handler - extension 54321

AutoAtt Handler #2 - extension 54322

10168 -> 54321 -> Greeting plays -> Choose Option 1 -> Transfers to Handler #2 -> Greeting plays -> Choose Option 6 -> "Wait while I transfer your call" -> Greeting plays

It doesn't ring, and becomes dead air, but the call is technically still connecting (timer is going)

[Vivek Batra]

How voice mail port CSS looks like?

Can it see the partition of number which is being dialed by CUC?

- Vivek

[Joseph Rivera-Santiago]

I attached a screenshot of one of the voicemail ports from CUCM

with your second question, I'm not sure I entirely understand, is there a way to test that?

[Vivek Batra]

Can you please let us know the number which you're expecting from CUC to outdial/transfer?

Do you have route pattern for that number in CUCM? (I'm assuming that one is external PSTN number).

Can HQ_Internal_CSS see the partition of respective route pattern?

- Vivek

[Joseph Rivera-Santiago]

So it's every external number, however the one I am trying to get to work is 855-981-1775

So if I take a look at Call Routing -> SIP Route patterns , there are no records found

But calls still make it out from CUCM -> SIP

How would I test if HQ_INternal_CSS can see that partition or any other for that matter

Thanks again for the help

[Vivek Batra]

Go to Call Routing -> Route Patterns and see if there is any matching pattern. If not, you need to configure it.

If already configured, check the partition associated with that route pattern.

Now go to Call Routing -> Calling Search Space and see if HQ_Internal_CSS has that partition assigned or not.

- Vivek

[Joseph Rivera-Santiago]

Ok was looking in the wrong place for patterns.  This was built before my time so it's a bit of digging and figuring out what was setup.

I attached another screenshot of all the route patterns we have configured, but I see some of them are the same patterns, just different descriptions and different partitions.

For testing purposes, to see if this is where the issues lie, could I create a new partition just for that number I listed above and a new partition, and add it to the HQ_Internal_CSS group?

I think we are definitely on the right track

[Vivek Batra]

From attached screenshot, I can't see any route pattern matching 855-981-1775. Maybe it's not displaying all route patterns.

Yes, definetly if you can do this, it will be easy to troubleshoot. Create new partition, new route pattern with number as 8559811775 and assign that partition to HQ_Internal_CSS. Just ensure keep that partition on the top. Since I'm not aware about your dial plan already configured, I assume this won't impact your production environment.

Also take care to assign appropriate route list to respective route pattern.

- Vivek

[Joseph Rivera-Santiago]

It's definitely displaying all 24, I had it set to display 250 just in case.

So if theres nothing matching that number....

We dial 9 to "get out", so would the pattern be 98559811775 or just 8559811775?

What is the purpose of keeping that partition on the top?

Again many thanks

[Vivek Batra]

What I said is there is no matching for 855-981-1775 but if you dial 9 as prefix, yes there are matching RP in your system.

Before adding new RP, just change the number in CUC from 855-981-1775 to 98559811775. Verify if call is hitting back to gateway or not.

Else do what we decided before.

I told to add new partition on the top to ensure when CUC dials that number, respective route pattern should get matched in case of conflicting entries.

- Vivek

[Joseph Rivera-Santiago]

Ah ok that makes sense.

CUC already has the 98559811775 as the ACN to dial.

It's definitely grabbing the new pattern and partition now, DNA shows that, it also shows to RouteThisPattern

If you want to call:

2523170388

Option 1

Option 6

You will see what I am running into in more detail