Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Consult Transfer problem after CCM upgrade from 3.3.4 to 4.1.3

I upgraded a CCM Cluster installed into a main site. In addition there is a branch office WAN connected by an MPLS Link with the main site; the branch is connected to PSTN using a Voice Gateway H323. The upgrade was perfomed from 3.3.4.sr2 to 4.1.3sr3a.

Now there are problems with consult transfer only on the branch office; main site don't is affected by the problem.

It's really strange because it occurs for 50% of the time, sometimes it works fine ..

To better explain the problem:

when a user receive a call from PSTN or from another phone (into same region or remote) and want to transfer to another collegue he press "transfer softkey", talk with the collegue and when he try to transfer the call "transfer softkey" appear disabled. If he transfer the call without consult the call is transferred correctly.

Later I have unistalled the 4.1.3 sr3a and installed 4.1.3 sr2 but nothing is changed

Someone can help me ?

6 REPLIES
New Member

Re: Consult Transfer problem after CCM upgrade from 3.3.4 to 4.1

When the user goes to transfer the call is another call ringing at the phone? The only reason I ask is that the phone will give priority to the new incoming call over the call that you are trying to transfer. Press the down arrow on the phone and the transfer options will come back.

Green

Re: Consult Transfer problem after CCM upgrade from 3.3.4 to 4.1

Voice Gateway H323, does your gateway config has MTP checkbox enable?

Have you chec if using FastStart or SlowStart for incoming calls?

You may post CCM|SDL detailed trace when problem happens.

//G

New Member

Re: Consult Transfer problem after CCM upgrade from 3.3.4 to 4.1

Did you ever resolve this? I have a customer with this exact same issue. Please post resolution status if you have one.

Thanks!

Hall of Fame Super Red

Re: Consult Transfer problem after CCM upgrade from 3.3.4 to 4.1

Hi Brent,

Do you perhaps have "on hook" transfer enabled? With this enabled you don't need to press the Transfer key a second time to complete the transfer.Have a look:

•When on-hook transfer is enabled, you can either hang up or press Trnsfer, then hang up.

•If on-hook transfer is not enabled on your phone, be aware that hanging up instead of pressing Trnsfer cancels the transfer action and places the party to be transferred on hold.

Onhook Call Transfer

Modifications to the Call Transfer feature add the onhook (hangup) action as a possible last step to complete a call transfer. The Transfer On-hook Enabled service parameter, which enables onhook call transfer, must be set to True for onhook call transfer to succeed. If the service parameter is set to False, the onhook action ends the secondary call to the third party.

In the existing implementation, if user B has an active call on a particular line (from user A) and user B has not reached the maximum number of calls on this line, the Cisco IP Phone provides a Transfer softkey to user B. If user B presses the Transfer softkey (or Transfer button, if available) once, user B receives dial tone and can make a secondary call: user B dials the number of a third party (user C). Cisco CallManager provides a Transfer softkey to user B again. If user B presses the Transfer softkey again (or Transfer button, if available), the transfer operation completes.

With the new onhook call transfer implementation, user B can hang up after dialing user C's number, and the transfer completes. Both the existing and new implementations work in both the case of a blind transfer (user B disconnects before user C answers) and also in the case of a consult transfer (user B waits for user C to answer and announces the call from user A).

The previous implementation remains unchanged: user B can press the Transfer softkey twice to complete the transfer.

From this doc;

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00803edb46.html#wp1088627

Hope this helps!

Rob

Please remember to rate helpful posts...........

Bronze

Re: Consult Transfer problem after CCM upgrade from 3.3.4 to 4.1

Hi,

with ccm 4.1.2 there is a new feature called "External Call Transfer Restrictions".

In previous releases, no configurable option existed to define a call as OnNet (internal) or OffNet (external). Cisco CallManager release 4.1(2) now provides that flexibility at the individual gateway, trunk, and route pattern levels. It also provides a global setting for gateways and trunks.

Cisco CallManager classifies incoming and outgoing calls on the basis of the following settings:

•An incoming call gets classified as OnNet or OffNet based on the setting that is configured on the gateway through which the call came into the network.

•An outgoing call gets classified as OnNet or OffNet based on the route pattern setting that is used to route the call out of the network.

Cisco CallManager 4.1(2) provides the ability to block OffNet to OffNet transfer that can be enabled by using a clusterwide service parameter, ***Block OffNet to OffNet Transfer****; this field appears under the clusterwide service parameter (Feature - General) in the Service Parameters Configuration window. This new service parameter replaces the ***Block External to External Transfer service parameter***.

During upgrade to Cisco CallManager 4.1(2), the new parameter replaces the old service parameter, and the old value (true or false) gets set to the new parameter value.

hope this helps

greetings

mehmet

New Member

Re: Consult Transfer problem after CCM upgrade from 3.3.4 to 4.1

Guys -

Thanks for the input - but I don't think any of those suggestions are causing the issue. To answer the question "Do you perhaps have "on hook" transfer enabled?" No, we don't. As for the "Block OffNet to OffNet Transfer" , it is set to false - the default setting. In fact, almost every service parameter is the default, including our h.323 gateways (all of them are h.323, fyi) so that means we also do not have "mtp required" either. Anything else we could look at?

Thanks.

165
Views
0
Helpful
6
Replies
CreatePlease to create content