Right now I am in the middle of a migration away from a bunch of old digital PBXs to a Cisco VoIP platform nation wide. I have my my CUCM cluster configured and most all of my big sites and contact centers done so now I am moving onto my smaller sites (>50 users). Currently I like to deploy 2800 and 2900 series ISR running MGCP out all of my Branch office across the US. This works out great with PRIs and POTS lines in a hunt group, but I what I havnt been able to try yet is using DID trunks. I know that there is a limitation with VICx-xFXO/DID cards and they cannot operate in DID mode with MGCP and thay I must use H.323. Knowing this limitation I would like to configure my Gateway/FXO ports to use MGCP, my FXS/DID ports to use H.323, and also take advantage of SRST failover mode. What I havnt been able to figure out is how do I configure the dial-peers for the DID functionality and still have it work when the Gateway is in normal operation and SRST mode.
My thought was this:
Have the typical outbound dial-peers point to the FXO ports for SRST/H.323 operation
Configure a pots dial peer with "Direct-inward-dial" and incoming called-number to match the DNIS
Configure dial-peer voip with session target of each CUCM subscriber with differing preferences
Configure a "lowest preference" dial-peer voip with a session target of the gateway's loopback
This way when the gateway is in SRST mode and the phones are registered locally the DID calls will be routed locally
Mt Ultimate goal is this:
Have a Local Gateway with SCCP based resources
Have a "Outbound Trunk" of POTS lines in FXO ports
Have an "Inbound Trunk" utilizing DID trunks and FXS ports
Have a failover option, so I could cut the WAN connection and retain most all call functionality. (Dont worry CUE is not involved)
Honestly I am still new to working with Gateways, MGCP, and FXO/FXS ports so I am very unsure of how I should proceed. I don't know if what I have proposed above will work or if its best practice so any advice I receive will be welcomed.
Looking at your scenarion..these remote sites are remote to cucm servers which mean that q921 and q931 signalling will be transversing the wan. Personally when i cant get my mgcp gateway local to cucm, I either go SIP or H323.
So again is there any reason why you want to do MGCP?
Once MGCP is out of the way, the picture becomes much clearer. MGCP just oesnt have limitations of fxo DID etc, you loose the granularity of using voice translation rules as well.
With gateways in SRST, if you insist on using MGCP, then mgcp falls back to default h323. Your DID inboud dial-peer still works, however you may need to create xlation rules to match the actual extension of your phones. With h323 you may have already done this for call in normal operation and hence you will not need to configure it again..
So your MGCP gateway operates as a h323 gateway in SRST. You will define dial-peers for outbound calls to PSTN, you will need to configure translation rules/ other forms of digit manipulation for calls to be routed to your internal numbers.
On your thoughts..Point 1-3 are good plans and you will need them only if you are using h323 gateway. With mgcp no dial-peers are needed except for srst as already mentioned.
You dont need point 4. In SRST mode when the dialled number is matched on the gateway the phone will ring. Remember that when you configure dial-peers to route cals to cucm, you most times use a range..where as in srst a specific match will be found,,,
On Media resources, you are spot on. Configure SCCP resources locally on each site gateway, that way you dont have stuff crossing over the wan
Just a few pointers
Please rate useful posts
"I am complete in God, God completes me"
Please rate all useful posts
"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
Thank you for your extremely helpful response. I will be working this out in my lab right away Monday morning. Its a good to know that for the most part I was right on track for what I should be doing.
To answer your question on MGCP, I use it because that is what I am comfortable with. The consultant that assisted with the initial deployment of some of our locations had used and it recomended that I follow his pattern with future deployments. Like I said I have only had minimal experience with configuring IOS based gateways for CUCM. After reading your post I will definately be exploring the use of H.323 and SIP on my gateways. If you have any useful links handy on configuring a SIP trunk between an IOS device and CUCM that would be awesome as I have had very limited experience with SIP that would be very much appreciated.
I will post back Monday or Tuesday with how things went in my Lab. Thanks again for your response.
Glad to be of help. I am glad you came to the forum. Dont always follow what people say, you make your decisions based on research and sound judgement. You then become a seasoned professional..which I see in you
To configure H323 gateway..there are two parts to it
1. Configuring the gateway on CUCM
2. Configuring dial-peers for routing calls to cucm and to the PSTN on the gateway
NB: When you setup an h323 gateway unlikt mgcp it status does not show as registered. You see the ip address of the interface you have enabled for h323 signalling, but the status is unknow.
Here is a link to configure and understand h323 for cucm
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...