There appears to be some duplication with the regards to the POTs dial-peers here in the configuration.
The dial-peers begining 999 are usually automatically configured and associated with MGCP controlled ports when configured through CallManager:-
dial-peer voice 999010 pots
dial-peer voice 999011 pots
dial-peer voice 999012 pots
The strange thing about these is that the service mgcpapp has been removed. However these voice-ports are still associated with mgcpapp on the following dial-peers instead, with the exception of port 0/1/3:-
dial-peer voice 40 pots
description Order line
dial-peer voice 41 pots
description FAX machine
dial-peer voice 42 pots
description Overhead Paging
If a device is connected to port 0/1/3, then it possible for this device to receive inbound calls, make outbound calls or both.
You should find that these voice-ports are configured on the appropriate gateway within CallManager, and will also have an attendant DN configured. The port should also indicate whether the port is for inbound, outbound or both.
The destination-pattern would be configured on a pots dial-peer specifically for SRST fallback if configured. Otherwise there is no use for the command as the port is controlled by mgcp, and the DN or destination-pattern is in CallManager.
Can you tell me how I would get to the place withing call manager you are talking about?
I am thinking since the existing router will be moving to the new site and the IP Addressing insternally will be the same, nothing needs to be done other than just move the router to the new PRI and port the numbers over and everything should be fine (as long as the devices go to the correct FXS ports).
Also, if you didn't notice, this is from the same branch that will be moving soon.
Your assistance was very helpful on the earlier post.
I used your sample config and it worked like a charm.
Thanks for the appreciation, glad to hear that you were able to test the PRI successfully with the sample config I provided.
Apologies, this is from memory, within the Device menu in CallManager admin, select Gateways and when the page displays click find. A list of configure gateways should be returned.
I suspect that there will be more that one, so click on the gateway which has the correct IP address or HostName.
When the page is displayed with the gateway, on the righthand side you should see all the FXS endpoints. Simply click on one of these ports, and from here the DN will be evident.
If the LAN IP addressing is remaining static, and the WAN interfaces, then yes you need to change anything. However if the WAN is IP addressing is changing, you will probably have to change your default-route.
Hi Richard, when configure an FXS port from within CallManager from new, there is a link on the page to add a new line. No different from when you add a line appearance to Phone.
This DN number would only normally appear in CallManager and is not configured in the router. When Callmanager receives an incoming for this DN is recognises which port is associated with the DN.
As I have said before, disregard the fact that there is a destination-pattern on the POTs dial-peers.
This is not configured by CallManager when the configuration is dowloaded to the gateway. This must have been added additionally, and the only reason for this is for fallback to H.323(SRST). In this scenario the signalling is not backhaul to CallManager and instead the gateway matches the outgoing dial-peer using the destination-pattern when the CM is down.
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...
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 discusses the bas...