CUCM 11.5 SIP TRUNK using CUBE

[fourier.ross1]

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.

[Andrew West]

Why aren't you just trunking directly between CUCM clusters? 

[fourier.ross1]

Andrew.....Thanks for the reply but the design is what we have to work with. CUCM 11.5 <SIP TRUNK> CUBE<SIP TRUNK> CUCM 11.5.

[Dennis Mink]

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

[fourier.ross1]

Dennis thanks for the reply. 64.12 is the Subscriber CUCM 11.5. I will check Early offer and let you know the results.

[fourier.ross1]

Dennis.... I tried Early offer Mandatory (insert MTP if needed) and Best Effort (no MTP inserted) and both give Fast Busy when I try to place a call.

[fourier.ross1]

Attached are the debugs with Early Offfer "Best Effort (no MTP inserted)" enabled on the SIP trunk profile.

[ADAM CRISP]

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

[fourier.ross1]

Thanks for the info Adam. Unfortunately, looks like this is supposedly fixed in 15.5.3.M7. I will try to upgrade IOS to 15.6.3M4 and post the results.

[ADAM CRISP]

Yeah, or maybe try udp..

[fourier.ross1]

Adam, thanks for the suggestion. I will try UDP prior to IOS upgrade and post the results. Stay tuned.

[fourier.ross1]

Changed SIP profile to use CDP only. The call routes but when answered dead air then fast busy. Attached debugs and SDL traces.

[ADAM CRISP]

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

[fourier.ross1]

Removed the SUB from the CM Group. Set SIP profile for outgoing to use UDP. 

See attached Debug casio messages.

[ADAM CRISP]

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