Question on Take back and Transfer (ATT Transfer Connect)

[Jay Schulze]

Hello,

Had a question to exactly how this is seizing the session with SIP. With this service on PRI years ago just using dtmf tones you would hit *8 and it would go back to carrier to initiate the take back. But with SIP I don't believe just hitting *8 from a SIP phone the carrier will know what to do with it. This would just send a notify back to SIP provider. So I guess the best way maybe is to setup a script in UCCE/CVP which would play those tones and send a refer back on that same session?

thanks

[Jonathan Schulenberg]

You need to issue a SIP REFER to the carrier. CUCM will never initiate a REFER but CVP can:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/customer_voice_portal/cvp11_6/configuration/guide/cvvp_b_configuration-guide-for-cisco-unified/cvvp_b_configuration-guide-for-cisco-unified_chapter_010.html#CCVP_RF_R05E7...

Make sure that CUBE is not configured to consume the REFER and instead pass it through to the carrier.

[Jay Schulze]

Thanks Jonathan.

This is what I struggle with. So ATT transfer connect will work natively with midcall DTMF. If we use a refer by going to CVP and returning a dynamic label like *8,,,XXXXXXXXXXX. I guess then ATT will know to invoke the TNT?

[Jonathan Schulenberg]

If DTMF works you would be able to test/reproduce this from your desk phone on any PSTN call. Talk to your AT&T rep to be sure but I do not believe the DTMF-based approach is not supported on the BVOIP offering, especially since they won’t interwork SDP capabilities on a SIP-to-SIP call through their network. The way I have seen multiple customers deploy this feature is with an in-dialog SIP REFER.

[Jay Schulze]

Thanks again for reply.

Yeah that is the problem DTMF from a phone won't work. It will send a notify back to ATT. I just don't know how you could do a warm transfer with this. If I try to do a conf. and send to CVP to return dynamic label. like "DTMF*8,,,,,18XXXXXXXXX". It's actually making a new call. I guess that would be the only way to send a rf back out. But trying to understand how exactly. You send to CVP. But if you do that it's a new call. So call flow would be as such.

--ATT-sip-trunk-w-xfer-connect---Sonus-SBC---CVP--CUCM--jabber-consult---agent then would have to xfer back to CVP?--rf*8XXXXXXXX

But I think this will create a new router call key and not stay on the same dialog. Which really it would just be a trunk-to-trunk xfer within ATT which we're trying to avoid.