Calls from Etisalat PSTN to FXO to voicemail do not disconnect

I have a tricky issue where outside caller calls in and when the call is forwareded to voicemail because of CFNA, the FXO do not disconnect. I have a setup where a Etisalat Analog lines are directly connected to UC560 FXO ports using RJ11.

When a call comes in over the PSTN to an FXO port on my UC560 and the call is answered by the user and after that user goes on-hook, FXO disconnects or gets released normally . When the user does not answer the call and becuse of CFNA timeout the call is forwarded to users voicemail box , then CUE answers, a voicemail is recorded, but when the calling party hangs up FXO doesnot disconnect instead it stays in OFFHOOK state (HANGS). Because of this no more calls are possible on that FXO line. I have to issue shut and no shut command on the FXO to get it released.

Previously when helping out another person in the UAE connected to Etisalat we did some minor changes...

voice-port 0/1/0

trunk-group ALL_FXO 61

translation-profile incoming INCOMING_CallerID_PROFILE

supervisory disconnect dualtone mid-call

supervisory custom-cptone UAE-CUSTOM-SIEMENS

supervisory dualtone-detect-params 1

no battery-reversal

input gain 14

cptone AE

timeouts call-disconnect 2

timeouts wait-release 2

timing min-ring 62

connection plar opx 202

description Configured by CCA 4 FXO-0/1/0-Custom-BG

caller-id enable

Try and change the supervisory disconnect to the other available options, although mid-call should work, for some reason it doesn't with all clients connected to them, from memory when I was last in Dubai not every exchange had the same equipment. I am not sure why you have so many supervisory I haven't seen them on other UAE deployments before, is that something that CCA put there??

Actually your voice-port config is unusual to me, if this is something that CCA has done, it must be new. There is way more configuration in your one then I have seen on many others... Hmmmm very odd.

Could you please suggest the voice port configuration that need to be used to address this issue with FXO disconnect when the call is forwarded to voice mail.

I would be more thankful if you could share the voice port configuration that you used to fix the other customer in UAE.

The configurations for FXO are not generated by CCA i have added them manually inorder to fix this issue with FXO disconnect.I tried with different supervisory disconnect but no use same issue with FXO.

Thanks a lot for your support on this tricky issue. I tried to fix this issue using different options but i was not able to fix that not even i was going closer to fix this issue. How did you know that we need to increase the frequency max deviation value to 50 to fix this problem with FXO disconnect when the call is answered by CUE or Voicemail box.

You know in the process of fixing this issue on my own i tried to increase this value to 35 but there was no improvement so thought that this might not be the solution for this issue.

You are really great cisco voice engineeer, who has given the solution very straight forward.

Have you ever faced this kind of problem earlier with FXO call disconnect when answered by Voicemail or CUE .

I have seen many people logging similar kind of issue but no has given the confirmed solution to fix this issue.

One small request can you help me how to capture the traffic, when the call is coming form FXO port and using wireshark find the frequencies for different call progress tone like dial tone, busy tone, disconnect tone.

To capture the PCM with the UC is fairly easy. You can use CCA Troubleshoot > Telephony Diagnostics > PCM Capture this will create PCM.dat capture file. Just select the right port and click begin and end when you finish the capture. Then open a case with SBSC and provide that file - we use internal tool do get the debug and to convert it to wav file. You can also try to find another 3rd party tool to convert it to wav file.

The other option is to enable span on the phone and collect the conversation using wireshark. Enter "service phone spanToPCPort 0" this will send the packets for the phone also to the PC behind the phone. Then connect PC behind the phone and collect the wireshark capture on the PC, convert it to wav and use some software for wav editing to find the correct tones. You should look at the wav editor software for the way to measure the tones but there are alot of guides.

Do not forget to enter "service phone spanToPCPort 1" when you finish with the capture.

The problem is disconnect is working fine in normal scenario ie when the call is answered by the user using the IP phone.But the question here is when the call is answerred by the voicemail ie CUE because of CFNA and when the external caller hangs up after the call is answerred by voicemail then FXO is not disconnecting. Even though the external caller hangs up the voicemail is not sensing this and instead records a large amount of silence in the voicemail box of the user.This silence is recorded for about 240 sec ie voicemail box message size of the user and then it releases the FXO port. I have used the following configurations

I really understand that the tones configured are not correct.But on the other hand i am not able to understand why the FXO is disconnecting properly when the call is answred by the IP phone directly.Is this not strange you see here.

Could you please helpme atleast how to find the correct cptones for the same atleast the procedure to find the correct CPTONEs.(I am not able to find the correct CPTONES form the service provider side).

Here is the debug vpm signal information that i have taken for two scenarios

the configuration on voice-port is as follows

voice class custom-cptone UAE-CUSTOM

dualtone disconnect

frequency 425

cadence 400 350 225 525

voice-port 0/1/1

translation-profile incoming INCOMING_CallerID_PROFILE

supervisory disconnect dualtone mid-call

supervisory custom-cptone UAE-CUSTOM

input gain 14

cptone AE

timeouts call-disconnect 2

timeouts wait-release 2

connection plar opx 202

description Configured by CCA 4 FXO-0/1/1-Custom-OP

caller-id enable

the came same configuration above with battery reversal answer but no use sitll same issue.

The other tricky thing that is happening is when the call is forwarded to voicemail of the user and after the external caller disconnects the FXO on UC540 does not disconnect immediately, instead it disconnects after the default messgae size is reached. ie the default message size of voicemail box is 240 sec so after 240 sec the FXO port is released or disconnects and a large amount of silence is being recorded in the users mailbox for about 240 seconds.

Can any one let me know what is happing here. when the call is forwarded to voicemail of the user, why FXO Port on UC540 not getting disconnected soon after the external caller disconnects the call.and insted it disconnects approximately after 240 seconds of call forwarded to voicemail.

I tried the same cofiguration as above with battery reversal answer in voice-port configuration but no use sitll same issue.

Have you seen the debug captures that i have posted. Could you please help me out what we have to look at in these debug message to fix this issue.Or any conclusion we can derive from these debug messages of VPM signal.

I have a simple configuration with a provide (telecom italia) direct connect to FXO. I noticed that when i choose to redirecting incomming call to a Iphone, and I bring down the call (for example from my cel phone), evrything works fine.

Instead when I redirect a incomming call to the Cue (for a AVR simple menu) and this works redirecting call to iphone, and from my cel bring down the call, the iphone still ring and after the No aswer timeout the call was passed again to cue for voicemail.

I am glad that you have resolved the issue. You should have tried this first as it is marked as the correct answer.

Just to add - the CUE is not manipulating the frequence. It just has longer disconnect timeout. That is why the CME should correctly recognize the disconnect tone to act on time without waiting to disconnect from the called side.