Avaya Uniform Dialplan help needed with Cisco

[rfcomm2k]

Recently we deployed Cisco in a building on another site less than a mile away. We are connecting to Cisco using Q-Sig trunking.
Users in the Avaya PBX may transfer to the other site and are allowed to take their extension with. Users in the Avaya can then still 4 digit dial to their coworkers in the other building.

The problem I am having is that if a Cisco user is offline (many of them use Cisco Jabber on their laptops instead of a phone), instead of calls being routed to their vmail the calls are encountering a fast busy. I am told this is because the Cisco is expecting 10 digits instead of the 4 digits I am currently sending.

I have been told that the Cisco cannot easily be changed to accomodate these because the Cisco platform services several other sites, some in 3 different area codes and states.


My goal then is to see if there is a way I can use UDP to insert the digits automatically. There are three different exchanges on the Avaya due to the size of the site. So I expect to need to make these adaptations for each separate user that migrates, and that is not a problem. Any given week there could be one or two Avaya users that migrate to Cisco, but there still remains hundreds of other users that stay on Avaya.

Anyone know if this can be done, and if so how?

 

[rfcomm2k]

Here is an example of what I have in UDP:

Matching Pattern Len Del Insert Digits Net Conv Node Num

7009 4 0 335 aar Y


335 is an unknown entity to me. I thought it would be a route pattern but I did a list of route patterns and it did not exist there. However, I do know that the calls are sent over trunk group 30 which is a pair of ISDN trunks that connect to a voice gateway.

 

[kyle555]

how is it that you sending 4 digits when the jabber client is online works but sending the same 4 digits when its not is bad?

If you need to send 10 when its offline, can you not just send 10 all the time? UDP could do that...

Or, if the 10 digits are consistent with the 4 digits, you could just have choice 2 in the route pattern be exactly the same but insert NPA-NXX. Should try that 2nd if the 1st choice doesn't get a valid response to setup a call.

 

[rfcomm2k]

Kyle, I have no idea what was done to make the Jabber client work when it is online vs offline. I suppose it may have something to do with the redirect to the Unity vmail connection, since that is the point of failure.

I think I WANT to send 10 all the time. Can you tell me what I need to change to enable that?

 

[kyle555]

either in UDP - match on the 4 digits and insert NPANXX, or just do it in the route pattern.

depends how you're setup - if in 'disp dialplan parameters' you look at 'ext first', then once you move your users over, if you delete station 1234 for example, then when someone dials 1234 and it doesn't exist as 'ext-first', it'll look at UDP where you might just have a match on '1' min4/max4.

If you're UDP first, then presumably you add 1234 to UDP when the person moves, and it'd be tedious to have to insert the leading 6 digits NPANXX for 1234 and then 1236 when 1236 moves over, etc. If that's how you're doing it, then maybe having '1' min4/max4 in aar go to a particular route that inserts the leading 6 digits would be easiest - so long as you don't use that route to hit other things on Cisco you might not want to be inserting 6 digits to

 

[rfcomm2k]

Good info Kyle.

I assumed I would need to insert digits but was not sure where. So is it in a Route Pattern I insert digits, or is it in a trunk group that I insert the digits? Because that trunk group is exclusively used to connect to that CUCM.

 

[kyle555]

In the route towards the trunk

You could hypothetically call private to that CUCM over the QSIG PRI and call public over the same QSIG for the Cisco to bounce you out to the PSTN.

You'd have the trunk type as private, and AAR for 4 digit calls would use private numbering and in a particular route for that you'd insert the 6 digits. Then, ARS would use public numbering, and you could have another route to the same trunk for the PSTN calls that wouldn't get NPANXX inserted.