11-14-2022 02:36 AM
Dear all,
I am unable to call outside or inside phones give a busy tone and the call is not hitting the router
UCS is connected to a cisco switch which is connected to the cisco core and core to sip router
internal calling is working fine
I think the issue is in sip trunk page configuration on cucm
Pls guide
11-14-2022 02:39 AM
What troubleshooting steps have you done? Have you checked the RTMT logs?
How can you confirm, that the call wasn't even reaching the router?
Why you think it's a problem on the sip trunk configuration page? Have you resetet the sip trunk in CUCM (it's mandatory)?
Without any more info, nobody will be able to help you?
11-14-2022 05:14 AM
11-15-2022 10:28 AM - edited 11-15-2022 10:29 AM
Advice you to make these changes to your voice gateway configuration to clean it up and to fix a few things not setup correctly.
voice service voip
ip address trusted list
ipv4 0.0.0.0 0.0.0.0 !This is a very bad thing to do as you turn off all the built-in toll fraud protection that exist in the gateway. Advice you to rework this to only allow what is needed to communicate with the gateway, in most cases this is the CM and the ITSP node IPs.
no allow-connections h323 to h323 !Not needed when you use SIP to SIP
no allow-connections h323 to sip !Not needed when you use SIP to SIP
no allow-connections sip to h323 !Not needed when you use SIP to SIP
username admin privilege 15 password 0 BN@1122 !Not good that you have the pw in clear text. Add this to your config to encrypt it, service password-encryption
interface GigabitEthernet0/0/0
no ip address
negotiation auto
!
interface GigabitEthernet0/0/0.20 !Why are you using a sub interfgace for this? You might simplify this by using the physical interface to define the IP address.
description *** VOICE ***
encapsulation dot1Q 20
ip address 10.10.20.1 255.255.254.0
no ip default-gateway 10.170.11.233 !Not needed, only used for a switched setup, not applicable when runing as a router.
no ip http server !Not needed and concidered a security risk when activated.
no ip http secure-server !Not needed and concidered a security risk when activated.
ip tftp source-interface GigabitEthernet0/0/0 !or GigabitEthernet0/0/0.20 if you still want to use sub interface
voice class uri PSTN sip !Add to match on VIA header for inbound calls from PSTN.
host ipv4:10.141.40.233
!
voice class uri CUCM sip !Add to match on VIA header for inbound calls from CUCM.
host ipv4:10.10.20.5
dial-peer voice 1 voip
description ** Outbound dial peer to CUCM **
no incoming called-number 011216379.
voice-class sip bind control source-interface GigabitEthernet0/0/0 !or GigabitEthernet0/0/0.20 if you still want to use sub interface
voice-class sip bind media source-interface GigabitEthernet0/0/0 !or GigabitEthernet0/0/0.20 if you still want to use sub interface
dtmf-relay rtp-nte sip-kpml
!
dial-peer voice 2 voip
description ** Outbound dial peer to PSTN **
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
!
dial-peer voice 3 voip
description ** Inbound dial peer from PSTN **
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
no destination-pattern 5000
no session target ipv4:10.10.20.5
no incoming called-number 216379.
incoming uri via PSTN
!
dial-peer voice 4 voip
description ** Inbound dial peer from CUCM **
session protocol sipv2
incoming uri via CUCM
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0/0 !or GigabitEthernet0/0/0.20 if you still want to use sub interface
voice-class sip bind media source-interface GigabitEthernet0/0/0 !or GigabitEthernet0/0/0.20 if you still want to use sub interface
dtmf-relay rtp-nte sip-kpml
no vad
Once you have this setup make sure that you send calls from CM to the VGW as you think you do. The easiest way to check if the configuration is correct is to do a DNA and simulate the call routing as calling from a phone. This should show you that CM thinks that it sends the call to the SIP trunk for the VGW. Once you know that is true you can start looking in the gateway by turning on these debugs in parallel, debug voip ccapi inout and debug ccsip message, once you have done that do a term mon to get the output in the SSH session. Capture that output and post it here as an attached file so that we can verify what happens in your gateway.
11-15-2022 12:48 PM
+5 to @Roger Kallberg for another amazingly thorough answer!
11-14-2022 05:55 AM
If you see nothing on the gateway, why don't you check the CUCM logs first?
Is CUCM able the reach the gateway? Is there a FW in between, that my block it? Is the IP routing correct? If you use multiple VLANs, is the inter-VLAN routing working?
It seems, that CUCM cannort reach your gateway, so you have to start troubleshooting on CUCM.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide