Transferred calls drop

Unanswered Question
Jun 25th, 2009

I have just performed a clean install of our UC500 with CCA 2.0 and software upgrade package 7.0.3. The system is set up as a Key System with the CO Lines configured on everyones phone, along with their primary internal extensions. It was conifgured completely using the CCA.

Recently, we have had calls drop when they are answered on an outside line, and transferred to an internal extension. The call drops right when the internal extension that it is being transferred to picks up. It does not occur every time, kind of hit and miss.

Any ideas why this could be happening, and why it seems to be random?

Thanks,

Derek

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
David Trad Thu, 06/25/2009 - 14:39

Hi Derek,

Can you provide a "debug vpm signal" and a "debug voice ccapi inout" please, i know this will be hard given the randomness of the problem, but if you can capture the details of when it does happen it certain will go a long way with narrowing down on the issue.

I have had this problem once before, i would be interested to see if you are experiencing the same problem as the symptoms sure look the same.


What specifically happens when the ext the call was transfered too picks the phone up?

  1. Is it dead air
  2. Busy tone
  3. Nothing, the phone looks the same as if you were picking it up to dial-out and make a call

Any further information you give would be great.

Cheers,

David.

Derek Thom Thu, 06/25/2009 - 15:19

I'll try those debug commands and try and watch for when it happens. How do you check the debug outputs if you aren't logged into the system when they occur?

IIRC, when the extension picks up, it's almost like they picked it up to make a new call, with a dial tone. But you can clearly see the outside line lit up and the ringing on the extension, then everything goes out when you pick up the phone, and then there is the dial tone.

I'll try and get more specifics.


Thanks!


Derek

Derek Thom Wed, 07/01/2009 - 08:31

Still experiencing this issue. I have the debugs turned on, but I don't have the CLI open when the transfer drops. Is there a way to view the debug outputs in a log format? I am familiar with the CLI, but have not done much with debug's.


Anyone else have any suggestions on why this might be happening?

Thanks,

Derek

Skyler Spence Wed, 07/01/2009 - 10:54

To log the debug output, enter the following command in configuration mode

(config)#logging buffered debugging

then to see the logs, type the following command in enabled mode

#show logging

Derek Thom Thu, 07/02/2009 - 14:42

Thanks, now that I have it logging I will check it after a call drops. Kind of a frustrating practice, since every call is an important one.

Just out of curiosity, since this is something I had a problem with in past setups running older IOS and CCA version, should I be able to call transfer with the UC being set up as a Key System? From what I understand, this creates trunks, and calls coming in on trunks can't be transferred to internal extensions. In the past, when I set up Key Systems, the transfer button would be grayed out and unusable. Now, that's no longer the case, so I thought maybe this issue had been resolved and is useable. But, maybe this is the problem?

I set the whole system up with the CCA specifically to avoid any potential conflicts or pitfalls, but I'm thinking this may be an issue.

Any input?

Thanks,


Derek

Derek Thom Fri, 08/20/2010 - 12:34

OK, client UC520 has the latest software pack installed (8.0.2) and this issue persists without any change, calls still drop when transferred.

I have been able to replicate the issue, so I am able to post the debugs that were requested a while back (see attached). To replicate it, I can just call in on their main number, have the receptionist pick up and then transfer to any phone. The transfer goes through fine the first time. If I call right back, go through the same process, and the call is dropped as soon as the receptionist hits transfer or hangs up. All parties drop to dead air.

I really need to get this figured out, so any help would be appreciated.

Thanks!

Derek

John Platts Thu, 07/02/2009 - 15:28

I have noticed this problem with the IOS 12.4(20)T2 release. I have not seen this problem in the 4.2.x/12.4(11)XW or the 7.1.x/12.4(11)YB releases. Upgrading to the 7.1 early adopter release might fix this problem.

ssiadmin01 Fri, 07/03/2009 - 03:19

Same problem here, i get calls dropped when transferring to an external number, as soon as remote party answers,  call is ended, also was running 7.03 pack i.e. 12.4(20)T2 but ran into system crash due to memory leak bug, Cisco Said:

I have analyzed and decoded the traces related to the crash ,and I found that you are hitting the following BugID:CSCsu04107:Traceback @ cce_dp_ec_classify_out_targets on applying policymapExternally found moderate (Sev3) bug: R-Resolved

Hence was advised to upgrade IOS, have upgraded to 12.4(22)T

Wonder if theres bugs in 12.4(22)T and tranferring calls??

Poor client, only has had this UC520 a week, first system crashed and now this call transfer issue

ssiadmin01 Tue, 07/07/2009 - 05:03

FIXED my issue, turned out to be the dspfarm transcode, when the two calls were setup one negotiated G711alaw and the other G711ulaw, hence the phone rang but as soon as picked up both calls disconnected, the dspfarm transcode only had the following setup by CCA 2.0:

dspfarm profile 2 transcode 

description CCA transcoding for SIP Trunk Generic SIP Trunk Provider

codec g711ulaw

codec g729abr8

codec g729ar8

maximum sessions 2

associate application SCCP

so simply added codec G711alaw (UK G711alaw is a must!, should really be included with region settings in CCA in my opinion!)

the following debug commands were quite usefull, (must have debug buffered 100000 at least):

debug ccsip all
debug voip ccapi inout
debug voip vtsp default
debug voip vtsp session

jimi.friis Thu, 07/16/2009 - 03:45

Hi ssiadmin and others,

My customer are having the same problem with call transfers randomly not working.

example:

External (A ) call is incoming to the receptionist (B) who transfers the call to the internal number (C)

Sometimes it works fine and sometimes B will only hear an "error tone" when calling C.

-------------

My customer is running the following software:

Cisco IOS Software, UC500 Software (UC500-ADVIPSERVICESK9-M), Version 12.4(22)T, RELEASE SOFTWARE (fc1)

and the dspfarm is:

dspfarm profile 1 transcode 
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 10
associate application SCCP

------------

Does anyone know about this issue?

Thanks,

Jimi

ssiadmin01 Thu, 07/16/2009 - 04:29

Hi Jimi

I think you have slightly different issue, transferring internally from an external caller, i would suggest you run the debugs as per my last post, if you have TAC support log it with them, post your debugs ill have a looksy too

also what do you have for call-transfer under telephony-service? e.g. transfer-system full-consult dss?

also do a show ephone and see if both the secretary phone and transfered phone are using the same prefered codec (if different then it would point to issues with transcode, but generally should be G711)

also just internally do call transfers and see if this works?

one more thing, are you using a sip trunk or PSTN ?

jimi.friis Thu, 07/16/2009 - 05:28

Thanks for the fast reply.

call-transfer setting: transfer-system full-consult dss

The connection is a SIP trunk.

All phones are using g711ulaw; I don´t know why it is set up like this as I think it should be g711alaw since the location is in Sweden.

I´m planing on doing some tests tomorrow on site and I will send my logs to TAC and I will post my results and feedback here.

//Jimi

jimi.friis Fri, 07/24/2009 - 09:28

My  (customers) problem with transfered calls are a little mysterios and neither I nor the TAC could find anything in the debugging and configuration.

I suspect that the problem could be that the phonenumber to recieve the transfered call was not registered (logged in) at the time and therefore the transfering person will get a "unknown number" error.

- If a number is not "registered" call-forwarding from internal numbers are not working; the guy at Cisco TAC told me that this is a limitation in the CME and first he tried to make a workaround but it didn´t work. I will continue my search for a solution. Because it is working from external calls I think there has to be a work around to get the call-forwarding to work on the inside (internal calls) even if the number at the time is unregistered.

If anyone know a work around, please... let me know.

Thanks,

Jimi

Marcos Hernandez Mon, 07/27/2009 - 04:32

If by "unregistered" you mean the IP phone is not active, then that call should just go to voicemail, assuming there is a voicemail box for that user and that call forward to voicemail is configured under the DN being called (or being the recipient of the transfer). What is you ephone-dn configuration?

Thanks,


Marcos

jimi.friis Mon, 07/27/2009 - 05:25

Hi Marcos,

Yes that is correct, the IP phone is not active. Voicemail is not in use and the ephone-dn look like this:

ephone-dn  119  dual-line
number 519 no-reg primary
description 519
name Jimi
allow watch
call-forward busy +46*********
call-forward noan +46********* timeout 10

When trying to make a workaround for this I configured the following (as recommended by TAC):

ephone-dn  119  dual-line
  number 519 no-reg primary
  description 519
  name Jimi
  allow watch
  call-forward busy +46*********
  call-forward noan +46********* timeout 10

> no huntstop ! i forgot this line here, but it was used in the config.

ephone-dn  157
number 519 no-reg primary
description forward when not logged in
preference 1
call-forward all +46*********

But this didn´t work either.

Thanks,

Jimi

David Trad Mon, 07/27/2009 - 05:02

Hi Jimi,

I am curious, can you provide some details please:

  • What Firmware are you using for the phones
  • Are your DN's setup as Dual-Lines? Octo-Lines or Single-Line setup??
  • Are you forcing any particular codec at any stage of the call progress?
  • on the CLI when you do "sh ephone reg" and "sh ephone unreg" what happens? do the values change intermittently?
  • Are you willing to upgrade the system to EA-7.1.1?
  • Is the problem predominantly from external calls coming into the system or does it happen with internal calls as well?
  • Does the call drop immediately or after a short period I.E 20 seconds?

If a number is not "registered" call-forwarding from internal numbers
are not working; the guy at Cisco TAC told me that this is a limitation
in the CME and first he tried to make a workaround but it didn´t work.
I will continue my search for a solution. Because it is working from
external calls I think there has to be a work around to get the
call-forwarding to work on the inside (internal calls) even if the
number at the time is unregistered.

See its this part that is confusing me, i need to try and understand more how the system is setup because your problem is jut not making sense, can you explain the call transfer process?

Example:

BOSS RECEPTION METHOD

Call comes into Ext-100, Ext-100 calls Ext-101 by pressing the transfer button, Ext-101 says yes i will take the call and then Ext-100 presses transfer again, if the answer is a no, Ext-100 resumes the call.

BLIND TRANSFER METHOD

Call comes into Ext-100, Ext-100 Then presses transfer >>> Extension Number >>> Transfer button and hangs up (or if it is coming from a single line phone just pressing the transfer button once).

When does the call drop out, at which point and how does it drop of? do you see the circuit tare down on the CLI?

If the problem happens again, what happens if you press hold immediatly after the call drops and then press resume let me know if the call resumes again or of the circuit has been torn down fully.

I have seen this problem quite a few times, or something of a similar nature, but all but one was configuration issue, one was a DSP problem and the box was swapped out, the others was just bad configuration, and if you used CCA to build this system there might be some unknown bug in 2.0.1 that has not been identified yet.

Can you post the full config of the system that is effected, and also a capture of the "sh ephone phone" command as well ? *Make sure to remove all sensitive data).

I am a little set back by the comment of the TAC staff, did you get a report from the TAC staff member of what was done or what config changes were made? I normaly ask them to note any changes they have made, what the configuration udpates were, why they did them, what it was supposed to achieve and then e-mail me a report before the case is closed off, i ask this for 2 reasons, first so i can learn and understand, second is i like to run a change log even thought i create a new running config txt file with a new date, but the first one is vital and highly important for me so it is a must for me when i request TAC support.

I hope we can sort your problem out.

Cheers,

David.

Marcos Hernandez Mon, 07/27/2009 - 05:37

Well, you are transferring to an internal extension, but in reality what you want to do is hairpin the call back to the PSTN. This changes the call flow completely. What happens if you try to transfer to that external number directly? I realize with the e.164 formatting (plus sign) some digit manipulation is required to make the number "dialable", but have you tried such a direct transfer? I suspect the problem is on the PSTN side (which does not mean the problem is "with" the PSTN). I am assuming this is a SIP trunk. Do you have "debug ccsip messages" available for a failed call?


Thanks,

Marcos

jimi.friis Thu, 07/30/2009 - 08:27

Hi Marcos,

Yes if I transfer directly to the external number it will work, but I want this to work for the extensions so that:

1. people don´t have to look up numbers when doing a transfer. this works as long as the user have registred the phone.

2. the transfer will work even if the user have not registred.

Thanks,

Jimi

Marcos Hernandez Thu, 07/30/2009 - 08:43

I completely understand the call flow now and we will make it work. To start, can you please add the following to the ephone-dn that is assigned to the phone:

no huntstop

Then, make sure that you have another DN that looks exactly the same, but has higher preference. In essence, the same thing that TAC recommended you to do, but with that extra "no huntstop" command under the primary DN.

Let me know,


Marcos

jimi.friis Thu, 07/30/2009 - 11:19

Hi Marcos,

I have been trying those changes and it didn´t work but I am pretty close to the solution (I think/hope)



I removed the "no huntstop" since it didn´t do any difference.

What I would like to do is to translate the number "00709******" to "+46709******" before it goes to the dial-peer, but I understand if that is not possible.

This is the closest I got in the configuration.
With this configuration the call-forward works in the following conditions
1. ephone is not registred and calls are from internal numbers
2. ephone is registred and calls are from external numbers
Confusing? Well for me it is...



! ONE OF THE DN´S USED FOR TESTING
ephone-dn  155  dual-line
  number 655 no-reg primary
  description +468*****655
  name Jimi
  allow watch
  call-forward busy 00709******    ! THIS WILL BE USED WHEN THE EPHONE IS NOT REGISTRED !
                                 !THIS HAS TO BE WITHOUT "+46" TO WORK IN INTERNAL TRANSFERING AND FORWARDING
                                 ! BUT IT IS NOT WORKING WHEN  THE CALLS ARE FROM OUTSIDE, UNLESS IT USES THE "+46"
 
  call-forward noan +46709****** timeout 10    ! THIS WILL BE USED WHEN THE EPHONE IS REGISTRED
                                             ! THIS WORKS FINE WHEN THE CALL IS COMMING FROM THE OUTSIDE, NOT FROM INSIDE


! TRANSLATION-RULE USED IN translation-profile sip-outgoing
voice translation-rule 11
rule 1 /^0\([2-9]\)/ /+468\1/
rule 2 /^0\(1[2-9]\)/ /+468\1/
rule 3 /^000\(.*\)/ /+\1/
rule 4 /^00\(.*\)/ /+46\1/
!

! TRANSLATION-PROFILE USED IN dial-peer voice 11 voip

translate calling 10
translate called 11    ! translation-rule 11, rule 4 WILL TRANSLATE
                        ! "00709******" TO "+46709******" SINCE THIS NUMBER HITS THE DESTINATION PATTERN
                        ! "0T" IN dial-peer voice 11 voip

! THE DIFFERENCE BETWEEN THE dial-peers IS THE COMMAND b2bua IN dial-peer voice 11 voip
! AND clid network-provided IN dial-peer voice 13 voip,
! IS THE b2bua NEEDED?
! COULD I USE THE clid network-provided IN dial-peer voice 11 voip, AND WOULD THIS SOLVE ANYTHING?

dial-peer voice 11 voip    ! USED FOR ALL USER INITIATED CALLS
translation-profile outgoing sip-outgoing
destination-pattern 0T
b2bua
voice-class codec 1
voice-class sip asserted-id pai
voice-class sip profiles 1
session protocol sipv2
  session target sip-server
dtmf-relay rtp-nte
fax protocol pass-through g711alaw
no vad
!

dial-peer voice 13 voip    !USED FOR CALL-FORWARD WHEN USER IS NOT LOGGED IN TO PRESERVE ORIGINATING NUMBER
destination-pattern +4T
voice-class codec 1
voice-class sip asserted-id pai
voice-class sip profiles 1
session protocol sipv2
session target sip-server
  dtmf-relay rtp-nte
fax protocol pass-through g711alaw
clid network-provided
no vad
!

Thanks,

Jimi

Marcos Hernandez Tue, 08/04/2009 - 19:14

Hi Jimi,


It is possible to translate the call before it hits the dial-peer. One alternative is to try this global CLI:

UC520(config)#voip-incoming ?              
  translation-profile  Translation profile
  translation-rule     Global digit manipulation and translation

Give that a try and let me know if it works for you.

Thanks,

Marcos

jimi.friis Fri, 08/07/2009 - 02:38

Hi Marcos,

Could you please tell me if this looks right? I don´t want to mess to much with the system without being sure that I can test this and still only affect myself.

Objective:
Translate called number 008588001 to +468588001

before hitting the dial peers so that the call will hit the "dial-peer voice 13" instead of "dial-peer voice 11"

! ! Configuration idea ! !

voip-incoming translation-profile ADD46
!
voice translation-profile ADD46
  translate called 4646
!  
voice translation-rule 4646
rule 1 /^008588\(.*\)/ /+468588\1/
!
!
dial-peer voice 11 voip
translation-profile outgoing sip-outgoing
destination-pattern 0T
b2bua
voice-class codec 1
voice-class sip asserted-id pai
voice-class sip profiles 1
session protocol sipv2
  session target sip-server
dtmf-relay rtp-nte
fax protocol pass-through g711alaw
no vad
!
dial-peer voice 13 voip
destination-pattern +4T
voice-class codec 1
voice-class sip asserted-id pai
voice-class sip profiles 1
session protocol sipv2
session target sip-server
  dtmf-relay rtp-nte
fax protocol pass-through g711alaw
clid network-provided
no vad

! end

Thanks,

Jimi

jimi.friis Sat, 08/08/2009 - 10:22

Thanks Marcos!

"Unfortunatly" I´m going on vacation untill the end of August, I´ll get back here when I have tried the config.

//Jimi

ssiadmin01 Mon, 07/27/2009 - 06:45

Do you dial "9" to get on outside line\activate outbound dial peer?

try call-forward all 90046*******

David Trad Mon, 07/27/2009 - 15:12

Hi Jimi,

call-forward busy +46*********
call-forward noan +46********* timeout 10

I am curios if you have tried the following:

REMOVAL OF THE + SYMBOL WITH THE ADDITIONM OF THE "0" TO GET EXTERNAL LINE

ephone-dn  119  dual-line
  number 519 no-reg primary
  description 519
  name Jimi
  allow watch
  call-forward busy 046*********
  call-forward noan 046********* timeout 10

Or this way

REMOVAL OF THE + SYMBOL WITH THE ADDITIONM OF THE "9" TO GET EXTERNAL LINE

ephone-dn  119  dual-line

ephone-dn  119  dual-line
  number 519 no-reg primary
  description 519
  name Jimi
  allow watch
  call-forward busy 946*********
  call-forward noan 946********* timeout 10

I am not in the UK so i couldnt be certain but i have never seen a case where the + symbol needs to be used, even with an ITSP service if not PSTN or ISDN, if i am not mistaken the + Symbole would be removed unless otherwise stated in the translation profile, and if it was required by the Service provider.

In both examples above i have assumed that you either dial "0" for an outside line, or you dial "9" for an outside line, either way if you are call forwarding to an external number then you need to make sure it is getting an outside line, unless of course you have configured your system for direct outbound dialing with not leading numbers.

Again i hope i have not misunderstood what you are doing or what you wanted, and i hope the above can resolve your problem.

Cheers,

David.

jimi.friis Thu, 07/30/2009 - 08:16

Hi David,

Yes I did try that but it is not working, acctually I think the problem is somewhere else since it will not work even if I configure the call-forwards to an internal extension.

Example:

Ext-655 is trying to call Ext-519

519 is not registred so calls should be forwarded to Ext-520

But 655 only gets the "unkown number" text in the phone and the signal is short beeps (like when the call is not working).

If Ext-519 is registred and do not answer the call, then the call will be forwarded to whatever number i want, +46********* or Ext-520

If the call is from the outside the call-forward do work.

The debug file is for a call from 655 to 519 when 519 is not registred.

Thanks,

Jimi

Derek Thom Fri, 08/13/2010 - 11:16

I am resurrecting this thread because I am still having the same issue as my original post, this time with a client of ours. The "fix" for me last time was to change the transfer system to "full-blind", which worked in our office here and people have learned to use it that way. However, for our client this is not acceptable, they want the "full-consult" transfer system.

The problem is essentially the same as we have in our office here. When a call comes in on an outside line, and they attempt to transfer it to another (internal) extension, the consult comes through but as soon as they go to hangup to comeplete the transfer (or even just press the transfer button again) the call is completely disconnected, the internal extension just gets dead air.

The e-phones are set up as dual line, and once again I let CCA do all of the configuration with no "out of band" modification via the CLI. They are running an older software version and I am currently downloading the 8.0.1 package to upgrade them to the latest, though I have some doubts as to whether or not this will fix it. Since no one else really seems to have this issue that I can tell (from the lack of other posts on the internet describing similar issues) I have a feeling it is something I have wrong in the config, but I can't narrow it down.

Any help that can be provided is appreciated. I can provide "show run" outputs, etc. as needed.

Thanks,

Derek

Actions

This Discussion