what am i missing for SRST?

Mark Graham · ‎09-24-2012

i'm trying to get 3 7961's to failover to the router that is controlling them and here is our setup in a nutshell

core switch (4507 redunant supervisors)

the network is all over the place, we do have layer 2 dot 1q trunks between every switch from the core, and we have a 3750 metro doing QOS and our metro wan to our remote sites. we're trying to get SRST working on three phones as we have not been sucuessfull in the past. i have read a little on the subject, and here is what we have setup as we speak.

call managers: we setup a Device pool with the same configuration as the current DP but i setup a SRST reference in this pool.

router down in the dispatch center:

here is our CM fallback config

call-manager-fallback

secondary-dialtone 9

max-conferences 4 gain -6

transfer-system full-consult

timeouts interdigit 4

ip source-address 172.21.0.17 port 2000 (this is the router ip add)

max-ephones 24

max-dn 24

system message primary SRST Fallback Active

system message secondary SRST Fallback

keepalive 15

we have our dial peers setup for this router, i do not have any Ephones setup, do i need to set them up or will the router get the current config from the phone?

Chris Deren · ‎09-24-2012

So, what is not working? The phones do not register or register but cannot call anywhere?

I take it your SRST reference in CUCM references 172.21.0.17, correct?

Chris

Mark Graham · ‎09-24-2012

more so if my config is ok, currently everything is in production and it is extremely difficult to test with public saftey in factor.

and yes, chris, i do have the ip address in the CUCM

Chris Deren · ‎09-24-2012

Yes, your config is OK, so phones should register OK, whether calls can be made depends on dial-peer configuration.

HTH, please rate all useful posts!

Chris

Mark Graham · ‎09-24-2012

anything in particular i need to do to the dial peers? our lines are plared and source to the primary call manager on the router.

Chris Deren · ‎09-24-2012

Well, you did not show what you already have in place.

Is the GW under normal condition using MGCP, SIP or H323?

If SIP or H323 your existing dial-peers will be used under SRST.

If MGCP you will need to build a dial-peer for every pattern you need there, i.e. emergency, local, LD, international pointing to proper voice ports.

HTH, please rate all useful posts!

Chris

Mark Graham · ‎09-25-2012

whoops i forgot to add those.

voice port config

voice-port 0/0/0

no battery-reversal

no vad

connection plar opx immediate 2100

description 2100

caller-id enable

!

voice-port 0/0/1

no vad

connection plar opx immediate 2101

description 2101

caller-id enable

!

voice-port 0/0/2

no vad

connection plar opx immediate 2637

description 911 line 1

caller-id enable

!

voice-port 0/0/3

no vad

!

voice-port 0/1/0

no vad

connection plar opx immediate 2102

description 2102

caller-id enable

!

voice-port 0/1/1

no vad

caller-id enable

!

voice-port 0/1/2

no vad

connection plar opx immediate 2913

description 911 line 2

caller-id enable

!

voice-port 0/1/3

no vad

connection plar opx immediate 2899

description 911 line 2

caller-id enable

mgcp fax t38 ecm

mgcp behavior g729-variants static-pt

!

dial-peer voice 90911 pots

destination-pattern 9911

port 0/0/0

forward-digits 3

!

dial-peer voice 91911 pots

preference 1

destination-pattern 9911

port 0/0/1

forward-digits 3

!

dial-peer voice 92911 pots

preference 2

destination-pattern 9911

port 0/0/2

forward-digits 3

!

dial-peer voice 93911 pots

preference 3

destination-pattern 9911

port 0/0/3

forward-digits 3

!

dial-peer voice 9500 pots

preference 5

destination-pattern 9.T

port 0/0/0

!

dial-peer voice 9501 pots

preference 4

destination-pattern 9.T

port 0/0/1

!

dial-peer voice 9502 pots

preference 3

destination-pattern 9.T

port 0/0/2

!

dial-peer voice 9503 pots

preference 2

destination-pattern 9.T

port 0/0/3

!

dial-peer voice 401 voip

preference 1

destination-pattern [0-8]...

session target ipv4:172.21.2.10

dtmf-relay h245-signal

codec g711ulaw

no vad

!

dial-peer voice 100 pots

description **Incoming dial peer

incoming called-number 2...

no digit-strip

!

dial-peer voice 402 voip

destination-pattern [0-8]...

session target ipv4:172.21.0.10

dtmf-relay h245-signal

codec g711ulaw

no vad

on the normal gateway we're using H323 thankfully.

Mark Graham · ‎10-12-2012

ok chris, here is what i discovered when we took down the core and had our pub and sub down.

SRST worked just as intended, however, dispatchers were not able to dial out, we have a dial code of 9 to get out. do we need to setup a dial plan on the router?

second of all, once they're in SRST they stay in SRST, in order to get them to fall back to the primary call manager the phone needs reset. is that normal, or should it fail back to the pub or sub when they see connectivity?

Chris Deren · ‎10-12-2012

You need proper dial peer to match what is being dialed.

Phones will re-register automatically , by default the timer is 2 minutes and is defined under device pool --> Connection Monitor Duration. Did you wait 2 minutes?

HTH, please rate all helpful posts!

Chris

Mark Graham · ‎10-12-2012

i dont recall if i waited 2 mintues or not, by the time someone else looked at it they said "huh, didnt go back" and restarted the phone. i will check on that when i can on monday.

regarding the dial peers, since they are pots lines, do i have to take a look at the pots peers?

Chris Deren · ‎10-12-2012

Yes, when you are under SRST use "debug voice dialpeer" to troubleshoot if they are being matched properly.

Chris

Roger Kallberg · ‎10-13-2012

An easier way, and much less intrusive for other services, to force the site into SRST would be to add specific host routes that point to null for the CUCM IP addresses on the egress gateway. With this you would only affect the phones ability to communicate with the CUCM, not shutting down the rest of communication to/from the site.

A benefit of this is that you will still be able to communicate with the VGW used for SRST, so you can test and verify SRST without being on site. You would of course still need some one local at the site to do some test calls from the physical phone.

Also consider use of trunk group(s) instead of duplicate dial peers. That would be a lot cleaner and make your config more readable.

Please rate all useful posts.

Sent from Cisco Technical Support iPhone App