Transfer from Experience Portal to CM Via SIP

[AirForces2050]

Hi All,

I am making a new configuration to switch from H323 to SIP via Session Manager. Till now I can get the call from 3rd Party SBC to Session Manager and from Session Manager to Experience Portal, Where Experience Portal plays an IVR App then it redirects the call to a VDN.

However, in the last step the blind transfer fails from the IVR App on Experience Portal to the VDN.
For Example, the IVR app transferes to VDN 5000 then experience portal traslates this to 5000@avaya.com then it is supposed to get back to SM for reidirection to CM but it fails here.
Any one have an idea where the problem could be?

 

[kyle555]

Is it via SIP REFER? AAEP transfers via refer. SM only routes digits on INVITES. To say, a refer is within an existing dialog - it is telling the SBC to refer the call to 5000. Now, the SBC passes that to the carrier on the other side - and of course it has no idea what 5000 means.

So, each transfer point has a DID and transfer to that, or, the Avaya SBC has something called refer handling where it translates a refer to a reinvite and instead of passing it out to the carrier, passes it back in to the call server (SM). So, a REFER to 5000 from AAEP goes to SM to the SBC, to a reinvite to SM, to CM, to a call flow, and it gets bridged that way. Presumably any decent SBC would have some mechanism to handle refers like that because it's too common a scenario that you need to transfer to a private number via SIP REFER. That, or change the way AAEP does transfers if that's even possible. It may be - I'm not sure off hand - but even if it were, it'd use up a second channel until it was able to transfer out.

 

[jimbojimbo]

Many many possibilities...

First of all, I try to always route the call through CM first. Gives me control of the call and when transferring the call back to CM the signal redirect is really between two trunks in CM so not dependent on third party (SBC)

Second, when transferring to a VDN you need to make sure the first thing you do is play a two second announcement (can be dead air) in order to anchor the call and get the 200 Okay. Otherwise strange things happen.

 

[AirForces2050]

@kyle555
Yea this is via SIP REFER. I think what you have clarified is what is really happening. I will try with the 3rd Party SBC if they can convert the REFER to Re-invite and see what will happen.
Thank you very much for these precious info.

@jimbojimbo
I have tested to route to CM and it is working just fine. also I put in vector 2 seconds silence but didn't solve the issue.
Thank you.

 

[Dilip1984]

Hi ,
We have a problem with SBC not sending "ACK" back to "200 Ok" from Service provider, The call flow is like this ,
User Calling from outside -> SBC -> SM -> Genysis IVR -> call transferred to Agent -> Agent transferring to Outsider Using Call manager through SM and SBC again.

But Here , When the refer comes second time from SM to SBC to route the call outside , SBC creating "ReInvite" to Service provider and Sending back "Invite" to SM again. we are receiving "200 Ok" from Service provider but SBC is not sending "ACK" to Service provider as SBC is not getting "200 Ok" back from SM and finally the timer expires after 32 Second , service provider Sends "BYE" and call disconnects.

Can you please suggest what changes should be required on SBC /SM to establish this connection..

Thank you All.....

 

[kyle555]

reinvite to the provider is to hold that leg until the invite to SM is handled. figure out how SM should route that. If that's to a CM queue for example, then the invite to SM to CM should setup a call from the SBC that represents the AAEP/Carrier leg that's help up and when answered, the SBC bridges lets AAEP drop and bridges the carrier in to the call to CM you set up.