MGCP PRI Dropped Calls

[cplatt01]

I had an incident yesterday when I our WAN connection failed to a remote office and the user was on a call connected T1 PRI. When the WAN failed, the call was cut off? My understanding is that the RTP stream should stay active? Any suggestions?

Thanks!

[Steven Smith]

Was the gateway on the other side of the WAN as the IP Phone? If so, the call will fail. If the gateway is on the same side of the WAN as the IP Phone, this should not have failed. Without tracing and debugs of what happened at the time, it will be tough to see why this failed.

[cplatt01]

It was on the same side of the WAN. That is what I figured, but I wasn't sure if anyone else had had it happen to them.

[jolo07310]

There is problem if your MGCP gateway is running SRST also.

Once SRST kicks in, it will go H.323 mode and cut off all the calls.

It is known issue. I have been told from cisco engineer, there is special command to fix the problem at new IOS, but I forgot.

Anyone please point me out.

Another way to convert your MGCP to H.323 for T1 PRI

Thanks

Ken

[maharris]

I wonder if they are talking about this, from the new Unified SRST 4.0 guide:

call preserve

To enable the preservation of H.323 VoIP calls, use the call preserve command in h323, voice-class h323, and voice service voip configuration modes. To reset to the default, use the no form of this command.

call preserve [limit-media-detection]

no call preserve [limit-media-detection]

Syntax Description

limit-media-detection

Limits RTP and RTCP inactivity detection and bidirectional silence detection (if configured) to H.323 VoIP preserved calls only.

Command Default

H.323 VoIP call preservation is disabled.

Command Modes

h323, voice-class h323, or voice service voip

Command History

Cisco IOS Release

Cisco Product

Modification

12.4(4)XC

Cisco Unified SRST 4.0

This command was introduced.

Usage Guidelines

The call preserve command activates H.323 VoIP call preservation for following types of failures and connections:

Failure Types

•WAN failures that include WAN links flapping or degraded WAN links

•Cisco Unified CallManager software failure, such as when the ccm.exe service crashes on a Cisco Unified CallManager server.

•LAN connectivity failure, except when a failure occurs at the local branch

Connection Types

•Calls between two Cisco Unified CallManager controlled endpoints

–During Cisco Unified CallManager reloads

–When a Transmission Control Protocol (TCP) connection between one or both endpoints and Cisco Unified CallManager used for signaling H.225.0 or H.245 messages is lost or flapping

–Between endpoints that are registered to different Cisco Unified CallManagers in a cluster and the TCP connection between the two Cisco Unified CallManagers is lost

–Between IP phones and the PSTN at the same site

•Calls between Cisco IOS gateway and an endpoint controlled by a softswitch where the signaling (H.225.0, H.245 or both) flows between the gateway and the softswitch and media flows between the gateway and the endpoint.

–When the softswitch reloads.

–When the H.225.0 or H.245 TCP connection between the gateway and the softswitch is lost, and the softswitch does not clear the call on the endpoint

–When the H.225.0 or H.245 TCP connection between softswitch and the endpoint is lost, and the soft-switch does not clear the call on the gateway

•Call flows that involve a Cisco IP in IP (IPIP) gateway running in media flow-around mode that reload or lose connection with the rest of the network

When bidirectional silence and RTP and RTCP inactivity detection are configured, they are enabled for all calls by default. To enable them for H.323 VoIP preserved calls only, you must use the call preserve command's limit-media-detection keyword.

H.323 VoIP call preservation can be applied globally to all calls and to a dial peer.

Examples

The following example enables H.323 VoIP call preservation for all calls.

voice service voip

h323

call preserve

The following configuration example enables H.323 VoIP call preservation for dial peer 1.

voice-class h323 4

call preserve

dial-peer voice 1 voip

voice-class h323 4

The following example enables H.323 VoIP call preservation and enables RTP and RTCP inactivity detection and bidirectional silence detection for preserved calls only:

voice service voip

h323

call preserve limit-media-detection

The following example enables RTP and RTCP inactivity detection. Note that for H.323 VoIP call preservation VAD must be set to off (no vad command).

dial-peer voice 10 voip

no vad

gateway

timer receive-rtcp

ip rtcp report-interval

The following configuration example enables bidirectional silence detection:

gateway

timer media-inactive

ip rtcp report interval

http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_command_reference_chapter09186a00805fb90a.html#wp1168838

Mary Beth

[maharris]

I just stumbled across this, I had been looking for it the other day - in this doc, they describe it as expected behaviour for backhauled PRI calls to fail during swithover - maybe that new command will help:

All active MGCP analog and T1 Channel-Associated Signaling (CAS) calls are maintained during the fallback transition. Callers are unaware of the fallback transition, and these active MGCP calls are cleared only when the communicating callers hang up. Active MGCP PRI backhaul calls are released during fallback.

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

Mary Beth

[cplatt01]

Interesting find Mary Beth. I really thought that MGCP ISDN PRI Calls were preserved during failover...If anyone does come across this command please post. I may even call TAC to see if they have an idea.

[cwatts]

Is the event that caused your WAN failure something that might also have caused the PRI to take a "hit"?

Maybe not cause and effect, but cause and cause ...

[cplatt01]

No, because the WAN failure was at the site with the Call Managers and not the remote site that was having an issue.

[maharris]

I am thinking that call preserve command I posted above might do it - they say h323, but they describe all of the circumstances it addresses, and it looks like it might take care of the switchover from MGCP to H323 control of the d channel.

Mary Beth

[cplatt01]

Straight from TAC:

The ISDN/PRI call state information is entirely maintained in Callmanager. The gateways ISDN and H.323 state machines are not part of the call and are not aware of the call state. When the GW switches from a backhauled mode to local H.323 control, the call must be cleared to the idle state. Subsequent call activity is then under local GW control.

This is not a bug or defect but rather a known feature limitation that is being addressed for future release (if possible - there is evidently substantial re-engineering involved to allow transition from MGCP control to H323 contol during fallback while preserving active calls on the PRI).