Blind OffNet to OffNet Transfer via CUBE Fails

[chuck.brule]

Guys:
Sticky wicket here.

We have a CUCM 8.5.1 SR3 cluster connected via SIP to a 3945E running 15.3(3)M as the CUBE.

Supervised Transfer of OffNet callers to OffNet destinations works like a champ.

Blind Transfer fails every time.

It seems like the CUBE is failing to respond to a 183 with the PRACK CUCM is sending it. But I need more experienced eyes on these traces to make sure I'm not sounding like a moron when I call TAC and ask them why the hell the CUBE is not responding correctly.

Any help would be greatly appreciated, guys. Attached is the Debug ccsip messages output from the affected call flow.

Chuck

[Ayodeji Okanlawon]

Chuck,

I coudlnt look in detail into the traces because my notepad++ is not working correct at the moment...but I had a breif look and what I see is that CUCM is sending a BYE with a cuase code of 47.

This most likely points to an MTP issue. We will need to see the detailed CUCM traces to narrow down why CUCM is doing this...

To confirm its MTP related, you can do a quick test and select insert mtp when needed or have mtp enabled on the sip trunk..

580167: Nov 20 10:03:38.528 PST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

BYE sip:2533804539@10.32.30.128:5060 SIP/2.0

Via: SIP/2.0/UDP 10.32.3.34:5060;branch=z9hG4bK73f5b3d76eb4b

From: <5412270318>;tag=1261737~56ac271d-fe35-46f0-ae58-e8ce52302586-56990749

To: "C KIRKPATRICK" <2533804539>;tag=FE9CA04C-C61

Date: Wed, 20 Nov 2013 18:03:26 GMT

Call-ID: D4CD3D73-514411E3-9E2FB500-25117E09@10.32.30.128

User-Agent: Cisco-CUCM8.5

Max-Forwards: 70

CSeq: 105 BYE

Reason: Q.850;cause=47

Content-Length: 0

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[chuck.brule]

I don't buy that the MTP is the fix-all for this one, man. We checked the "insert MTP as needed" checkbox the other night and it still fails. (That box also broke Mobility for a strange reason so we took it off).

Looking at the traces shows the CUBE fails to pass a PRACK to a 183 on to the SP (CUCM sends this PRACK to CUBE and gets an OK for it so I know that piece is working). This looks like an issue at the CUBE IMHO, but I need some validation or at least some deeper inspection in the traces.

Help?!

Chuck