J1xx blind/unsupervised transfer issue (no audio both ways).

[qtelcom]

I have hosted systems with TelAgility (Power by Avaya) on SE 11.0GA and SE 11 SP1 using their SIP trunks. All J1xx phones have been setup as remote workers. In both cases, blind transfers to a J1xx phone results in no audio(both ways). It's repeatable every time. User receives external call, presses transfer, dials extn, and presses complete, the receiving extn picks up and hears no audio and the caller hears no audio, and if that extn presses hold and picks it back up, the audio is restored and both parties can talk. This happens on the TelAgility SE 11GA and 11SP, J169/179 phones with FW2.0, 3.0, 3.0.0.2. It's only when the J1xx is the target of the blind transfer. H.323/SIP/RAS ALGs/helpers are disabled on the customer routers.

-Transfer actions from VMpro to J1xx work fine.
-Supervised Transfers to J1xx work fine.
-9608 phones on these same systems -blind transfers work fine.


On prem IP5000v2's with J1xx phones -blind transfers work fine.

Any ideas or suggestions?

 

[TheSmash]

What are your settings for the below?

System > VOIP > Allow Direct Media Within NAT Location

Extension > Allow Direct Media Settings



ACSS (SME)

 

[qtelcom]

Yep, I also thought the same thing, so I've tried with all combinations. both checked, both unchecked, one checked and the other not checked and vice versa, all with the same no audio result. (Default settings were Direct media checked and the "Allow Direct Media Within NAT Location" unchecked) (All codecs match -SIP trunks and extns are Ulaw G.711)

After further testing, Looks like the commonality is when J169/179's are setup as remote workers.

We were able to reproduce this with our on prem Ip500v2 with a single J1xx setup outside the office setup as a remote worker. If the J1xx remote worker is the target of a blind transfer from another extn, we get no audio both ways. A simple press hold and pick it back up and the audio works.

So in my 3 separate IPO's on 3 separate networks I'm having this issue.
Two of which are completely different customers on a powered by Avaya SE11.0 and Se11SP1 with j1xx setup as remote workers.
One is our own IP500v2 with a J1xx remote worker

I have tried 11GA, 11SP1, the j1xx FW 2.0, 3.0 and the latest 3.0.0.2.1 for them

Does anyone else see this when J1xx are setup as remote workers? Blind transfer to it having no audio both ways, with the magical hold/unhold to restore audio?

 

[GeosmithUK]

Hi,

I have a lot of experience of this issue.

It feels the last two months of my life have been trying to prove to Avaya that this is a firmware bug.

I finally got a resolution from tier 4 support at Avaya.

The workaround at the moment is to turn on direct media path on all IP phones.

There is a fix coming next year in 11.0 SP3.



ACSS|AIPS|APSS

https://ipoffice.tools

 

[GeosmithUK]

I should add the fact that they are remote workers has nothing to do with it. It happens locally too.

ACSS|AIPS|APSS

https://ipoffice.tools

 

[qtelcom]

Appreciate the response; however,

I have direct media path on for all IP phones, and blind transfers to remote j169 = no audio, every-time. I can't reproduce it if the J169 is local (same subnet) to the IPO. Direct media path has no effect for me.

I have a working ticket with Avaya, yay!

 

[GeosmithUK]

Interesting. I still think it may well come down to the same firmware bug though.

I wish you luck in dealling with Avaya support. Please do report back with your findings. I would be good to compare notes!

ACSS|AIPS|APSS

https://ipoffice.tools

 

[qtelcom]

You're probably right, this is what I got back after submitting everything; I wonder if this is your JIRA.

Jira IPOFFICE-144883

R&D working on a solution
Fix scheduled in 11.0 SP3

 

[GeosmithUK]

Interesting. They didnt give me any Jira number.

I will ask when I am back in the office next week

ACSS|AIPS|APSS

https://ipoffice.tools