2 stage dialing

[Eugene Meyer]

Hi all.

I'm trying to configure 2 stage dialing but without data connectivity (IP connectivity), between Avaya, and Cisco. Here is the scenario:

We have an Avaya Call centre in country A, who needs to make calls to clients in country B, however there is only Cisco infrastructure in country B. What Im trying to configure is for the Call Centre agents to dial the Cisco gateway in Country B (via an access code or something like that), the gateway will then provide a dial tone to the agent who can then dial a client in country B from the gateway, and have a called number CLI of an extension residing on the Call Manager in country B.

Its worth mentioning that there is no IP connectivity between the two systems, so the call legs will all be established over the PSTN.

A diagram of the call flow will look like this.

Avaya agent --> GW --> PRI --> Country A SP --> Country B SP --> PRI --> Cisco GW (provides dial tone to agent, and makes call to client) --> Client in country B.

I had a look at the below Cisco document on how to configure two stage dialing with dial-peers, but see that the gateways still require data connectivity. So my question is, will this be possible with the set up Im facing, and if so, how do I configure this? I am also aware that this opens the network up for Toll Fraud, but this will be a short/dirty work around until we can get SIP trunks between the Cisco GW and SP.

http://www.cisco.com/c/en/us/support/docs/voice/voice-quality/22373-1stage2stage.html

This section in specific.

When the user picks up Phone 1, the dial tone is heard from the PBX. The user enters the digits and then hears another dial tone from the PBX/CO connected to Router B. There are two ways to achieve this:

1. Use direct-inward-dial on Router A.

   With direct-inward-dial configured, when the PBX/CO seizes the port on the router and sends a setup message that contains the DNIS digits. The router uses those digits to match an outbound VoIP dial-peer and sends the call to the remote router. Router B then seizes the line to its PBX/CO and does not forward it any digits. The remote PBX/CO then provides a dial tone to the user on Phone 1. It then appears as if the user is connected to that PBX/CO.

   This is the configuration for Router A:

   dial-peer voice 99 pots
   destination-pattern 1234
   direct-inward-dial 
   
   !--- This command is needed so that the router !--- routes the call based on the dialed digits.
   
   port 1/0:0
   prefix 1234
   !
   dial-peer voice 100 voip
   destination-pattern 5678
   session target ipv4:192.168.1.2

   This is the configuration for Router B:

   
   !--- This dial-peer matches the entire destination pattern, !--- strips it all off, and does not send any digits to the PBX/CO.
   
   dial-peer voice 201 pots
   destination-pattern 5678
   port 1/0:0
   

[Vivek Batra · Accepted solution]

1. When call hits the Cisco gateway in country B, inbound dial-peer should be configured with 'no direct-inward-dial', this will ensure that caller gets secondary dial tone.

2. Now caller will enter the DTMF and will match the appropriate outbound dial-peer to route the call again to PSTN.

3. So for Cisco gateway, it's PSTN to PSTN call.

Do you see any challenges here?

- Vivek

[Eugene Meyer]

Hi Vivek.

First of all, thanks for the suggestion on how to get this 2 stage dialing done.

I don't foresee any challenges with this but I have another question here. Is there a way to create a white list using a E164 number instead of an IP address, or any other way to make this more secure? As I mentioned we don't have IP connectivity between the two offices, and I don't want to run the risk of a massive phone bill.

[Vivek Batra]

Hi,

I don't think you can control/restrict calling on POTS dial peer in anyway the way it can work for VoIP call (ip trust authenticate). You've some choice to identify the caller and match the respective inbound dial-peer with the help of 'answer-address' command but again later on, default dial-peer 0 will be selected for unknown callers and here is a risk.

Ayodeji (+5) has already mentioned that there is a serious risk in the scenario which you want to achieve. Myself has many clients who have been victim of such fraud and lost thousand of dollars.

One thing which I've not asked you before. Do you have CUCM in country B manging gateway calls? If yes, we can think of some solution so that only intended callers can be given desired services. If no, you will end up with huge chances of toll fraud with standalone gateway.

In either case, you don't need to have IP connectivity between two countries.

- Vivek

[Eugene Meyer]

Hi.

Yes there is a CUCM 8.6.2 server in country B that manages the MGCP gateways.

I also have a CUC 8.6 server in country B and trying to see if there is a way that I can utilize this server with an IVR option that will ask for a PIN. Once the correct PIN has been received the CUC server will provide dial tone and a call can be initiated from the CUC server...not sure if this is possible, but looking into this. I remember was a way toll fraud could be commited for Untiy, and Im trying to see how it was done and whether there is a way to make it more secure and use it as a solution here.

Perhaps you know if this is possible or not?

[Vivek Batra]

Hi,

What you are referring as white list for POTS is not available in Cisco. It's with many legacy TDM switches vendors like Avaya, Siemens etc. 

With CUCM 9+, we have some enhancements where call can be restricted/allowed on the basis of CLI, but not available in CUCM 8.6.

Did you check Mobile Voice Access (MVA)? It's sort of DISA and help mobile workers to use office trunks to make outgoing calls and with PIN authentication too. I think that can serve your purpose. Please let me know if you need some more info about MVA.

- Vivek

[Carlo Poggiarelli]

Great tip Vivek +5!

With that feature, each user in Country A can have his own extension in Country B and 

and  could be called back with a Country B DDI by customers in the same country.

Cheers

Carlo

[Ayodeji Okanlawon]

But how will this work when the customer is country A wants to dial a client in country B. He makes a call over the PSTN to country A and wants to dial a PSTN number in country. Unless you have to manually do a CFA on each DN to a certain number in which case you don't need MVA. MVA assumes that a user is tied to a number and when calls originate from that mobile, the DN is displayed as the CLI..

"Mobile Connect allows users to manage business calls using a single phone number and pick up in-progress calls on the desktop phone and cellular phone. Mobile Voice Access is the associated integrated voice response (IVR) system, which allows users to turn Mobile Connect on or off and to initiate calls from a cellular phone or other remote phone as if the call were initiated from the desktop phone. "

May be I am missing something... :)

[Vivek Batra]

MVA assumes that a user is tied to a number and when calls originate from that mobile, the DN is displayed as the CLI..

Perfect... caller has to tied up with specific DN but when call comes to MVA, caller has a choice whether to make call to internal DN or make external call.

If dials internal DN, called phone will see internal DN as CLI instead of actual CLI.

If dial external number, respective remote destination CSS will take care to allow external PSTN calls.

Cisco has used some mix terms here which is confusing.

1. Mobile Voice Access: Allow mobile workers to use office trunks and make outgoing calls so that called party will see office CLI.

2. SNR/Mobile Connect: When DN is being called, both DN and respective remote destination will ring.

3. Mobility: When having active call on IP phone, call can be transferred to remote destination number using single key (mobility key).

- Vivek

[Carlo Poggiarelli]

I guess that

 with a remote destination profile  associated to each agent on site A , it could be as every agent in Site A has an extension on site B CUCM.

I assume that actually agents configured on Avaya system have their own DDI reachable from PSTN.

Please correct me if I'm wrong :)

Cheers

Carlo

[Eugene Meyer]

Im not familiar with MVA, so please send some information if you dont mind.

However on that note, the call agents in country A is on an Avaya system. We do have Cisco in country B, but the call center does not operate from there anymore. From your suggestion (and I migh be wrong) it seems like the call agenst in country A should be on Cisco if MVA is an option...or do I have it wrong here?

[Vivek Batra]

They don't be on Cisco. Some of their information needs to be configured in CUCM (country B).

Before suggesting you further on MVA, would like to ask you some questions;

1. Is it OK if all Avaya callers share same PIN or you would want different PIN for each caller?

2. Is it OK if all Avaya callers when make calls to country B, called party sees the same CLI or different for each caller?

- Vivek

[Eugene Meyer]

1. All users on Avaya can be on the same PIN if thats easier

2. The called party needs to see a CLI that is on the CallManager in country B. Reason for this is, if the called party tries to call the number that showed in the CLI, then I want to be able to manipulate the routing of it back to country A where a call agent can pick up the call, but the clients is still charged at a local rate for the call.

[Vivek Batra · Accepted solution]

Ok...

One thing I forgot to mention and just noticed which you won't like that MVA is not supported with MGCP. However we still can achieve this with some workaround. Following are the major building blocks;

1. Since you're using MGCP, inbound call will straight away goes to CUCM.

2. Create Route Pattern with MVA access code in CUCM.

3. Create SIP trunk in CUCM pointed to gateway.

4. Create inbound dial-peer in gateway for calls from CUCM having 'service mva' enabled.

5. Route MVA route pattern to SIP trunk pointed to gateway.

6. Create remote destination profile and remote destination number. Enter any Avaya PSTN number here as remote destination number. Associate remote destination with one of the internal DN.

7. Create one end user with Mobile Voice Access enabled and assign this user to remote destination profile.

8. Enable MVA in service parameters and configure MVA access code.

Please note that here, caller will not only have to enter PIN, s/he will have to enter remote destination number too to get access and make calls.

These are some major steps to be taken care during configuration however if you're new to MVA, we may face some challenges at the time of implementation. 

- Vivek

[Eugene Meyer]

This looks exactly like what I need for this client.

Im new to MVA, but I'll do some reading up on this, and paly around a bit. If I run into any issues with the implimentation I'll message you, if you dont mind Vivek.

Thanks a million for this Vivek :)