I’m seem to be able to repeat an issue that we somehow did not catch before. Incoming calls take about 7 seconds or so before audio can be heard. Sometimes the audio never comes. Some times one way audio happens on outgoing, but not as often.
Any idea what this could be?
Hey are you using HDX ?
Skype virtualization pack with VMware Horizon View
Can you disable USB Redirection and retry?
@member we don’t have USB redirection enabled
Is the Skype client showing that it is optimized?
Yes it is. I’m seeing the device name and headset symbol as well in the lower left side of the skype client
Network already checked? Usually it‘s pretty straight forward.. Is it happening on every Audio output device? HDMI/DP also?
it is usually the outside caller can’t hear my voice until after 7 seconds or so. So something with the transmission of the microphone audio
Network has been checked
It doesn’t happen to Windows Thin Clients we still have
Did you had a look on that article? docs.vmware.com/en/VMware-Horizon-7/7.5/horizon-remote-desktop-features/GUID-E00B7DC3-CAC6-421F-A9A7-FF0925888D9D.html
Who would I provide the logs to?
Can you read something in them? I don‘t believe that Igel can provide help on that but you could open a ticket at our support.
Ok thanks. I do have a ticket open from your support team to hopefully help from that side too. Hasn’t been much help yet
How about logs from the IGEL itself?
not on my lab atm. I would check: /var/log and /tmp/
If I enabled Debug TCPDump Logging. Any specific place that would be? @member
nvm, think i found it. ls /debuglog
This log file may help. I’ve pushed this to IGEL Support & VMware support. This is the log I’m hoping that should find out whats going on since it has all the call information and network logs.
I’m almost 99% positive this issue has been narrowed down to the VMware horizon client above 4.9 causing it. I can repeat and resolve the issue on a windows PC by installing different versions of the horizon client. I’l lbe asking igel to hopefully supply a private build so i can verify
Hey @member, I saw you called. Are you asking for a firmware with an older version of the Horizon client installed? I believe IGEL is on 5.0, if not 5.1 at this point.
Yes sir. I hope thats not too much to ask
I can repeate the issue on vmware versions above 4.9
We can try older firmware, we probably won’t be able to provide a custom release with an older version of the Horizon client.
I’ve already tried all of the older version of firmware
4.10 is the lowest IGEL 11 goes to
Do you have any 10.x firmware devices out there?
10.05.100 uses Horizon 4.8.0
No I do not
So, on Windows we see the same thing on the 5.x client. Have you tried the latest 5.2 client. Just want to be sure, as I have a better chance at getting that in a private or future build
Yes, thats what my tests were ran on the Ubuntu machine yesterday. With version 5.2 of the horizon client
OK, let me talk to management, and see what they think. I’ll put notes in the case and then see what I can do. Wrapping up a meeting right now, but I should have the case notes updated in an hour or so.
So I may have something to try
The issue is similar enough
HKLMSOFTWAREVMware, Inc.VMware BlastConfig
NetworkContinuityEnabled with value as 0
UdpEnabled with value as 1
Looks like I need to change this, I’ll make this change and see what happens
Good find! Let me know how it goes. I will still add the notes to the case in case I need to persue the older Horizon cleitn option
Ok thank you!
Looks like that fix didn’t work for us. I’ve reached out to vmware and updated them but thats all I got at the moment
OK, I’ll run this buy management here, but I may not hear anything back until tomorrow
@member is it still true that works fine on an external network, but not when using a device on your internal network?>
Yes only on versions 4.10 and greater
4.9 works internally and externally
I think I may get pushback because of that, since it appears to be a limitation of Network routing/security
That sucks then
I’m going down the VMware Agent route and am finding the issue goes away with Agent 7.4. I’m going to keep going up to find out which one breaks it. So the good news is this leaves me a solution while VMware finds the issue.
That’s interesting, what version were you running in production? I thought you said you were on 7.10?
Yep. We are on VMware View 7.10, with the 7.10 Agents. However they are backwards compatible so decided to try older agents
Ah, you downgraded to 7.4 then. That makes more sense
I am wondering if you will lose some functionality, or a bit of optimization going back to those versions. There must be a reason they require communication to the external IP addresses. I know Skype changed it’s model at some point from distributed to communication routed. It may be a change to accommodate that architecture change.
Yep! The Environment is still 7.10 but not the agent for the machine i’m testing
Yea, VMware is still struggling to get back to me. They forwarded it off to the engineering team so hopefully they can shed some light
I wonder if it is trying to connect to your PBX and failing?
I’d be really curious to know if VMWare or MS figure out what is going on, and what the fix is.
Also, FYI, VMWare dropped the private beta for MS Teams optimization yesterday, so that should be here soon(ish).
well another interesting find. 7.4 worked, i realized because the Skype Plugin doesn’t seem to work on that version. So I Installed the 7.10 Agent and didn’t install the Skype Plugin. So with the Real Time Audio / Video the issue goes away. So root cause looks to do something with the Skype Plugin is communicating
Continue reading and comment on the thread ‘Skype virtualization pack with VMware Horizon View calls take about 7 seconds or so before audio can be heard’. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.
Submit a question, or Join Today!