Cisco CUCM to Alcatel PBX SIP calling issues

[carl_townshend]

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

[Ayodeji Okanlawon]

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?

[carl_townshend]

how do i do a trace ?

the call manager is ver 8.6

[Ayodeji Okanlawon]

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.

[carl_townshend]

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

[abdel-moniem]

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