Calls in and out of MGC controlled FXO port ring then drop

Answered Question
Feb 19th, 2014
User Badges:

Lab environment


Setup


7960 -> CUCM 8.6 -> MGCP controlled FXO port on 2811 router -> PSTN emulator (another 2811) -> E1 trunk -> Public Router (CME) -. 7960


FXO port is set up to PLAR to the 4 digit extension on the CUCM hosted 7960.


Calls from the 7960 on the CUCM ring to the "Public" 7960 and will continue to ring until answered.  As soon as the call is answered, the call drops on the CUCM 7960.


Calls in the other direction, from the Public 7960 to the CUCM 7960 proceeds to teh FXO port, the FXO port answers and PLARs the call to the 7960 on the CUCM.  The CUCM 7960 rings once, and then drops the call.


Running a debug voice ccapi inout on the MGCP gateway indicates a disconnect cause code of 16 (which indicates normal call clearing)


It acts like its a codec mismatch.....


Its a lab so I can run debugs or provide configs if desired.

Correct Answer by acampbell about 3 years 5 months ago

Hi Jeffrey,


After a wee bit more digging - the fxs port on the PSTN box has battery-reversal by default.


My thought is when the fxo set to connected after the ringing stage the fxs in the PSTN box is

signalling a battery reversal which the fxo is seeing as a clear down.


Can you try turning this off on the PSTN router.



!

voice-port 1/0/0

no battery-reversal

!


Hopefully this will resolve the issue and you can get your calls in both directions


Regards,
Alex.
Please rate useful posts.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Nishant Savalia Wed, 02/19/2014 - 23:04
User Badges:
  • Silver, 250 points or more

Hi jeffery,

Please share below ouput separately for incoming & outgoing both:


"debug mgcp packets" & "debug voice ccapi all" for public router and "MGCP controlled FXO port on 2811 router".


Also share detail trace from CUCM.



Regards,
Nishant Savalia

jeffrey.girard Thu, 02/20/2014 - 06:29
User Badges:

Nishant - I believe that I have captured all of the permutations that you wanted.  I did not include any debug mgcp packets from the public router - as the public router is a standalone H323 and not running MGCP

      

5 attached to this reply, one attached to next one

Nishant Savalia Fri, 02/21/2014 - 02:41
User Badges:
  • Silver, 250 points or more

Hi jeffrey,

Can you please share your running config of public router and mgcp controlled rotuer.




Regards,
Nishant Savalia

Nishant Savalia Sun, 02/23/2014 - 23:08
User Badges:
  • Silver, 250 points or more

Hi Jeffrey,

Sorry for late response.


From your scenarios, it seems to be codec issue but from debugs it's not clearly identified as the disconnect cause you are getting is 16.

For further analysis please provide detail trace of CUCM (collect it from RTMT).

http://www.cisco.com/cisco/web/support/JP/100/1000/1000706_cm_trace.html



Apart from that few information required as below:-


1). Have you disabled G722 codec from service parameters? If not then please try to disable G722 codec and test call again.


2). Phone and Gateway is in which device pool?


3). Have you configured any MRGL under Device pool / Gateway ?


4). Please share your snapshots of region & Gateway configuration.



Regards,

Nishant Savalia

acampbell Mon, 02/24/2014 - 06:20
User Badges:
  • Green, 3000 points or more

Jeffrey,


On the FXO port on the MGCP gateway can you negate the battery reversal


!

voice-port 0/1/0

no battery-reversal answer

description Analog link to PSTN 1/0/0

caller-id enable

!


I think this being seen as a supervisory disconnect signal

Give it a try





Regards,
Alex.
Please rate useful posts.

jeffrey.girard Wed, 02/26/2014 - 06:06
User Badges:

Nishant and ACampbell -

     Sorry for the delay.  I am out out town on Mondays and Tuesdays at my client site.  This is my home lab.


So, Nishant - The link that you provided for RTMT is in a far eastern language which I cannot read.  I can provide RTMT traces, but what traces do you want?  Gathering all traces for all services is about 40 trace files.  Which ones are you interested in seeing?


I disabled 722 globally, reset all devices and no change.  The target phone and the FXO port on the MGCP gateway are both in the Alamosa device pool.  I have and MRGL created (also called Alamosa).  It contains the MRG (Alamosa).  Inside the MRG at the conf bridge, the MTP, and the Xcoder built on the 2811 router.  Yes, the MRGL of Alamosa is in the Alamosa device pool.


The requested screen shots are attached.


ACampbell - you got me half way there.  Now, outbound calls complete successfully and do not drop.  However, inbound calls still disconnect after the first ring of the PLAR'd device.

acampbell Wed, 02/26/2014 - 17:59
User Badges:
  • Green, 3000 points or more

Jeffrey,


Sorry for the delay,


I think the call from public to CUCM is failing due to the caller id feature


On your mgcp router can you try taking the caller id feature off


!

voice-port 0/1/0

no caller-id enable

!





Regards,
Alex.
Please rate useful posts.

jeffrey.girard Wed, 02/26/2014 - 18:47
User Badges:

Alex -

     Thanks for the reply


     I removed the caller-id enable command


     Shut and no shut the port


     No change.


     Outbound calls from CUCM to PSTN work, inbound calls from PSTN to FXO port ring the PLAR phone once and then disconnect.


     debug voice ccapi inout disconnect cause code remains 16 (normal call clearing)


Jeff

acampbell Thu, 02/27/2014 - 01:09
User Badges:
  • Green, 3000 points or more

Jeffrey,


Can you post the output of


debug vpm signal

debug vpm spi


from the mgcp router with the failing call



Regards,
Alex.
Please rate useful posts.

acampbell Thu, 02/27/2014 - 11:31
User Badges:
  • Green, 3000 points or more

Jeffrey,


It seems to be the FXO sending a reversal on answer (this is normal) that is killing the call


*Feb 20 10:26:49.154: htsp_process_event: [0/1/0, FXOLS_CONNECT, E_HTSP_VOICE_CUT_THROUGH]fxols_connect_proc_voice

*Feb 20 10:26:49.542: htsp_process_event: [0/1/0, FXOLS_CONNECT, E_DSP_SIG_0110]fxols_rvs_battery

*Feb 20 10:26:49.542: htsp_timer_stop2

*Feb 20 10:26:49.542: htsp_timer_stop2

*Feb 20 10:26:49.682: htsp_process_event: [0/1/0, FXOLS_CONNECT, E_DSP_SIG_0100]fxols_normal_battery

*Feb 20 10:26:49.682: htsp_timer_stop2 fxols_disc_confirm

*Feb 20 10:26:49.682: htsp_timer_stop


I see you have a 2811 as the PSTN emulator can you lets us see the sho run from that box


Trying to get my head round the FXS set up



Regards,
Alex.
Please rate useful posts.

jeffrey.girard Thu, 02/27/2014 - 11:39
User Badges:

Alex -

     I agree on the FXO sending the battery reversal upon answer.  I saw that from previous examinations at these debugs.  That is why I put in the battery-reversal answer command on the FXO.


     Attached is the sh run from my PSTN emulator.


     The FXS port in question is port 1/0/0 and the E1 that goes to my Public H323 Gw supporting the Public IP Phone is E1 0/2/1


Jeff                

Correct Answer
acampbell Thu, 02/27/2014 - 16:23
User Badges:
  • Green, 3000 points or more

Hi Jeffrey,


After a wee bit more digging - the fxs port on the PSTN box has battery-reversal by default.


My thought is when the fxo set to connected after the ringing stage the fxs in the PSTN box is

signalling a battery reversal which the fxo is seeing as a clear down.


Can you try turning this off on the PSTN router.



!

voice-port 1/0/0

no battery-reversal

!


Hopefully this will resolve the issue and you can get your calls in both directions


Regards,
Alex.
Please rate useful posts.

jeffrey.girard Thu, 02/27/2014 - 16:34
User Badges:

Alex -

     You got it.


     Calls processing in both directions.


     I really appreciate all your time and effort into this


Jeff

acampbell Thu, 02/27/2014 - 16:54
User Badges:
  • Green, 3000 points or more

Jeffrey


Glad its fixed & glad to help



Regards,
Alex.
Please rate useful posts.

Actions

This Discussion