REFER to originating media gateway

[Dionysis]

Greetings, I have yet another out of the box solution I have to build.

The goal is to transfer a call out using a refer, however it must return via the same media gateway using that it came in on, using a REFER, so that no RTP remains after the call is transferred.  The solution is to avoid our equipment becoming in scope for PCI.

So here is the problem:
4 gateways across 2 sites, any agent on any site can accept a call from any gateway.
4 HA SIP Server pairs can accept calls from any of the 4 gateways.
The outbound call MUST leave via the same gateway.
Agents cannot single step transfer.

And here's the kicker, if the outbound transfer fails I need to handle that and retry twice, if it still fails I need to play a message.

Thus far I have built a routing strategy that handles the agents not being able to single step transfer, and managed to choose which gateway the calls is routed through.  However, I've done this using 4 dedicated trunk group DN's to transfer to, meaning the oosp-transfer-enabled option does nothing.

My calls are using an INVITE rather than REFER regardless of what options I set on the Trunk Group DN's.

Any ideas?

[Kubig]

Try to insert Transfer-type option with value oosp to the Extension data within strategy (ExtensionUpdate). I have did it through this and all works as expected

[Dionysis]

Thanks Kubig, I found that in the Routing reference guide this morning, it's working a treat! 

So in the spirit of sharing the knowledge, this is how I got the whole solution working:

At the beginning of the inbound call get the trunk using
ExtensionData['OtherTrunk']

The suspend for event function is then used to wait for "EventPartyChanged".

Then the frustrating part, both a RequestCompleteTransfer and RequestCompleteConference generate an EventPartyChanged, so to check if the agent has left the call I use GetRawAttribute[23], this returns the "OtherDNRole", which in the case of a transfer is 3.

Finally, using Kubig's "Transfer-Type" option above we transfer to a specific trunk group dn with the contact option matching the trunk found in the original attached data.

And there you go.  Simple really.

[Dionysis]

So now that the testers have had their way there's a problem.

If the agent attempts to conference I disconnect the call using a TRoute with Route Type Reject.  This disconnects the call and leaves the agent speaking with the customer again.  If the agent then attempts another transfer we see an error, "request already in progress".

Thoughts?

[Kubig]

Your steps are not correct - the request on create conference or another service is not answered/serverd properly and till the request is not correctly ended, it is not possible to "fire" another request for similiar function. Why did you do disconnect in these cases?

[Dionysis]

Are you aware of any way to disconnect the transfer in a different way Kubig?

[Dionysis]

Looks like we may have an answer.

The latest GA SIP Server has a fix for exactly this problem.

Now the difficult part, convince the customer to upgrade. 

[Kubig]

I am not against this way, but I was just wondered why you disconnect attempts/requests to the conference. Good new is that all will be resolved;-)

[Dionysis]

We need to disconnect the conference in order to keep the original agent, and infrastructure, out of scope for PCI compliance.  The theory being that if the agent were able to conference in this case the call could be recorded, and therefore bring the entire contact centre into scope, which in turn becomes incredibly difficult, and expensive, to manage.