[cisco-voip] CUBE/SIP Issues on Blind Xfer

[Daniel Pagan]

Folks:

I'm working an issue where blind transfers into UnityCx result in ring back followed by a disconnect. Grabbed detailed CCM traces and ccsip debugs off CUBE and the issue seems to be caused by CUBE and its call-leg to the ITSP. All call-legs except those for the IP phone and Annunciator devices utilize SIP.

In a nutshell, the issue I'm seeing is that CUBE fails to continue transmitting the appropriate SIP transactions to the provider. I know this sounds vague so I'll diagram it below:

::: UnityCx receives the transferred call - replies to CUCM with 100 then 180 Ringing.
::: MediaMgr invokes an annunciator successfully to provide CUBE w/ ringing - transactions to connect CUBE to ANN below:

CUCM======CUBE=======ITSP
INVITE------->
TRYING<------
INVITE------>                      ||CSeq #110
                                200<---------                       ||SDP
200<----------                                                      ||SDP
ACK---------->                                                    ||SDP w/ c= .... <Annun_ip_addr>
                                ###NO ACK HERE###

::: UnityCx answers the call - CUCM attempts to disconnect CUBE/ANN
::: Transactions for this are below:

UNITYCx=====CUCM======CUBE=======ITSP
200----------->
                                INVITE-------->                                                  ||SDP w/ a= inactive
                                100<-----------
                                                                ACK--------->                      ||CSeq #110
                                                                ##NO reINVITE OUT##

:: This triggers the MX streaming timeout and MediaMgr deletes the call CIs

CUBE was upgraded to 15.1(4)M6 a few days ago. Has anyone encountered this problem before? CUBE sends the ACK to close the final response for connection to the Annunciator late on the ITSP side... then no INVITE request is sent to proceed with the new request after UnityCx connects. SIP transactions remain idle and the MX streaming timeout occurs after 8 seconds. At first, I thought "well... CUBE is still sending the ACK to the provider w/ the correct CSeq.. so it being late in the order of operations shouldn't be a problem", but late or not, CUBE should still reINVITE after the ACK.

Thanks for reading through this. Thoughts?

- Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131018/29b5c77a/attachment.html>