Problem with Assisted Transfer

[dacafaca]

I have a problem with the user which we installed Avaya IPO500 with VoiceMailpro.
VoiceMail Pro use for incoming calls and functionality that we are currently the most important is Asisted Transfer. (Transfer to an external numbers)

The problem is as follows:

Asisted Transfer: The Incoming call is transferred to an external number.
We set the option if no one answers, 10 sec. call returns to the new VoiceMail menu (module) or if busy call also returns to the new VoiceMail menu (module).
Avaya IPOffice 500 is connected via dual PRI TRUNK CARD (60 channels) to the Public Telekom operator for incoming and outgoing calls.

When we transfer a call to the Public Telecom Operator (T-Com,on whose network is connected IPO500), or to GSM Mobile Networks, everything works great, call is after NoAnswerTime or IfBussy back to the VoiceMail Pro and forwarded to another menu. That works fine!

The problem is that IPOffice does not recognize when no one answers, or when busy when the transfer is done by other Telecom operators who are not on the ISDN (but made the conversion from ISDN to IP).

Avaya says that the other Telecom operator is not providing "end to end ISDN connection" and therefore the whole thing does not work.

How to solve this problem?

 

[amriddle01]

Avaya are correct, as the other providor is not using ISDN it would appear that they are not passing the call progress indications through, this is how the IP Office knows if the call is ringing,answered or busy etc. It's not the IP Office at fault so it's not the IP Office that needs to be changed

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[dacafaca]

Consider that this is a national operator, exactly what they should change in the system?

Can we make IPOffice to ignore this message?

 

[amriddle01]

There is no message to ignore, that's the point, the IP Office cannot react to something it isn't receiving. They are not sending what is required for the things you want to happen, it is probably a limitation of the equipment being used, if you want to fix it get it presented on ISDN and you are done

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[intrigrant]

If the IPO is connecter to PRI and the call is presented by the provider to a analog line then the provider must send ISDN messages regarding call progress back to IP Office.
If you don not receive them then they have a poor infrastructure.

 

[CarGoSki]

Manager: Configuration Settings > Line Settings > T1 PRI Line

Add 'Not-end-to-end ISDN' Information Element: Default = Never*, Software level = 4.2+.
Sets whether the optional 'Not end-to-end ISDN' information element should be added to outgoing calls on the line. The options are Never, Always or POTS (only if the call was originated by an analog extension). *The default is Never except for the following locales; for Italy the default is POTS, for New Zealand the default is Always.

Are you in Italy or New Zealand and are you running 4.2+?

 

[dacafaca]

Ip Office is connected to PRI trunk,and Provider is sending Progress Message to IP Office.
I`m in Croatia and i`m running 4.2+.

I had an open case in Avaya, sent them all the trace`s , and eventually they wrote me this:
(for your information:T-Com operator is the main telekom operator in Croatia,and IPO is connected via PRI trunk to them. Optima is the second main operator in Croatia,and when we make calls to numbers that are in their network, Assisted Transfer is not working.)

AVAYA WROTE:

Hi Damir,
I have had feedback from the engineering team on why the assisted transfer call from vmpro is failing to be recalled on Optima lines.

In the Optima trace I have highlighted the messaging that causes the call from the ipo to be completed as a normal off switch transfer, and unfortunately it is down to the line provider and not the ip office that this is happening.

The T-com to T-com trace highlighted in blue shows the correct busy messaging for the vmpro to react to, and does not contain the same Progress messages.

Basically the Optima Telecom is not providing end to end ISDN connection, in response to the supervised transfer set up message, Optima responds first with a Call Proceeding message and secondly with a progress indicator. The progress indicator contains the following IE: 1e 02 8a 81.

This is decoded as follows:

1e - Progress indicator
02 - Length=2
8a - network beyond interworking point
81 - Call is not end to end ISDN: further progress information may be available in-band.

As the remaining leg of the call isn't ISDN the vmpro will never learn the state of the target device. As in-band information is present the VMpro has to complete the transfer to allow the caller to hear it.

Optima then sends a disconnect message with the following additional progress indication: 1e 02 82 88.

This decodes as "in-band information or appropriate pattern now available". The disconnect also contains display information ZAUZETO which translates as BUSY.

The VMpro supervised transfer action can't work correctly with an ISDN provider that sends progress information in-band.

In the traces you will see the T-com trace does not contain the same messaging and hence it works as desired.


(Traces are in ATT.)

 

[amriddle01]

dacafaca, I'm not sure how many different ways you need to be told it will not work but it won't. Even if you were able to get the IP Office to ignore that particular message (which you can't) it still wouldn't work as it would not be receiving the messages to say that the call is proceeding,connected, busy etc as they are being presented in-band. the very fact your other trunk works tells you it's this trunk at fault not the equipment. Avaya make this equipment and if they tell you it isn't going to work I very much doubt we would know any better. You need to get rid of this hybrid ISDN/IP connection and have it presented as a standard ISDN trunk or keep it and have this issue

ACS - IP Office Implement

"What the Crocodile Hat....was that?