Transfer caller to external number 7

[daleblizz]

Hello again.

Avaya Office IP Release 4.2

Workers at one of our Office IP swtiches are trying to transfer incoming calls to external numbers. They press transfer, enter 9, then the area code and it's blocked -- the phone displays "Incompatible".

I've dug around in the manuals and everything looks like it should be set to allow external transfers, but obviously I'm misssing something.

Any help on where to look would be appreciated.

Thanks,
Dale

 

[amriddle01]

I have just looked at the config he emailed me, not put it into a system, he only has the 9N (which it could ever match) going to his ARS which is setup to send it out correctly.

ACS - IP Office Implement

"I'm just off to Hartlepool to buy some exploding trousers

 

[IPOfficeIreland]

I think a trace is really needed here. If it works sometimes and not others you really don't know if it is the customer or system at fault.

What phones are they amriddle? Could it be the 16series with the bug of missing the 2nd digit dialled number?

Does the person who is transferring have long fingernails?

 

[amriddle01]

5410's 20's etc no 1600 series or IP. you could well be right with the fingernails, I couldn't see that from the config , does the line prefix come into effect going out on T1's?

ACS - IP Office Implement

"I'm just off to Hartlepool to buy some exploding trousers

 

[cmnstr]

@amriddle01, now that you mentioned the line prefix I was reminded of a situation with a system I worked on recently. Customer had 2 PRI and outbound calls were failing 50% of the time. One PRI had a line prefix of 9 in the settings and the other did not. Calls using the one with the line prefix could not dial out until the prefix was removed and the system was rebooted. Line prefix is only supposed to have an effect on the way inbound calls are displayed and no effect on outbound calls, but this is apparently not the case with some carriers.

 

[daleblizz]

Thanks cmstr and amriddle01:

The line prefix has "91" in it. All (but one) of our other switches are blank. And the one that isn't blank has a "9".

I'm not quite sure why they'd want to add 91 (I guess that would assume that every return call would be long distance). I'll blank it out and reboot tonight and see if that clears the problem.

Thanks again.

 

[daleblizz]

I Removed 91 from the line index. That didn't correct the problem.

They can call numbers in the 704 area code, but they can't transfer to them.

Looks like it might be a job for Avaya.

 

[amriddle01]

Did you try removing the XXXXXXXXN shortcode from the ARS, worth a shot even though it should not have matched it.

ACS - IP Office Implement

"I'm just off to Hartlepool to buy some exploding trousers

 

[daleblizz]

amriddle01:
"Did you try removing the XXXXXXXXN shortcode from the ARS, worth a shot even though it should not have matched it."

Yes I did -- that didn't make a difference.

Avaya went in through my computer and did a trace. I got bad information from the user -- all the digits were going through (not just 9704) -- it was reaching the CO and... just sitting there. A ticket is open with the CO side now.

Thanks for all the help. It guess it was another case of garbage in -- garbage out.

 

[daleblizz]

It's been a long hard path on this one.

The problem may be back to the Avaya. The CO switch won't transfer calls because the Avaya isn't sending the caller ID of the transferring phone. (It's for security reasons.) The CO sees the number it want's to transfer to, been won't connect the call without caller ID.

However the same phone DOES send caller ID on normal calls to the 704 and 813 area codes.

Is there anything in the Avaya that could programmed to not send caller ID on transfers? Or is this just how the Avaya works?

Thanks for any suggestions.

Dale

 

[Bas1234]

In the ARS at telephone number put in NW

___________________________________________
It works! Now if only I could remember what I did...
___________________________________________

 

[amriddle01]

I think he's asking how to stop it withholding, is that right? What do they want exactly as calls originating from the system normally display the main bearer number, is that not good enough?

ACS - IP Office Implement

"I'm just off to Hartlepool to buy some exploding trousers

 

[daleblizz]

The main number for the location is probably what they what the location wants to show.

As far as the CO guys are concerned, it can be any number -- it just needs to show a number to let the transfer go through.

 

[daleblizz]

amriddle01:
"...What do they want exactly as calls originating from the system normally display the main bearer number, is that not good enough?"

I just talked to the manager. What they would prefer is that it showed their individual DIDs on transfers, just like it does on their normal outbound calls.

If that's not possible and they only get one number, they'd like it to be: 704-333-3209

 

[cmnstr]

We have worked with Avaya Tier 3 for several weeks on a similar issue. A call comes into the auto attendant and the caller presses option 1 to transfer. This transfer option sends the call to an external number. Much of this is dealing with SCN calls but the results we are experiencing are the same as what you describe. Here is something to try:
Create an extension on your switch and set it to unconditionally forward to the external number. Next, try to transfer the call to that extension, which should, in turn, send the call to the external number. This works on my switch. What we do not yet know is why this works but a regular transfer does not. We have worked on this almost daily for 3 or 4 weeks so I will post an update as we find out more. Hope this helps you.

 

[amriddle01]

Sounds like some of the service providors in the US are Mickey Mouse outfits, don't they have a standardised method of connection and call handling? Or does each one make up it's own rule etc?

ACS - IP Office Implement

"I'm just off to Hartlepool to buy some exploding trousers

 

[daleblizz]

Problem Solved. Thanks for all your help.

An Avaya support tech told me to try...

Short Code: [9]N
Telephone #: 9Nsi7043333209
Feature: Dial
Line Group: 0

... and that since our IP Office is "4.0 or above" it needed to go into ARS and not in the main Short Code list.

He also suggested trying 9Ns7043333209, if the above example didn't work.

It worked with 9Ns and not with 9Nsi. I guess it just keeps the CO switch happy, because the direct calls and transfers still show the individual callers DID number, which is what they wanted.

Thanks again.

 

[tlpeter]

If the tech told you to use [9] then i would have start laughing and and hang up the phone


ACA - Implement IP Office
ACS - Implement IP Office
ACA - Implement IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[fshaw]

I just solved a similar problem on an older 403. The calls could not be transferred to external numbers since swapping PRI providers. They display their direct numbers on outbound Caller ID rather than the main telephone number.

I created a separate ARS table using [8] and set each dial command with Nsi123456789. Now they hit transfer, 8, the number, and transfer again.