Which SIP message triggers use of Rerouting Calling Search Space (CSS)?

[voip7372]

Can someone tell me exactly what SIP message or header inside a SIP message triggers the use of the Rerouting CSS on a SIP trunk for an incoming call that was transferred?  We have a SIP trunk from an AudioCodes SBC to ME Teams and for various reasons we'd like to have transferred calls from MS Teams to the CUCM use the Rerouting CSS for that SIP trunk the calls comes in on to CUCM.  

Also, can you point me to any documentation that provides detail on this?  I found very general info about it on Cisco's web site but not any fine detail so we can know for sure what CUCM uses in a SIP message or what TYPE of SIP message it needs to see to trigger the Rerouting CSS.  As I understand it, I 'think' it uses a REFER message to trigger the use of the Rerouting CSS and NOT for example, a referred-by header inside an Invite message, is that right?

This is an example of a REFER message sent by MS Teams to the AudioCodes SBC.  I haven't yet gotten to the point where we can get the REFER message all the way to CUCM from Teams, via the AudioCodes SBC because of the config already in use, which we might change depending on what I learn here about what triggers CUCM to use the Rerouting CSS, but once I know for sure what CUCM needs to use the Rerouting CSS, I'd like to make changes and test it. So anyway, here's the REFER from Teams to the SBC.  Is THIS what CUCM needs or is it something else?   Any detail/examples of a SIP message you can give would be great.  

REFER sip:+15132223333@us-voice-sbc..domain.com:5061;transport=tls SIP/2.0
FROM: <sip:+15132223333@us-voice-sbc..domain.com>;tag=b128ac22817b453c83c1af09484e7cd9
TO: <sip:+15132223333@company.domain>;tag=1c1309202146
CSEQ: 6 REFER
CALL-ID: 129036129964202161311@us-voice-sbc..domain.com
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 52.114.1.0:5061;branch=z9hG4bK7adc02e
CONTACT: <sip:api-du-a-uswe2.pstnhub.microsoft.com:443
CONTENT-LENGTH: 0
REFER-TO: <sip:+15137211700@sip.pstnhub.microsoft.com:5061;user=phone;transport=tls>
REFERRED-BY: <sip:sip.pstnhub.microsoft.com:5061
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2021.3.29.2 i.USWE2.5
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

[Sarg .]

Looks like no one has replied this one.  Personally, I think you need to upload the full trace so we can answer the question for ourselves by following the call. However, that refer message is enough to trigger a transfer. I have seen such refer messages trigger transfers with expressway/vcs. And if cucm is trying to use the re-routing css, you will also know if you have cucm detailed logs on because you will see cucm list the partitions in the css before throwing up an error when it does not see a partition that would permit the call. 

#

[voip7372]

The call logs won’t really help in this case because we don’t have the audiocodes SBC configured to send the REFER message to CUCM...yet. I had everything configured and working perfectly but there was one snag in the plan. I had it working so that when someone in teams transfers or forwards a call, the audiocodes box would add a diversion header with the number of the person in teams making the transfer (which is that person’s assigned office number), so that would get the call past Verizon without failing because the diversion header with the office number allows the call to pass. I also had it configured so the asserted identity header would be updated to show the original calling party number, so if you transfer or forward the call, you see the number of who was actually calling you rather than the office number that originally was called. That way the third-party that was ultimately called via transfer or forward would see who is really calling them.

What I’m trying to solve now is, we like to use the office calling party number to initially route the call in CUCM to the proper PSTN gateway because it might be in a different country for example. I discovered that because of the way I am updating the asserted identity header with the number that originally called, this breaks the ability to initially route the call based on the office calling party number when the call arrives at CUCM. Then we had the idea to use the rerouting calling search space to fix this and presumably by using the original called number which is the office number in the refer message and that would allow the ‘route by calling party number’ to work correctly for us.

Anyway, for this posting, what I’m trying to figure out is if in fact that REFER message is exactly what CUCM is looking for to trigger the use of the rerouting calling search space and if it is, we will need to reconfigure the audiocodes device so that it has everything it needs to send the proper messages to CUCM including the refer message along with a diversion header with the proper number also. It’s a little bit complicated but I have it working the way we want with that one exception.

[voip7372]

In case anyone is watching this of finds it later, Cisco TAC did confirm that CUCM must get a REFER message similar to the one below to trigger the use of the Rerouting CSS.  

The number in the FROM header is the number that transferred the call and the REFER-TO is the number that the call was transferred to.

REFER sip:+15132223333@us-voice-sbc..domain.com:5061;transport=tls SIP/2.0
FROM: <sip:+15132223333@us-voice-sbc..domain.com>;tag=b128ac22817b453c83c1af09484e7cd9
TO: <sip:+15132223333@company.domain>;tag=1c1309202146
CSEQ: 6 REFER
CALL-ID: 129036129964202161311@us-voice-sbc..domain.com
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 52.114.1.0:5061;branch=z9hG4bK7adc02e
CONTACT: <sip:api-du-a-uswe2.pstnhub.microsoft.com:443
CONTENT-LENGTH: 0
REFER-TO: <sip:+15137211700@sip.pstnhub.microsoft.com:5061;user=phone;transport=tls>
REFERRED-BY: <sip:sip.pstnhub.microsoft.com:5061
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2021.3.29.2 i.USWE2.5
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY