06-02-2018 12:27 PM - edited 03-17-2019 12:56 PM
Placing a call from one UCM 11.5 cluster to the next the call fails. The phone rings on the other end the call is dead. The setup..... CUCM 11.5 <SIP Trunk> CUBE<SIP Trunk> CUCM 11.5 using two 7965 (SCCP) on both ends.
Attached is the sdl trace, debug ccsip error and debug ccsip messages.
Any help is appreciated.
06-02-2018 08:02 PM
Why aren't you just trunking directly between CUCM clusters?
06-03-2018 01:06 PM
06-03-2018 06:09 AM
what is the 64.12 IP addres that initiates the call.
I verified the SIP trace and is never seems to receive an SDP to negitiate a codec.
the 200OK with SDP is received by 64.254 but not sent onwards to .12.
can you test between early offer SIP on your trunk
06-03-2018 01:09 PM
06-03-2018 01:34 PM
06-04-2018 07:26 AM
06-04-2018 11:27 AM
I don't like that the 200 OK from 65.11 isn't being responded to by the cube, at all.
even if you had a codec problem, you'd expect some complaining for us to look at.
I'd investigate https://quickview.cloudapps.cisco.com/quickview/bug/CSCuu89938
and make sure you've not hit that.
Adam
06-04-2018 12:22 PM
06-04-2018 01:03 PM
06-04-2018 02:23 PM
06-05-2018 12:59 PM
06-05-2018 02:29 PM
Please can you configure the originating call manager to send to the cube using UDP transport as well?
The TCP send error is with sending a 200 ok back to the originating call manager from the cube.
The receiving call manager is not getting an ACK from the cube and is resending its 200 ok.
thanks
06-05-2018 09:11 PM
06-05-2018 11:13 PM
1. 64.11 sends an invite to the cube at 65.254.
cube responds back with a 100 trying
2. 65.254 send an invite to 65.11
65.11 reponds back with 100 trying
180 ringing
3. cube sends 180 back to 64.11 (check point)
4. 65.11 sends 200 OK
5. Cube sends back ack to 65.11 straight away,
6. cube 65.254 send 200OK to originating CM at 64.11
7. cube does not get an ACK and retransmits the 200
8. you give up and 65.12 send a BYE
9. Bye is Ack by the cube straight away
10. Bye is send to 64.11 from cube but is not acked by 64.11 ;-(
It looks to me that there is a firewall or something blocking udp sip messages from 65.254 to 64.11
or perhaps's there's an IP route missing on the cube. Can you ping 64.11 from 65.254 ??
I suspect you did not hear ringback on the originating handset - see step 3. This would indicate that 64.11 did not receive the 180 ringing
The ack sent by the cube in step 5 and 10 indicate you're cube is in a super b2b mode which is quite fancy. I'm not actually familiar in how this is configured on a cube, so once this is fixed, It would be nice if you could share your config with me.
Good luck
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: