cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
390
Views
5
Helpful
4
Replies

2nd Hop transfers

tom
Level 1
Level 1

Software Version: CUCM 4.2(3)sr4a

2 Gateways MGCP

This is the scenario.

A call comes from outside of the organization to 76xx to CTI to a receptionist 47xxx. Then call is transferred to the bosses receptionist at DID 7665. Then the bosses receptionist tries to transfer to the boss at DID 7612. The call is dropped and the original caller gets a message from our PRI provider AT&T (all circuits are busy).

This scenario has been tried with many different phones in the same location with the same results.

Further information as follows:

This situation may have been going on since the original Cisco CM install (not sure)

The configuration may have been designed this way to prevent toll fraud

This is a Secured Facility

All internal transfers work flawlessly

1st Hop transfers work fine for example, calls from the outside to bosses receptionist and then to the boss work just fine.

Bosses receptionist phone has been replace with a new one as a precaution

Other thoughts:

Could this be a mismatch in CSS on the involved phones?

Could this be a device pool issue?

Could this be a dial plan issue?

Could this be a Route Pattern issue?

Could this be a Gateway issue?

Does this scenario sound familiar to anyone?

Any thoughts or observations will be appreciated

4 Replies 4

Rob Huffman
Hall of Fame
Hall of Fame

Hi Tom,

That is a "strange" one for sure. Just for testing purposes

can you check this parameter in CUCM;

Set the Block OffNet to OffNet Transfer  clusterwide

service parameter to False and try the test again.

Cheers!

Rob

Rob

I checked this setting and it is already set to FALSE

Block OffNet to OffNet Transfer

Thanks, Tom

Rob,

I thought I owed you an update on this. You have helped me out several times in the past.

It turns out all this maybe due to an ISDN protocol mis-match.

DMS-100 versus the NI2 protocol.

The original CM installers used the DMS-100 protocol on the Cisco 2851 Gateway because they said the NI2 protocol did not work and would not allow calls through.

What makes matters worse on the Provider side ATT they are using the NI2 protocol.

I am going to make the change and see what happens. Also, here is a TRACE I preformed on the Gateway during a test call.

Best Regards, Tom

Rob Huffman
Hall of Fame
Hall of Fame

Hey Tom,

Thanks for posting back my friend +5 for sharing this update.

This makes sense, and I'm kind of surprised other things don't work

properly with this protocol mis-match. We use DMS100 on our gateways

and our telco uses DMS100 from their end as well. The testing I did when

you first posted up this issue did not produce any problems with the 2nd hop

Transfer in any way.

Cheers!

Rob

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: