Showing results for 
Search instead for 
Did you mean: 

Spontaeous New Calls When Call is Transferred

This is for CUCM 8.6 with 7945's with SIP image SIP45.9-3-1SR1-1S.

When internal call is placed and the called party goes off-hook then sometimes one or the other phone will spontaneously initiate a new call which puts the original call on hold.   Additionally, the new call immediately gets a reorder tone rather than a dial tone.

We have ruled out CTI manager/applications.

The only telltale in the CM logs is:

linkConsultativeCall unable to auto link primary call on line 1 - no call on feature hold|

for which we cannot determine the root source.

I have been doing Cisco UC/Collab for 15 years and have never encountered behavior like this.




any third party call control

any third party call control apps in the mix? jabber for X, lync, etc.?


I thought of call control

I thought of call control because they do have CyberTech call recording which has a CTI hook.  I performed tests with CTI Manager services stopped and the problem surfaced.

Here's more detail as to what is going on cluster wide.

  • The issue only happens about 50% of the time
  • Between the caller and called phones it varies as to which one has the spontaneous event
  • Only phones in one remote (g729) region show this behavior.

Aside from the statement that

Aside from the statement that the original call is put on hold, the symptoms sound a lot like a codec negotiation issue between the two phones. You say that a new call is initiated, do you see anything in the CM traces to indicate the destination of the new call? How do you know the original call is put on hold? Is there hold music? Do you see something in the trace to indicate the call is put on hold? 

I am thinking that we would need a more complete CM trace (Detailed level) before we can narrow down root cause. 



HTH -Bill (b) (t) @ucguerrilla

Please remember to rate helpful responses and identify


We know it's not a codec

We know it's not a codec issue and observe the symptoms directly because the two test phones are next to each other in adjacent cubes and in the same Device Pool/Region.   That said the issue only occurs with phones within this one Device Pool/Region.  The phones in the other 4 DP/R's are fine.  I filtered through the debug level traces and the only thing out of the ordinary is what was posted up top.

For the record everything has been reset and CUCM appliances restarted with no change in behavior.

Further, the cluster has been running for months with no changes in configuration.  This is a new issue which started occurring in the last two weeks.


Update:  TAC confirmed the

Update:  TAC confirmed the problem is relative to the the BIB  the fact whent it fails it causes the phone to behave badly.   We were provided ES firmware (SIP45.9-3-1ES27S)  which eliminated the bad behavior of the phones.

The root cause of the BIB failure is being triggered by a Cybertech NICE call recording system which has been having a lot of issues.   Needless to say most of the time its not recording any calls.


Discovered when BIB for call

Discovered when BIB for call recording duplicate media streams is turned off the problem goes away.  So in fact it might still be codec related.

CreatePlease to create content
Ask the Expert- Webex Hybrid Services Solutions