01-23-2015 04:22 AM - edited 03-17-2019 01:42 AM
Hi All
I have configured a SIP trunk between my cucms and an Alcatel old pbx on a remote site, they are all identical configs.
However one of them, the remote site Alcatel can call my cucm and voice is ok
But when we try to dial from the CUCM to the Alcatel we are getting the fast busy tone!
Codecs are set etc! as it works one way fine!
any ideas what thsi could be ?
cheers
01-23-2015 05:17 AM
Giving ideas without seeing in detail why the call is failing is like groping in the dark searching for a tiny dropped pin.. :)
Can we look at the logs ie cucm traces? What version of cucm is this?
01-23-2015 05:21 AM
how do i do a trace ?
the call manager is ver 8.6
01-23-2015 05:26 AM
This link will show you how.
https://supportforums.cisco.com/document/126666/collecting-cucm-traces-cucm-862-tac-sr
Ensure you collect the traces from both the server the phone is registred to and the server in the cucm group of the sip trunk. If you have two servers there, then collect the trace from both. When you attach the log file, include the calling and called number along with the time of test call. You will need to do another test call after you have enabled cucm traces.
01-23-2015 06:02 AM
Hi here is a snip of the trace for the call
the calling phone was ext 448 the called number over the sip trunk is 88044615
cheers
16
2015/01/23 08:15:31.897|CC|REJECT|26821723|26821724|476|8804615|8804615|1
2015/01/23 08:15:43.577|CC|RELEASE|26821726|26821727|16
2015/01/23 08:15:54.907|CC|SETUP|26821728|26821729|476|88044615|88044615
2015/01/23 08:15:54.909|CC|OFFERED|26821728|26821729|476|88044615|88044615|SEPC4641301122E|DELHI-SIP-TRUNK
2015/01/23 08:15:55.273|SIPT|26821729|TCP|OUT|172.24.32.34|5060|DELHI-SIP-TRUNK|172.20.65.5|5060|1,100,13,53766610.2^*^*|13409968|cf27ae80-4c211f5a-1d65c-222018ac@172.24.32.34|INVITE
2015/01/23 08:15:55.640|SIPT|26821729|TCP|IN|172.24.32.34|5060|DELHI-SIP-TRUNK|172.20.65.5|5060|1,100,63,1.4651678^172.20.65.5^*|13409969|cf27ae80-4c211f5a-1d65c-222018ac@172.24.32.34|100 Trying
2015/01/23 08:15:56.012|SIPT|26821729|TCP|IN|172.24.32.34|5060|DELHI-SIP-TRUNK|172.20.65.5|5060|1,100,63,1.4651679^172.20.65.5^*|13409970|cf27ae80-4c211f5a-1d65c-222018ac@172.24.32.34|403 Forbidden
2015/01/23 08:15:56.012|SIPT|26821729|TCP|OUT|172.24.32.34|5060|DELHI-SIP-TRUNK|172.20.65.5|5060|1,100,63,1.4651679^172.20.65.5^*|13409971|cf27ae80-4c211f5a-1d65c-222018ac@172.24.32.34|ACK
2015/01/23 08:15:58.668|CC|RELEASE|26821728|26821729|67108885
2015/01/23 08:16:02.133|CC|SETUP|26821730|26821731|4133320804|467|467
2015/01/23 08:16:02.136|CC|OFFERED|26821730|26821731|4133320804|467|467|172.24.32.38|SEPC464130114C0
2015/01/23 08:16:18.712|CC|SETUP|26821733|26821734|568|487|487
2015/01/23 08:16:18.714|CC|OFFERED|26821733|26821734|568|487|487|SEPC464130117E9|SEPC4641301147E
2015/01/23 08:16:20.151|CC|SETUP|26821730|26821737|4133320804|467|1999
2015/01/23 08:16:20.157|CC|OFFERED|26821730|26821737|4133320804|467|1999|172.24.32.38|CiscoUM1-VI54
2015/01/23 08:16:20.159|CC|RELEASE|26821731|0|0
2015/01/23 08:16:28.151|CC|RELEASE|26821730|26821737|16
2015/01/23 08:16:31.997|CC|SETUP|26821738|26821739|476|88044615|88044615
2015/01/23 08:16:31.998|CC|OFFERED|26821738|26821739|476|88044615|88044615|SEPC4641301122E|DELHI-SIP-TRUNK
2015/01/23 08:16:31.999|SIPT|26821739|TCP|OUT|172.24.32.34|5060|DELHI-SIP-TRUNK|172.20.65.5|5060|1,100,13,51956482.95772^172.24.48.180^SEPC4641301122E|13409978|e5356f00-4c211f7f-1d65d-222018ac@172.24.32.34|INVITE
2015/01/23 08:16:32.366|SIPT|26821739|TCP|IN|172.24.32.34|5060|DELHI-SIP-TRUNK|172.20.65.5|5060|1,100,63,1.4651682^172.20.65.5^*|13409979|e5356f00-4c211f7f-1d65d-222018ac@172.24.32.34|100 Trying
2015/01/23 08:16:32.764|SIPT|26821739|TCP|IN|172.24.32.34|5060|DELHI-SIP-TRUNK|172.20.65.5|5060|1,100,63,1.4651683^172.20.65.5^*|13409980|e5356f00-4c211f7f-1d65d-222018ac@172.24.32.34|403 Forbidden
2015/01/23 08:16:32.764|SIPT|26821739|TCP|OUT|172.24.32.34|5060|DELHI-SIP-TRUNK|172.20.65.5|5060|1,100,63,1.4651683^172.20.65.5^*|13409981|e5356f00-4c211f7f-1d65d-222018ac@172.24.32.34|ACK
2015/01/23 08:16:39.148|CC|RELEASE|26821738|26821739|67108885
2015/01/23 08:16:44.261|CC|SETUP|26821740|26821741|4133320804|465|465
2015/01/23 08:16:44.263|CC|OFFERED|26821740|26821741|4133320804|465|465|172.24.32.38|SEPC46413011466
2015/01/23 08:17:26.622|CC|RELEASE|26821733|26821734|16
2015/01/23 08:17:33.320|CC|SETUP|26821743|26821744|568|536|536
2015/01/23 08:17:33.322|CC|OFFERED|26821743|26821744|568|536|536|SEPC464130117E9|SEPC46413011477
2015/01/23 08:17:44.673|CC|RELEASE|26821706|26821707|16
2015/01/23 08:18:38.248|CC|RELEASE|26821713|26821714|16
2015/01/23 08:18:51.306|CC|RELEASE|26821740|26821741|16
2015/01/23 08:18:53.509|CC|SETUP|26821746|26821747|447|033255961|033255961
2015/01/23 08:18:53.513|CC|OFFERED|26821746|26821747|447|033255961|033255961|SEPC46413011482|172.24.32.38
2015/01/23 08:18:53.739|SIPL|0|TCP|IN|172.24.32.34|50
01-23-2015 06:37 AM
Hi Carl
I believe a detailed SIP trace captured would give more information. However I can see that the Alcatel sends to the CUCM SIP 403 Forbidden message in which indicates whether that the Alcatel doesn't trust the IP address of the CUCM or the Client might not accepting calls due to unregisteration . I wonder if the Alcatel PBX is having a setting to trust incoming communications from certain IP address ranges? if yes can you add the CUCM Callmanagers (ALL CUCM cluster IP Addresses including Subscribers). Is there a Cisco CUBE in the middle? if yes you should change the VOIP trust list to include the IP address of the CUCMs as well.
hope that helps
MonieM
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