SRST / MGCP Switchback issue

Unanswered Question
Jul 7th, 2010
User Badges:

Hi,


I'm running CUCM 7.1 and a 1751-V in a lab environment. The 1751-V is equiped with a VIC2-2BRI-NT/TE. I've configured SRST and MGCP fallback on the 1751-V. Everything is working as it should except that all the active PSTN calls get disconnected when switchback happens, eventhough the switchback mode has been set to "Graceful". I want it to wait with the switchback till all the calls have been cleared, just like the "graceful" setting describes.


CCME#show ccm-manager
MGCP Domain Name: CCME.domain.local

Priority        Status                   Host
============================================================
Primary         Registered               cm (192.168.10.12)
First Backup    None                    
Second Backup   None                    

Current active Call Manager:    192.168.10.12
Backhaul/Redundant link port:   2428
Failover Interval:              30 seconds
Keepalive Interval:             15 seconds
Last keepalive sent:            12:20:48 CET Jul 7 2010 (elapsed time: 00:00:04)
Last MGCP traffic time:         12:20:48 CET Jul 7 2010 (elapsed time: 00:00:04)
Last failover time:             None
Last switchback time:           None
Switchback mode:                Graceful
MGCP Fallback mode:             Enabled/OFF
Last MGCP Fallback start time:  12:14:09 CET Jul 7 2010
Last MGCP Fallback end time:    12:18:18 CET Jul 7 2010
MGCP Download Tones:            Disabled
TFTP retry count to shut Ports: 2

Backhaul Link info:
    Link Protocol:      TCP
    Remote Port Number: 2428
    Remote IP Address:  192.168.10.12
    Current Link State: OPEN
    Statistics:
        Packets recvd:   19
        Recv failures:   0
        Packets xmitted: 35
        Xmit failures:   0
    BRI Ports being backhauled:
        Slot 0, VIC 1, port 0
        Slot 0, VIC 1, port 1
Configuration Auto-Download Information
=======================================
Last config-downloaded:00:00:00
Current state: Waiting for commands
Configuration Download statistics:
        Download Attempted             : 3
          Download Successful          : 3
          Download Failed              : 0
          TFTP Download Failed         : 0
        Configuration Attempted        : 2
          Configuration Successful     : 2
          Configuration Failed(Parsing): 0
          Configuration Failed(config) : 0
Last config download command: New Registration
FAX mode: cisco
Configuration Error History:


Here are de MGCP debugs:


001841: Jul  7 12:17:58.593 CET: cmapp_host_fsm: Processing event GO_ACTIVE for host 0 (192.168.10.12) in state DOWN
001842: Jul  7 12:17:58.593 CET: cmapp_start_host_tmr: Host 0 (192.168.10.12), tmr 0, duration 15000
001843: Jul  7 12:17:58.597 CET: cmapp_open_new_link: Open link for [0]:192.168.10.12
001844: Jul  7 12:17:58.597 CET: cmbh_open_tcp_link: Opening TCP link with Rem IP 192.168.10.12, Local IP 192.168.10.11, port 2428
001845: Jul  7 12:17:58.601 CET: cmapp_open_new_link: Open initiated OK: Host 0 (192.168.10.12), session_id=84DF34B4
001846: Jul  7 12:17:58.601 CET: cmapp_host_fsm: New state ACTIVE_OPENING for host 0 (192.168.10.12)
001847: Jul  7 12:17:58.605 CET: cmbh_tcp_open_ind: TCP open succeeded for 192.168.10.12, calling callback.
001848: Jul  7 12:17:58.609 CET: cmapp_host_fsm: Processing event CONN_OPEN for host 0 (192.168.10.12) in state ACTIVE_OPENING
001849: Jul  7 12:17:58.609 CET: cmapp_stop_host_tmr: for host 0 (192.168.10.12)
001850: Jul  7 12:17:58.609 CET: cmapp_mgr_send_rehome: new addr=192.168.10.12,port=2427
001851: Jul  7 12:17:58.609 CET: cmapp_host_fsm: New state CHECK_MGCP_REG for host 0 (192.168.10.12)
001852: Jul  7 12:17:58.613 CET: cmapp_check_def_mgc: MGC conn stat = 3
  (1=UNKNOWN,2=CONNECTED,3=CONNECTING,4=NO_DNS_NAME,5=NO_RESPONSE)
001853: Jul  7 12:17:58.613 CET: cmapp_host_fsm: Processing event MGCP_REGISTERING for host 0 (192.168.10.12) in state CHECK_MGCP_REG
001854: Jul  7 12:17:58.613 CET: cmapp_mgcp_send_rsip: ip_addr=192.168.10.12 port=2427 if_type=-1, slot=0,subunit=0 rst_type=3
001855: Jul  7 12:17:58.613 CET: cmapp_start_host_tmr: Host 0 (192.168.10.12), tmr 0, duration 30000
001856: Jul  7 12:17:58.617 CET: cmapp_host_fsm: New state REGISTERING for host 0 (192.168.10.12)
001857: Jul  7 12:17:58.641 CET: cmapp_host_fsm: Processing event REGISTRATION_ACK for host 0 (192.168.10.12) in state REGISTERING
001858: Jul  7 12:17:58.641 CET: cmapp_stop_host_tmr: for host 0 (192.168.10.12)
001859: Jul  7 12:17:58.645 CET: cmapp_host_fsm: New state REGISTERED for host 0 (192.168.10.12)
001860: Jul  7 12:17:58.645 CET: cmapp_mgr_process_ev_host_registered: Host 0 (192.168.10.12) is active and registered
001861: Jul  7 12:17:58.645 CET: cmapp_try_fallback(set_to_mode=OFF)
001862: Jul  7 12:17:58.645 CET: cmapp_shut_backhaul: backhaul link shutdown is not configured
001863: Jul  7 12:17:58.645 CET: end FALLBACK now!
001864: Jul  7 12:17:58.645 CET: cmapp_fallback_pri_backhaul(set_to_mode=OFF)
001865: Jul  7 12:17:58.649 CET: cmapp_fallback_bri_backhaul(set_to_mode=OFF)
001866: Jul  7 12:17:58.649 CET: cmapp_cleanup_bh_port(rehome,3)
001867: Jul  7 12:17:58.649 CET: cmapp_cleanup_bh_port:callEntry->callID is 0xDF on 0/1
001868: Jul  7 12:17:58.649 CET: cmapp_wait_for_calls_cleanup(rehome,6,3)
001869: Jul  7 12:17:58.649 CET: cmapp_wait_for_calls_cleanup: ccs call still exists...
001870: Jul  7 12:17:58.649 CET: cmapp_wait_for_calls_cleanup: callid=0xDF still exists, pausing for 500 msec...
001871: Jul  7 12:17:58.737 CET: %ISDN-6-DISCONNECT: Interface BRI1/1:1  disconnected from 06123456789, call lasted 23 seconds
001872: Jul  7 12:17:59.153 CET: cmapp_wait_for_calls_cleanup: ALL BRI calls are cleared!

As you can see the call gets disconnected, but not because of a caller ending the call..


001873: Jul  7 12:17:59.153 CET:        [0]:slot 1, port 1, interface_type 14
001874: Jul  7 12:17:59.153 CET: cmapp_fback_shut_dch_intf 
001875: Jul  7 12:17:59.153 CET: cmapp_fback_shut_dch_intf: Disable the D channel
001876: Jul  7 12:18:00.153 CET: cmapp_fback_cfg_router_if: configuring if:[interface BRI1/1]
001877: Jul  7 12:18:00.153 CET: cmapp_fback_cfg_router_if: configuring [shutdown]
001878: Jul  7 12:18:00.429 CET: %LINK-5-CHANGED: Interface BRI1/1, changed state to administratively down
001879: Jul  7 12:18:00.649 CET: cmapp_fback_cfg_bri_backhaul 
001880: Jul  7 12:18:00.649 CET: cmapp_fback_cfg_bri_backhaul: Enable BRI isdn bind-l3 ccm service mgcp
001881: Jul  7 12:18:00.649 CET: cmapp_fback_cfg_router_if: configuring if:[interface BRI1/1]
001882: Jul  7 12:18:00.649 CET: cmapp_fback_cfg_router_if: configuring [isdn bind-l3 ccm-manager service mgcp]
001883: Jul  7 12:18:00.869 CET: cmapp_fback_shut_dch_intf 
001884: Jul  7 12:18:00.869 CET: cmapp_fback_shut_dch_intf: Enable the D channel
001885: Jul  7 12:18:00.869 CET: cmapp_cleanup_bh_port(rehome,3)
001886: Jul  7 12:18:00.873 CET: cmapp_wait_for_calls_cleanup(rehome,6,3)
001887: Jul  7 12:18:00.873 CET: cmapp_wait_for_calls_cleanup: ALL BRI calls are cleared!
001888: Jul  7 12:18:00.873 CET:        [1]:slot 1, port 0, interface_type 14
001889: Jul  7 12:18:00.873 CET: cmapp_fback_shut_dch_intf 
001890: Jul  7 12:18:00.873 CET: cmapp_fback_shut_dch_intf: Disable the D channel
001891: Jul  7 12:18:01.873 CET: cmapp_fback_cfg_router_if: configuring if:[interface BRI1/0]
001892: Jul  7 12:18:01.873 CET: cmapp_fback_cfg_router_if: configuring [shutdown]
001893: Jul  7 12:18:02.149 CET: %LINK-5-CHANGED: Interface BRI1/0, changed state to administratively down
001894: Jul  7 12:18:02.353 CET: cmapp_fback_cfg_bri_backhaul 
001895: Jul  7 12:18:02.353 CET: cmapp_fback_cfg_bri_backhaul: Enable BRI isdn bind-l3 ccm service mgcp
001896: Jul  7 12:18:02.353 CET: cmapp_fback_cfg_router_if: configuring if:[interface BRI1/0]
001897: Jul  7 12:18:02.353 CET: cmapp_fback_cfg_router_if: configuring [isdn bind-l3 ccm-manager service mgcp]
001898: Jul  7 12:18:02.573 CET: cmapp_fback_shut_dch_intf 
001899: Jul  7 12:18:02.573 CET: cmapp_fback_shut_dch_intf: Enable the D channel
001900: Jul  7 12:18:05.577 CET: cmapp_fback_cfg_router_if: configuring if:[interface BRI1/1
no shutdown]
001901: Jul  7 12:18:05.577 CET: cmapp_fback_cfg_router_if: configuring []
001903: Jul  7 12:18:05.841 CET: %LINK-3-UPDOWN: Interface BRI1/1, changed state to up
001904: Jul  7 12:18:06.821 CET: cmapp_fback_cfg_router_if: configuring if:[interface BRI1/0
no shutdown]
001905: Jul  7 12:18:06.821 CET: cmapp_fback_cfg_router_if: configuring []
001906: Jul  7 12:18:07.085 CET: %LINK-3-UPDOWN: Interface BRI1/0, changed state to up
001907: Jul  7 12:18:23.065 CET: cmapp_mgr_process_ev_host_registered: Send new CM reg after Rehome


Any idea what I may have been overlooking?


Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (2 ratings)
Loading.
auppal Sat, 07/10/2010 - 10:05
User Badges:
  • Cisco Employee,

switchback is when you have 2 node and one cluster is down then the mgcp gw will hold the call and switch the active reg

istration to the other node after the call is disconnected. In mgcp t1 pri the call will drop since backhaul drops and there is no way to

know when the call disconnects or connects look at this

http://www.cisco.com/en/US/customer/tech/tk1077/technologies_configuration_example09186a008012ecc6.shtml


might explain it better


Thanks

2044418Puts Sun, 07/11/2010 - 00:35
User Badges:

Yes I know that the call drops as soon as the CUCM cluster becomes unavailable. But as soon as that happens SRST kicks in and the phones start to register to the SRST gateway with MGCP fallback and that is working as it should.


Lets say people start calling to the PSTN when SRST and MGCP fallback is active. What I've noticed, and what this discussion is about, is that when the CUCM cluster comes back up the calls to the PSTN are dropped, because the gateway immediately reregisteres with the CUCM, but I want it to wait till all the active PSTN calls are finished. Thats why I configured the MGCP Switchback setting to graceful. But this does not seem to work since the switchback happens immediately. And I would like to know why.


Thanks

auppal Sun, 07/11/2010 - 09:39
User Badges:
  • Cisco Employee,

that makes sense i checked your logs it looks like the gw sees a active dsp being used on the call would be intrested to see if there was actually an active call. In the past CSCse14185  was suspected in such issues what IOS are you using ? Its worth while to see if your IOS has the fix to this bug after which you might want to collect deb vtsp all and deb ccm-manager backhaul events/messages

Liz Bentler Mon, 09/27/2010 - 13:13
User Badges:

As I understand it selecting graceful only extends a timer that delays registering the GW to CUCM upon restore.  Changing the GW to H323 is the only way to preserve the calls regardless of how long they are up.

Liz

MARTIN STREULE Tue, 09/28/2010 - 01:59
User Badges:
  • Silver, 250 points or more

Hi,


There is another point for H.323 is this scenario to consider:


If you really want to have graceful to wait for the last call to clear - all phones which registered back to the CUCM cannot use this gateway for calls.


So this might be graceful for the last guy sitting on the phone for another hour - but for all the other ones it's bad.


IMO the best solution is H.323 with "call preserve".

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/h323pres.html

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/gateways.html#wp1044178


Cheers,

Martin

Actions

This Discussion