cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1866
Views
0
Helpful
10
Replies

Incoming call gets forwarded to external number doesn't disconnect after call ends

steven-lau
Level 1
Level 1

Hi everybody,

I am implementing a small setup for a customer with the UC520 and about 8 IP Phones. So far we have this problem where the customer wants to call forward all calls to their mobile when they are not in the office. This works fine with internal calls to their extension, but once an incoming call is forwarded, the line dosen't disconnect after the call ends.

I suspect it has something to do with the disconnect tone, but the issue only occurs in the above senario. I have already enabled "supervisory disconnect dualtone mid-call" on the FXO port with no success.

voice-port 0/1/0
trunk-group ALL 58
supervisory disconnect dualtone mid-call
cptone SG
timeouts call-disconnect 3
timeouts wait-release 3
connection plar opx 511
caller-id enable

This project is in Singapore.

Any help is greatly appreciated.

Thanks a lot in advance

Steven

10 Replies 10

David Trad
VIP Alumni
VIP Alumni

Hi Steven,

Can you confirm something for me please.

Does the actual port lockup or does the line lockup? This is quite important, if the Port is locking up then it may be resolved but with a very small chance, maybe 10-20% chance of resolving that issue.

However if it is just that the circuit is not getting torn down, then we have more options to explore and various ways to resolve the issue.

If you have CLI Experience can you run some debugs on a forwarded call to a mobile service, and capture the VPM signal debug, on top of that can you capture the port status so we can see if it is a hung port issue.

I await your feed back.

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

Hi David,

Thanks for your reply.

I have run a few tests and found that the problem occurs with incoming calls routed to external numbers.

The situation is that I have 4 FXO lines, incoming call will occupy one FXO port. As the call is forwarded to an external number, another FXO port will be occupied.

After the call ends, both FXO ports are still in use (the lights for these FXO ports remain lit). I have to physically disconnect these cables to solve the issue, disconnecting one cable will release both lines.

I have attached the debug output for the VPM Signal, but I am not too sure how to capture the port status.

UC520#
000137: Jun  5 03:36:28.858: htsp_process_event: [0/1/0, FXOLS_ONHOOK, E_DSP_SIG_0000]fxols_onhook_ringing
000138: Jun  5 03:36:28.858: htsp_timer - 125 msec
000139: Jun  5 03:36:28.986: htsp_process_event: [0/1/0, FXOLS_WAIT_RING_MIN, E_HTSP_EVENT_TIMER]fxols_wait_ring_min_timer
000140: Jun  5 03:36:28.986: htsp_timer - 10000 msec
000141: Jun  5 03:36:28.986: htsp_timer3 - 5600 msec
000142: Jun  5 03:36:28.986: [0/1/0] htsp_start_caller_id_rx:BELLCORE
000143: Jun  5 03:36:28.986: htsp_start_caller_id_rx create dsp_stream_manager
000144: Jun  5 03:36:28.986: [0/1/0] htsp_dsm_create_success  returns 1
000145: Jun  5 03:36:29.290: htsp_process_event: [0/1/0, FXOLS_RINGING, E_DSP_SIG_0100]
000146: Jun  5 03:36:29.290: fxols_ringing_not
000147: Jun  5 03:36:29.290: htsp_timer_stop
000148: Jun  5 03:36:29.290: htsp_timer - 10000 msec
000149: Jun  5 03:36:30.302: htsp_process_event: [0/1/0, FXOLS_RINGING, E_DSP_SIG_0000]
000150: Jun  5 03:36:31.366: htsp_process_event: [0/1/0, FXOLS_RINGING, E_DSP_SIG_0100]
000151: Jun  5 03:36:31.366: fxols_ringing_not
000152: Jun  5 03:36:31.366: htsp_timer_stop
000153: Jun  5 03:36:31.366: htsp_timer_stop3
000154: Jun  5 03:36:31.370: [0/1/0] htsp_stop_caller_id_rx. message length 0htsp_setup_ind
000155: Jun  5 03:36:31.370: [0/1/0] get_fxo_caller_id:Caller ID receive failed.  parseCallerIDString:no data.
000156: Jun  5 03:36:31.370: [0/1/0] get_local_station_id calling num= calling name= calling time=06/05 12:36  orig called=
000157: Jun  5 03:36:31.374: [0/1/0] htsp_dsm_close_done
000158: Jun  5 03:36:31.374: htsp_process_event: [0/1/0, FXOLS_WAIT_SETUP_ACK, E_HTSP_SETUP_ACK]
000159: Jun  5 03:36:31.374: fxols_wait_setup_ack:
000160: Jun  5 03:36:31.374: htsp_timer - 6000 msec
000161: Jun  5 03:36:31.378: htsp_process_event: [0/1/0, FXOLS_PROCEEDING, E_HTSP_PROCEEDING]fxols_offhook_prochtsp_alert_notify
000162: Jun  5 03:36:31.418: htsp_process_event: [0/1/0, FXOLS_PROCEEDING, E_HTSP_ALERT]fxols_offhook_alert
000163: Jun  5 03:36:31.470: htsp_call_bridged invoked
000164: Jun  5 03:36:31.474: htsp_process_event: [0/1/0, FXOLS_PROCEEDING, E_HTSP_CONNECT]fxols_offhook_connect
000165: Jun  5 03:36:31.474: [0/1/0] set signal state = 0xC timestamp = 0
000166: Jun  5 03:36:31.474: htsp_timer_stop
000167: Jun  5 03:36:31.478: htsp_process_event: [0/1/0, FXOLS_CONNECT, E_HTSP_VOICE_CUT_THROUGH]fxols_connect_proc_voice
000168: Jun  5 03:36:34.438: htsp_digit_ready(0/1/0): digit = 1
000169: Jun  5 03:36:36.630: htsp_timer_stop3 htsp_setup_req
000170: Jun  5 03:36:36.634: htsp_process_event: [0/1/1, FXOLS_ONHOOK, E_HTSP_SETUP_REQ]fxols_onhook_setup
000171: Jun  5 03:36:36.634: [0/1/1] set signal state = 0xC timestamp = 0
000172: Jun  5 03:36:36.634: htsp_timer - 1300 msec
000173: Jun  5 03:36:37.934: htsp_process_event: [0/1/1, FXOLS_WAIT_DIAL_TONE, E_HTSP_EVENT_TIMER]fxols_wait_dial_timer  htsp_dial
000174: Jun  5 03:36:38.582: htsp_process_event: [0/1/1, FXOLS_WAIT_DIAL_DONE, E_DSP_DIALING_DONE]fxols_wait_dial_done htsp_alert
000175: Jun  5 03:36:38.582: htsp_timer - 350 msec
000176: Jun  5 03:36:38.582: htsp_call_bridged invoked
000177: Jun  5 03:36:38.586: htsp_call_bridged invoked
000178: Jun  5 03:36:38.590: htsp_process_event: [0/1/0, FXOLS_CONNECT, E_HTSP_VOICE_CUT_THROUGH]fxols_connect_proc_voice
000179: Jun  5 03:36:38.594: htsp_process_event: [0/1/1, FXOLS_WAIT_CUT_THRU, E_HTSP_VOICE_CUT_THROUGH]fxols_handle_cut_thru
000180: Jun  5 03:36:38.594: htsp_timer_stop

Once again thanks for your assistance.

Best Regards

Steven

Hi Steven,

One thing I know for certain is that I am not the right person to give you advice on this, this one single problem has defeated more times then I care to count, it has caused me more grief and aguish then I like to think about.

I did work out a way to defeat it eventually, but sadly the way I do it is not for everyone and most will not want to do it, or worse do not have the means/options to do it.

I spent a fair bit of time in Singapore contracting to various companies building systems for SIP trunking, a company I would encourage you to talk to (assuming they are still in operation, I am not sure as I have not been back in 2 years), is Smartel (Smart Tel). They have SIP trunk capabilities and at the time were one of the most competitive in Singapore, by having your calls go out over a SIP trunk you can avoid this problem, and I have had to do this now for multiple clients, in fact we pretty do it for all deployments now.

If you do not want all calls to go out over a SIP trunk, you can create a secondary dial-peers for the SIP trunk only, instead of having "0" as the secondary dialtone, you can use something like "9", this way you only need to educate the client/staff to press "9" instead of zero when creating a call forwarding rule.

Someone like Dave Harper or Steve might have some chances of success in resolving this problem for you as Singapore and Australia pretty much have the same type of networks/infrastructure, Dave might have some suggestions, but i just caution you now, do not be too hopefully, make a backup plan in the event there is no work around for you, you might prevent a loss of hair and maybe even retain a few years on your age

I am sorry i dont have anything else for you.

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

What version of IOS are you using? We have had similar issues with older IOS versions and FXO lines, have you tried the latest Software Pack?

I am using Cisco IOS Software Release 12.4(11).

Probably going to update to the latest to check if it solves the problem. I will update later.

Hi Steven,

I am using Cisco IOS Software Release 12.4(11).

Based on that I would say it is the original IOS that the system was shipped in, one of the first ones the UC-500 had, so it is... how do you put this? Uhm OLD

Probably going to update to the latest to check if it solves the 
problem. I will update later.

Right... Sounds like a plan, however right now is about where i need to throw a spanner in the works and get you thinking about this before you do it.

For starters:

  • Have you thought about how you are going to do the upgrade? Will it be command line and placing the IOS On the flash card?
  • Will you upgrade to CME version 8? Or use Lets say 124.(22) T4  (CME version 7) and just nudge the 151.1 IOS release which is CME version 8?
  • Will you be upgrading the CUE at the same time? You would be crazy not to, you really do not want the latest IOS with a 3.0 maybe 3.2 if your lucky CUE running, you would want to bring it in line with your CME so maybe 7.0 or one of the 7.X.X derivatives
  • Are you considering using CCA 2.2.4? If so just be aware that upgrading a system using CCA that has been long managed via the command line will without a shadow of a doubt "BREAK" something, well actually more then one thing, actually previous experience also indicates that in certain cases it wont even upgrade. CCA will run into a few problems is what I am saying I guess. However CCA is the recommended way to do it, and I wont deny that, but I need you to be prepared to spend some time resolving issues that (WILL) occur, things like your ACL's may or may not change, be removed, replaced, modified, or other. And if your Vlan configuration is not OOB compliant then that might also get modified (Might being the operative word as well), oh and I should mention things like DHCP pools or interface settings may also get modified, oh and VPN settings too. But don't panic you can easily fix everything that gets changed you can either replace it with your old config or fix up the offending lines that CCA put in there. (PS) I am just speaking from experience, everyone will have their own personal experience, I am just making sure you throw caution into the wind. And PLEASE make sure you backup your running configuration before you even consider making changes and especially an upgrade.

Keep in mind CCA will apply the right settings to things like your voice ports and your telephony-services for your region and types of services these are the two major sections of the configuration in my opinion that need special attention, it does some other cool things as well, I think the cool things out weigh the bad things regardless

If you got 4 hours spare I would even go as far as to say, blow the old configuration away, do the upgrade, reset the system to factory defaults at the same time, and then use the telephony wizard that CCA will present you with on an unprovisioned system, this way you no for sure it will work the way you wont it too. Make sure you download software pack 8.0.2 which has the latest support IOS and CUE in that pack, oh and phone loads too.

Lastly, you are still going to use analogue/pstn/fxo lines, that is not going to change, so no matter which path you take and the problem is still not resolved, do not be too disappointed you just need to work hard to get the decision makers to upgrade the system to a 2 BRI system

OK I have rambled enough on this topic, good luck with what ever path you take and I truly hope I am sooooooooooooooooo wrong and everything works out for you and the issue goes away,a nd my post was nothing more then a long rant .

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

Hi David,

I have updated the IOS and CUE together using the CCA. I used another unit for my tests so backup wasnt necessary.

The sad news is that I haven't been able to solve the problem.

Are you saying that moving to BRI will solve this problem? So far I am working with analog only and haven't played with the other options.

Best Regards

Steven

Hi Steven,

I have updated the IOS and CUE together using the CCA. I used another unit for my tests so backup wasnt necessary.

The sad news is that I haven't been able to solve the problem.

I figured this would be the case, but it is always best to let the person experience the process otherwise we just don't learn.

Are you saying that moving to BRI will solve this problem? So far I am 
working with analog only and haven't played with the other options.

I would stake all i have on it


I'll reiterate what I have posted before in other threads about this same topic, ISDN/BRI are digital services, they are by and large more reliable and contain better services and line characteristics, analogue lines were designed for old systems, anything pre late 90's IMHO, PSNT/Analogue lines just do not cut it in the modern age of technology.

Plus in Singapore ISDN/BRI services are well priced, configuring them on a UC-5XX is a cinch and you can then begin promoting to your clients Indial ranges, giving them this ability brings to the front the best feature sets of the UC-5XX, SIP/BRI/PRI can put a UC right in its elements and make it sing songs

Cheers,


David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *

steven-lau
Level 1
Level 1

Hi everybody,

I have solved the issue with the TAC. Their guy was great and was able to get to the problem. I was lucky the customer bought the smartnet support.

Below are the steps I applied:

Apply the commands on all the FXO ports that you have:

- timing sup-disconnect 50

Under the voice card 0, configure the following command to make the DSP stay across the voice port permanently , even if the call is connected from one voice port to the other via the TDM backplane:

- voice-card 0

- no local-bypass

Thanks to all who helped.

Best Regards

Steven

Hi Steven,

I am super glad to hear it friend

I am also glad you stuck it out and worked through the motions and channels to get the positive outcome.

Cheers,

David.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *
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: