Got CUBE in Direct routing setup with Teams Phone system. If an external mobiles calls into Teams and performs a "consult transfer" to another mobile it intermittently (2/10 times) get transfer failed. Note REFER method is disabled due to other issues so just using standard INVITE leg for transfers.
Going thru CCSIP trace of consult transfer failure (SIP ladder attached) I can see 500 internal error coming from SBC. If I compare that to working consult transfer trace the only difference I see is 200 OK for the RE-INVITE (highlighted with sdp a=inactive) is waited upon before MS SIP proxy (52.114.16.74) sends re-invite . Transfer works as normal then. Whereas in non-working trace MS SIP proxy (52.114.16.74) doesn't wait for 200 OK before sending it's INVITE w/ SDP (sendrecv). SBC consequently responds back with 500 internal Server error.
I came across RFC 3261 (SIP) section 14.2 stating
"A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE"
https://datatracker.ietf.org/doc/html/rfc3261#section-14.2
wanting to validate is that possibly what's going on here ? has someone come across this and found a fix ? If there's a way perhaps on SBC to block (or induce delay) to consume/discard an invite until 200 OK hasn't been responded to for a previous INVITE ?
appreciate any feedback. MS support not going anywhere with this so thought I'd check in our community. SBC is a Cisco CUBE .. snippet of SIP ladder for both working and non-working below .. initial part of the incoming call which works fine anyway is omitted (wouldn't fit) .
I have attached SIP ladder for both the non working and working consult xfer. appreciate any feedback please. There is no CUCM . just CUBE and Teams.
