MGCP gateway still registered in SRST ?

[lowfell]

Question I'm trying to test srst on an a replacement isdn 28XX with 4321.
I put a acl on  access switch to deny access to cucm and the phones. the phones go in to "service interupted"  but no SRST service,

However when i run #show ccm-manager it says the gateway is still registered to a call manager. Is this correct?

[Roger Kallberg · Accepted solution]

Instead of using a ACL to block the traffic you could use static host routes that send the traffic destined to the IPs of the CMs to dev null. This is the by far easiest and least complicated way to achieve that a site goes into SRST.

[Roger Kallberg · Accepted solution]

Instead of using a ACL to block the traffic you could use static host routes that send the traffic destined to the IPs of the CMs to dev null. This is the by far easiest and least complicated way to achieve that a site goes into SRST.

[lowfell · Accepted solution]

for whatever eason this post was duplicated. see the other post, but thanks again for your help

[lowfell · Accepted solution]

Apologiues here, i tried to close the duplicate post by accepting closing it saying it was duplicate. anyway.

In the end i went for

ip route 1.2.3.4 255.255.255.255.255 null0

this did the trick with registration, though my SRST still isn't working.

Anyway thank you so much for the help
 

[Roger Kallberg]

What is it that isn’t working with your SRST?

[lowfell]

 I am having the same issue here with an MGCP gateway with FXO port.
here is my config under fallback
call-manager-fallback
max-conferences 6 gain -6
transfer-system full-consult
timeouts interdigit 6
ip source-address 10.42.173.1 port 2000
max-ephones 12
max-dn 24
system message primary Service Interruption
transfer-pattern T
keepalive 20
voicemail 290000
no huntstop
pickup 603890
alias 1 294013 to 760230
alias 2 294013 to 760231
alias 3 294013 to 760232
alias 4 294013 to 760228
alias 5 294013 to 760229
call-forward pattern T
call-forward busy 290000
call-forward noan 290000 timeout 15
time-zone 21
time-format 24
date-format dd-mm-yy
cor incoming group4 default

I used THESE aliases because in CUCM the 760228, 29, 30 etc were in the huntgroup along with the pilot of 294013

this still doesn't work though as this hunt group need to be called from the PSTN so someone dials 01XXX XXX228 which presunably is translated in cucm to 294013 the only tranbslation on the gateway i can see is
voice translation-rule 1
rule 1 /^.*\(....$\)/ /\1/
!
voice translation-rule 2
rule 1 /^.*$/ /90\0/
!
!
voice translation-profile PSTN-Inbound-Translate
translate calling 2
translate called 1
!

Do i not need a specific dial-peer as well. or have i added the wrong number to the aliases?

In debug i can see it hits dial-peer 999000 is this correct ? Here is the config gotr that dial peer
!
dial-peer voice 999000 pots
service mgcpapp
port 0/1/0
!
dial-peer voice 999001 pots
service mgcpapp
port 0/1/1
!
dial-peer voice 1 pots
translation-profile incoming PSTN-Inbound-Translate
incoming called-number .
direct-inward-dial

I think i may have found the answer. I've used the hunt pilot as 294013,  which is trhe number on CUCM. however , sohould i not have used the number on the voice port which is 760228 instead ? here is the voice port
voice-port 0/1/0
supervisory disconnect dualtone mid-call
no battery-reversal
no vad
no comfort-noise
cptone GB
timeouts call-disconnect 3
timeouts ringing infinity
timeouts wait-release 3
timing hookflash-out 50
timing guard-out 1000
timing sup-disconnect 85
connection plar opx 760228
impedance complex2

[Roger Kallberg · Accepted solution]

Not really something that anyone without insight into your specific configuration can answer. In general with MGCP you would do translations of calling and called numbers in CM. As this is not applicable in SRST mode you’d need to create the same translations in the gateway. This would be time consuming and error prone as it’s an easy thing to forget to update whenever there is a change in configuration in CM. For this reason many have disbanded use of MGCP in favour of SIP as then you’re catering to translations directly in the gateway, so it would work in both normal operation and in SRST mode.

[lowfell]

This is a project with like for like swaps going fro 2800's to ne 4300's. going to SIP isn't an option in this case. The only translalions i can see are as follows

voice translation-rule 1
rule 1 /^.*\(....$\)/ /\1/
!
voice translation-rule 2
rule 1 /^.*$/ /90\0/

On CUCM there must be a transllation that that transslates 760228 to 370228
if i dial 01XXX  760228 this is the only number for the site and is converted to also hunt group number

So, should 760228 be the number I use in my alaiases to the extensions like
alias 760228 to 760230
alias 760228 to 760231   etc etc etc ? 

is this correct?



 

[Roger Kallberg · Accepted solution]

As I wrote before it’s not possible to give you a specific answer on this as we do not have the needed information to do so. My best advice is to map out what is happening in normal operation mode and create the matching setup for when the system operates in SRST state.

If it’s a like for like swap wouldn’t that mean that you would have all configuration in place in the old router so that you can move it over to the new router?

It is actually quite straightforward to make the switch from MGCP to SIP. It might sound daunting, but with a little planning and preparation it can be done seamlessly.

[lowfell]

Sorry i didn't expalin that very wel. It's a like for like but the SRST was never used in the old. Apart from SRST it's new for old.

Unfortuanely SIP isn't an option and I need to get SRST working with what I've got. thanks for your help anyway.