Ring tone OK but call disconnected at off-hook

[daniel.yuste.aroca]

Dear all,

We are facing a problem with incoming calls received via FCTs connected to our CME by FXO ports.

Outgoing calls through the FCTs are working fine and the cell called is seeing the right cell number as caller ID.

The problem raises when we call back this number: we can hear the ring tone and the operator´s phone is ringing fine, but the call gets disconnected as soon as the operator picks the call up.

We are running CME 8.6 in router 2911 with VIC2-4FXO inserted.

In the file attached you have the output of debug vpm signal. Translation seems OK as the called number isthe right DN and the calling number is the right one too.

I will try to attach the output of debug voip ccapi inout later

Any idea what the problem could be?

Thanks in advance.

Daniel

voice-port 0/2/0
translation-profile incoming MOVILES-IN
translation-profile outgoing MOVILES-OUT
compand-type a-law
cptone ES
connection plar opx 2500
impedance complex2
caller-id enable
voice-port 0/2/1
translation-profile incoming MOVILES-IN
translation-profile outgoing MOVILES-OUT
compand-type a-law
cptone ES
connection plar opx 2500
impedance complex2
caller-id enable
voice-port 0/2/2
translation-profile incoming Moviles-IN
translation-profile outgoing Moviles-OUT
compand-type a-law
cptone ES
connection plar opx 2500
impedance complex2
caller-id enable
voice-port 0/2/3
translation-profile incoming Moviles-IN
translation-profile outgoing Moviles-OUT
compand-type a-law
cptone ES
connection plar opx 2500
impedance complex2
caller-id enable

[Ayodeji Okanlawon]

Hi,

Can you send the ff:

1. sh run

2. Debug voip ccapi inout

3. debug h225 ans1

4. debug h245asn1

[daniel.yuste.aroca]

Hello aokanlawon,

Just attached the show run.

Will attach the debugs missing tomorrow, when I can get them.

Thanks and best regards.

Daniel

[marmugam · Accepted solution]

Hi,

Is this is the call flow:-

Inbound call

-----FXO----- 2911(CME)---IP phone

++ Looks like the call is released from the Far end frist, as they are sending supervisory disconnect signal through Battery reversal. Once the call is connected they send the reverse battery signal to start the billing.

May  3 14:05:30.783: htsp_process_event: [0/2/1, FXOLS_CONNECT, E_HTSP_VOICE_CUT_THROUGH]fxols_connect_proc_voice

May  3 14:05:30.983: htsp_process_event: [0/2/1, FXOLS_CONNECT, E_DSP_SIG_0100]fxols_normal_battery

May  3 14:05:30.983: htsp_timer_stop2

May  3 14:05:31.099: htsp_process_event: [0/2/1, FXOLS_CONNECT, E_DSP_SIG_0110]fxols_rvs_battery

May  3 14:05:31.099: htsp_timer_stop2

May  3 14:05:31.099: htsp_timer_stop2

++ After 744 msec, they reversed the batter sig and sent normal battery indication  for disconnecting the call

May  3 14:05:31.743: htsp_process_event: [0/2/1, FXOLS_CONNECT, E_DSP_SIG_0100]fxols_normal_battery

May  3 14:05:31.743: htsp_timer_stop2 fxols_disc_confirm

++ Call is released to CME IP Phone.

May  3 14:05:31.743: htsp_process_event: [50/0/250.1, EFXS_CONNECT, E_HTSP_RELEASE_REQ]efxs_connect_disc

++ I beleive this should be ok, to let the telco/PBX switch know why they are sending sending Battery reversal in 745 msecs.

++ Just for another confirmation, please send the following debugs:-

Degbus:

++ debug voip ccapi inout

++ debug ephone messages

++ debug vpm sig

Include the mac-address of the Ephone., along with called/calling numbers.

[daniel.yuste.aroca]

Hello all,

Just attached the output of debug voice ccapi inout and debug ephone message during a failed call.

Debugs for h225 and h245 did not show any output during a failed call with the following flags on:

H.225:

  H.225 Event Messages debugging is on

  H.225 ASN1 Messages debugging is on

  H.225 ASN1 Error Messages debugging is on

H.245:

  H.245 Event Messages debugging is on

  H.245 ASN1 Messages debugging is on

  H.245 ASN1 Error Messages debugging is on

[marmugam]

Hi,

You wll not see any h323 related events as this call is coming in from analog line to a phone registered to CME(same box). I was expecting to see all the debugs in parallel.

// However, Like I mentinoed earlier Far end is releasing the call:-

13287 is call ref for incoming call-leg fr FXO

13288 is call-ref for outgoing call-leg to SCCP phone.

// Once both leg is bridged, we see a disconnect from telco after 750 msecs(approximately). Co-relating vpm sig yesterday and ccapi shows far end released the call. You can also see that we see 13287 call getting disconneted first followed by ephone leg.

May  4 09:46:26.578: //13287/D65E5C5AB2ED/CCAPI/cc_api_call_disconnected:

   Cause Value=16, Interface=0x313ADF5C, Call Id=13287

May  4 09:46:26.578: //13287/D65E5C5AB2ED/CCAPI/cc_api_call_disconnected:

   Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)

May  4 09:46:26.578: //13287/D65E5C5AB2ED/CCAPI/ccConferenceDestroy:

   Conference Id=0xD47, Tag=0x0

May  4 09:46:26.578: //13287/D65E5C5AB2ED/CCAPI/cc_api_bridge_drop_done:

   Conference Id=0xD47, Source Interface=0x313ADF5C, Source Call Id=13287,

   Destination Call Id=13288, Disposition=0x0, Tag=0x0

May  4 09:46:26.578: //13288/D65E5C5AB2ED/CCAPI/cc_api_bridge_drop_done:

   Conference Id=0xD47, Source Interface=0x32279578, Source Call Id=13288,

   Destination Call Id=13287, Disposition=0x0, Tag=0x0

May  4 09:46:26.578: //13287/D65E5C5AB2ED/CCAPI/cc_generic_bridge_done:

   Conference Id=0xD47, Source Interface=0x32279578, Source Call Id=13288,

   Destination Call Id=13287, Disposition=0x0, Tag=0x0

May  4 09:46:26.578: //13287/D65E5C5AB2ED/CCAPI/ccCallDisconnect:

   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=16)

May  4 09:46:26.578: //13287/D65E5C5AB2ED/CCAPI/ccCallDisconnect:

   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)

May  4 09:46:26.578: //13287/D65E5C5AB2ED/CCAPI/cc_api_get_transfer_info:

   Transfer Number Is Null

May  4 09:46:26.578: //13288/D65E5C5AB2ED/CCAPI/ccCallDisconnect:

May  4 09:46:26.578: //13288/D65E5C5AB2ED/CCAPI/ccCallDisconnect:

   Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

   Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)

++ Please check with them to see why they are disconnecting the call approximately after 750 msecs. Time delata from  vpm debugs provided originally and ccapi looks same.

Thanks,

Murali

[daniel.yuste.aroca]

Just in case it could be useful for anyone, we solved the issue by configuring "no battery-reversal" under the voice ports associated to the FXO ports having the issue.

Thanks marmugan for your help on this issue.

Daniel