cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2929
Views
10
Helpful
5
Replies

Gateway Support for ISDN Transfer to SIP REFER with UUI

Hello Cisco Experts,

I'm hoping someone can confirm if the following functionality can be configured on a stand-alone Cisco GW without a PGW or other SIP Server/Soft Switch. The GW will most likely AS54xx Series:

  1. Act on mid-call DTMF “*8xxxxxxxxxx” ?
  2. Translate “*8xxxxxxxxxx” to SIP REFER?
  3. Include UUI transmitted in ISDN Set Up Message in SIP REFER/INVITE User to User Header?

- A high level drawing of the call flow is attached and referenced below.

1. INVITE from SIP PSTN to Cisco GW

2. GW routes call to IVR via ISDN/PRI

3. IVR Treats Call

4. IVR initiates "Blind Transfer" via "*8xxx" and includes UUI in ISDN Set Up

5. GW translates "*8xxx" to SIP Refer and includes UUI in SIP Header

Thank you in advance for your help.

Best,

Albert

1 Accepted Solution

Accepted Solutions

Correct, a new call would be then be initiated, to transfer the existing one.

TCL/IVR docs claims to have full control over SIP headers, so working on REFER and UUI headers should not be a problem.

If you are interested in having the script developed professionally, or just a proof of concept, you can contact me at the e-mail address indicated in my profile.

Thank you for the nice rating and good luck!

View solution in original post

5 Replies 5

paolo bevilacqua
Hall of Fame
Hall of Fame

You will need a custom (and accurately written, as it's notr trivial) TCL/IVR script to do that.

Thanks for the quick reply Paolo! I haven't touched a TCL Script in years : )

I apoligize, but just to confirm, all the functionality I referred to above (including the translation of the UUI from ISDN Set Up to SIP UUI Header) can be accomplished with a TCL/IVR  script without interacting with any application external to the Cisco GW?

Thanks Again!

Albert

Yes. Note that if you want the transfer to happen when system sends *8xxxx", there is no ISDN SETUP, and no UUI. The reason is that at least the way you explained the call flow, setup has happened already, from router, and the call is then connected.

That makes sense. I simplified the call flow for illustration purposes.

The solution is intended to front-end a PRI Based IVR to support AT&T IP Transfer Connect. The IVR currently uses "*8xxx" to initiate a Take Back abnd Transfer.

So, if I am correct, the "*8xxx" would not immediatly transfer the call, rather, it would initiate the Q.931 setup.

If the above assumption is correct, would the UUI then be avalaible to insert in the SIP Header?

Thanks again!!!

Correct, a new call would be then be initiated, to transfer the existing one.

TCL/IVR docs claims to have full control over SIP headers, so working on REFER and UUI headers should not be a problem.

If you are interested in having the script developed professionally, or just a proof of concept, you can contact me at the e-mail address indicated in my profile.

Thank you for the nice rating and good luck!