cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2046
Views
0
Helpful
6
Replies

Voice GW Redundancy

Denny Trujillo
Level 1
Level 1

I’m hoping someone can help me design/validate a pair of cisco voice gateways. I have two C2921s proving PSTN connectivity to a Microsoft Lync environment. I’m trying to figure out the best way to set these up for high availability. Below is a topology on how everything is connected. I’m having issues achieving full redundancy on either a T1/QSIG trunk failure or an upstream IP/Ethernet failure. Below are the results of my failover testing.

  • Normal operation (Lync -> PSTN): Lync round robins between the two gateways
  • Normal operation (PSTN -> Lync):  All calls are routed through C2921B, if GW-B is unavailable, calls are rerouted through GW-A.
  • Complete loss of a gateway (Lync -> PSTN): Lync detects the failure and sends the calls down the available gateway
  • Complete loss of a gateway (PSTN -> Lync): NEC detects the failure and sends the calls down the available gateway

So far so good with failure scenarios, now here’s where the issues begin:

  • Loss of IP connectivity for GW (Lync -> PSTN): Lync detects failure and sends the calls down the available gateway
  • Loss of IP connectivity for GW (PSTN -> Lync): NEC does NOT detect failure since QSIG trunk is still up
  • Loss of QSIG connectivity (Lync -> PSTN) Lync does NOT detect failure since IP/SIP is still up
  • Loss of QSIG connectivity (PSTN -> Lync) NEC does detect failure and sends calls down the available gateway.

Is there any cisco voice technologies to help me overcome some of these issues?

cisco-lync.JPG

1 Accepted Solution

Accepted Solutions

Hi

That's correct.

On Lync, you should just need to associate both the gateways that you have defined in your topology to the PSTN Route in the voice policy - have you done that?

If so, test it again, but there may be some change that needs to be made so that Lync retries.

For example, with CUCM and H.323 gateways you have to enter the following:

'no dial-peer outbound status-check pots'

This stops the gateway returning 'user busy' if the E1/T1 is down, and makes it return a failure instead. Then CUCM fails over to the next gateway... If it doesn't fail over on Lync I'd try the same thing.

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

View solution in original post

6 Replies 6

Brandon Svec
Level 7
Level 7

I am NOT and expert at this, but it is an interesting problem and I thought maybe a tcl script could be leveraged to shutdown the T1 port when IP connectivity is lost in at least one of the two scenarios.  Look at this post and see if it is any help:

https://supportforums.cisco.com/thread/2090532

Good luck.

-- please remember to rate and mark answered helpful posts --

Hi

  • Loss of IP connectivity for GW (PSTN -> Lync): NEC does NOT detect failure since QSIG trunk is still up

You can use this configuration to monitor a specific LAN interface and drop the ISDN when it goes down:

voice-port 0/0/0:15

cptone GB

busyout monitor GigabitEthernet0/0

If the failure is further away you would be best to have a resilient network in place.... or go down the TCL route and monitor a route or something.

  • Loss of QSIG connectivity (Lync -> PSTN) Lync does NOT detect failure since IP/SIP is still up

The gateway will return a code to Lync that tells it that the destination is not available. Lync should be able to respond to this and try the next gateway...

Aaron

-

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Aaron, I take it that I would modify your configuration to drop my ISDN D-Channel correct? I'll have to test out T1 trunk failure some more to see if Lync is notified about the failure. Last time I simulated this, Lync would fail the call every time it tried routing it to the failed gateway.

voice-port 0/0/0:23

cptone GB

busyout monitor GigabitEthernet0/0

Hi

That's correct.

On Lync, you should just need to associate both the gateways that you have defined in your topology to the PSTN Route in the voice policy - have you done that?

If so, test it again, but there may be some change that needs to be made so that Lync retries.

For example, with CUCM and H.323 gateways you have to enter the following:

'no dial-peer outbound status-check pots'

This stops the gateway returning 'user busy' if the E1/T1 is down, and makes it return a failure instead. Then CUCM fails over to the next gateway... If it doesn't fail over on Lync I'd try the same thing.

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Hey Aaron, the following command resolved the issue of lync not hunting for another available gateway if the primary gw lost its PRI: 'no dial-peer outbound status-check pots'.

Without the command, the GW would return a "SIP/2.0 404 Not Found" error. With the command 'no dial-peer outbound status-check pots', the GW returns a "SIP/2.0 503 Service Unavailable" error. If Lync receives a 4xx error, it will fail the call. However, if Lync receives a 5xx error, it continues to hunt for the next available route/gateway.

Hi

Cool - I thought it was a good theory!

Thanks for reporting back!

Aaron

Aaron Harrison

Principal Engineer at Logicalis UK

Please rate helpful posts...

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!