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?
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.
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
I wonder if they are talking about this, from the new Unified SRST 4.0 guide:
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]
Limits RTP and RTCP inactivity detection and bidirectional silence detection (if configured) to H.323 VoIP preserved calls only.
H.323 VoIP call preservation is disabled.
h323, voice-class h323, or voice service voip
Cisco IOS Release
Cisco Unified SRST 4.0
This command was introduced.
The call preserve command activates H.323 VoIP call preservation for following types of failures and connections:
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
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.
The following example enables H.323 VoIP call preservation for all calls.
voice service voip
The following configuration example enables H.323 VoIP call preservation for dial peer 1.
voice-class h323 4
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
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
ip rtcp report-interval
The following configuration example enables bidirectional silence detection:
ip rtcp report interval
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.
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.
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 ...
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.
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).