Redirecting SIP call from external call control (SIP trunk)

[Sinisa Hreljac]

Hi to all,

we have external call center for some purposes so some calls are redirected to that call center call control system.

Situation is as follows:

PSTN <-> CUCM <-SIP trunk-> CUBE <-SIP trunk over MPLS-> external call controll system/PBX --> Agent

On external call controll PBX there are contact center agents and call queuing. If customer waits in queue (listens music on hold) for longer than some predefined time, call should be redirected back to CUCM and to some other DN.

Problem with this is, there will be two calls over MPLS; one originated call to external call center, and one call that is going back to CUCM, both calls over MPLS. We don't want that.

What we want: when customer wait for some time in external call center queue and no agent answers, call should be redirected to local DN on CUCM but without using MPLS link.

Current call to external contact center should be terminated but customer's call should not be dropped but redirected to CUCMs DN.  

Is there any solution for this?

Thanks.

[b.winter]

CUCM supports the feature path replacement. Check out the Cisco docs.

But as long as the other PBX doesn't release the call after the redirect, there is nothing you can do on the Cisco side.

Your problem is also not with the redirect of the call (as I have understood it, because the call is working), but more with the media path.

So something in the PBX says, that the media path needs to be ankered there.

[Sinisa Hreljac]

Actually, this setup is not yet implemented. We are in process in designing this scenario and we are concerned about MPLS usage as there will be a limited bandwidth for calls.

I've simplified question, but here are more details:

Customer calls our phone number on CUCM which is redirected to our IVR (UCCX). There is menu prompts to choose some options, and one of them is call to external Contact Center (CC). So that call is placed over CUBE and MPLS to external PBX and CC and it is initiated from UCCX script via CallRedirect.

Scenario #1:

There are already (let say 20) established calls to external CC over MPLS, and we have MPLS bandwidth just for that 20 calls. With remote PBX admins we'll agree that they will allow only 20 concurent calls to preserve MPLS bandwidth and call quality. They will refuse 21st call. So, if this is 21st call, that call will be refused as "Busy" and our UCCX script will detect that and that call will be redirected to some other number.

Scenario #2:

There are less than 20 established calls to external CC, so call will be answered by external CC. In that case, as redirection is made from UCCX script, call on UCCX will be released, but call flow will be as I mentioned before in first post. Now comes tricky part. If call is in queue on remote CC for longer than defined seconds/minutes, we want that call to came back to us on some number, but as you mentioned, remote PBX should release call, not only redirect, as this will be a new call so same call will go to remote PBX and back to our CUCM. Now, question is in what way remote PBX have to release/reject allready established call so on our side that call will not be terminated but redirected on some other number?

I've looked for feature that you mentioned, "path replacement" but I'm not sure how to use it. There is a CUBE between our CUCM and remote PBX so there is question if this should be implemented on CUCM or CUBE.

We are fine if such call goes to CUBE and than from CUBE came back to CUCM, as that solution is not using MPLS link.

[b.winter]

For scenario #1:

If the call goes through CUBE anyway, why don't you limit the call volume on the CUBE already? Or do it on CUCM with region/location settings?

Why sending the call via MPLS to the CC, if it gets blocked anyway?

For scenario #2:

You have to check:

Is it possible for PBX to release the call, and if yes, how it does it --> But you have to check this on the PBX side.

As already written, as long as the PBX doesn't release the call, you can't do anything on the CUCM / CUBE side.

For UCCX, for some scenarios, it won't release the call. Because it needs to stay in the loop.

For example, if the call was transferred to a DN, but this DN is not answering.

Then UCCX is able to retrieve this call and put it back into the queue e.g.

=> To do that, it needs to stay in the signalling/media flow.

Also as info:

Even if the PBX is able to release the call, the call will be hairpinned on the CUBE per default.

Path replacement is exactly the feature that you need.

It is used to tear down hairpinned calls.

Example:

Call comes in and goes directly to the PBX

PSTN <--> CUBE <--> CUCM <--> PBX

On PBX there is a forward or a transfer back to a CUCM number --> The call is now hairpinned on the PBX.

PSTN <--> CUBE <--> CUCM <--> PBX

                                     CUCM <--> PBX

With path replacement, CUCM recognizes this situation and resolves the loop by canceling the calls to the PBX and updating the call leg towards CUBE.

[Sinisa Hreljac]

For scenario #1: 

Yes you are right, that is one solution that we can implement on CUCM or CUBE. For this scenario we have various solution so that is not a problem.

For scenario #2:

CUCM <--> PBX - this is not acceptable configuration due security standards in our company. Every interconnection to other companies should go over CUBE. So situation is: CUCM <--> CUBE <--> PBX

As I understand, path replacement is not applicable here, or I'm wrong?