The first frame is an outbound rule and governs what the device must see in the dialing pattern before it will allow the call to pass to the trunk.
The privilege level is a relative setting that you can use to establish various tiers of allowed extensions to use the rule. While they are labled as local, national, etc., the names have nothing to do with the actual calling area, but rather they form a hierarchical chain such that those with the highest level (international) can access and make use of any outbound rule and those with lower authority (local for example) can access local and internal, but will not be able to use the national and international rules.
The frame with network settings is more of a personal preference…along with your environment. As your provider apparently has an SBC on site, I am assuming that you also have an internet facing firewall/router apart from the UCM given that the UCM is set to route mode and both the LAN and WAN are using private IPs. If it were me, I would get the provider to change the SBC IP to be within the same LAN segment as the other devices so I could treat it as any other device connected to the LAN. I would then change the UCM to be in switch mode as the route function adds no value and only complicates things. If the provider will or won’t change, then perhaps you can change the environment to his LAN segment.
I will assume the provider settings for the trunk are OK as you indicated outbound is fine. I do encourage you to examine the codec settings in the trunk as well as the extensions and only select those that are needed by the provider. There is no value in sending extraneous codec offerings when many will never see the light of day in use. It is merely added traffic that could be hampered by MTU settings. Fundamentally, it’s extra baggage with no benefit.
On the inbound rule, we need to understand how the provider is delivering the DID. The UCM is very specific with regard to the format and which header is used and while the trace shows 526XXXX, it also shows the it in the TO header and the trunk settings are set for the request line. Please change this to reflect the TO header.
As you were able to get a capture, you should make the suggested changes and make a test call while doing a capture and once complete download the capture, open wireshark and go to the Telephony tab at the top and then VoIP Calls and highloght the test call and then select flow. This will provide a graphical representation of the message flow between the UCM and the SBC and will show if there was some error provided by the UCM that will reveal why the call did not progress. Hopefully, the call will be successful, but if not we can see why with the trace.
Also, I am making the assumption that -
- The phones in question are registered to the UCM
- Calls have been successfully made between the various extensions so that we know that they work.
While testing I suggest that you change the alert-tone back to the default instead of Alert 4. The intent is to start slow and easy and once it functions correctly,…then you can go back and change to your desire.