01-31-2019 11:15 AM - edited 03-17-2019 02:02 PM
Good day Experts
I have two questions
1. I am failing to make outbound calls on my SIP trunk
CiscoGW<-----------------SIP trunk-------------->CUCM
I can make ingress calls but i cant make egress calls attached is my Route Patterns and Partitions.
2. I will have to put a second SIP trunk could someone help me with how i will have separate Translation rules and translation patterns. First one A my CUCM and second one B my thirdparty PBX.
I don't get to make the two work in harmony but lets tackle Question one first then we can do two issue is only one SIP trunk works at a time....
02-01-2019 01:49 AM
02-01-2019 06:35 AM
In addition please collect "debug ccsip messages" from the voice gateway and post them here along with the calling and called numbers.
02-03-2019 11:41 PM - edited 02-03-2019 11:41 PM
Chris The calls are not even hitting the Voice GW i did run the debug to check outgoing calling nothing is coming
As stated Ingress calling works.
That leaves me to check my CSS etc on the call manager...
Question 2: How do i make the two SIP trunks work on the gateway?
02-04-2019 05:30 AM
To be 100% sure the call does not make it to the GW, do you see the SIP messages when debugging inbound call?
If yes, then what does DNA show on CUCM side, can you post screen shot of DNA results?
02-05-2019 03:18 AM
Good day Chris
I am able to make inbound calls to extension inside, I am not able to make external calls ( egress)
A debug on incoming calls i get terminal output.
I dont get any output for outbound actually the call drops as soon as i press # to place the call i get an engaged tone which points to me that its an issue on the call manager i need to surely run with DNA and see where my call is dropping
I will share my DNA output this evening
02-06-2019 08:59 AM - edited 02-06-2019 09:43 AM
Good day Chris
Please check the results of the DNA we still getting an engaged tone when trying to call out. So we can not make outgoing calls, but we can make incoming calls. On the Gateway we can not see any Debug output for " Debug voice ccapi inout " for outgoing calls.
Also note that we are removing MGCP off the Cisco GW before we configure SIP on it. But we are not tempering with any configuration of MGCP on the CUCM. We are just configuring SIP trunks to the Gateway. When this is done we can get Ingress calls in this manner Telco---->Gateway----SIP trunk----CUCM------ Extension. No out going calls we get a busy tone.
Check the screen snipet from the DNA that we did.
Awaiting your analysis
02-06-2019 09:44 AM
Your DNS screen shot is incomplete, please expend all branches and provide the full screen shot.
What we do see is that from CUCM perspective the call should be routed "Match Result= RouteThisPattern" going to New-SIP-Trunk-Gateway, is this the correct trunk?
Do you have proper dial-peers, e164 map that would route 90977965787, and strip the off-net code, etc. Can you post "show run" from it?
Can you also do "debug voice dialpeer" when making the test call?
02-06-2019 10:55 AM - edited 02-06-2019 11:01 AM
Good day Chris
What we do see is that from CUCM perspective the call should be routed "Match Result= RouteThisPattern" going to New-SIP-Trunk-Gateway, is this the correct trunk?
The above is correct, it is the correct trunk.
The out bound call cannot even hit the Gateway router we tried debug "voice ccapi inout" we do not get any output. We get a busy tone when we call out and call drops instantly.
What we have noticed is in the Route groups we seem not to have a proper configuration here. any guidance? we seem to think MGCP is still messing us up we don't seem to see any SIP Route Groups gateways.
Please check the last attachment with a sample of a a SIP route group we found online
02-06-2019 11:23 AM
According to the output from DNA it was using the SIP trunk, not the Route group pointing to your MGCP GW, but you still have not provided full DNA screen shot.
Are you positive your logging is properly set on your GW, do you see other events, i.e. inbound call, I know I asked this, but I don't think I saw an answer. This is common mistake.
If so, next step is you will need to look into CUCM trace logs to see exactly what is happening, you can pull the CallManager log using RTMT and you can post it here along with information on called number, calling number and timestamp.
02-06-2019 11:45 AM
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