I’m trying to run the mobile server via a reverse proxy (in this case, IIS ARR/URL Rewrite), so we can share multiple services on port 443 on the same server.
I’ve successfully got the UI working as well as video streams via the proxy, the only thing I can’t get working is the audio stream. If I turn on audio, I get the pop up “Network Error. Try later.” If I connect directly to the mobile server via port 8081, it works fine.
Initially video streams would not work, I had to add a origin header on the proxy and override the value with the internal URL. Once I did this, video streams work fine.
Looking at wireshark, it looks like two different headers pass through for the audio websocket connection. They are Referer and Host, which I’ve also into the proxy for the audio endpoint. Checking wireshark, the HTTP websocket request now looks identical whether going through the proxy or direct, but via the proxy still doesn’t work.
Has anyone tried this and got it working?
Thanks.
Hi John,
I would suppose you are running Mobile Server 20.3.
Could you confirm that WebSockets on both ends of the RP are established ?
Are there any messages on them ?
This message is usually seen when socket is not opened correctly, forcibly closed or no data is transmitted on it within some time interval.
But in general sounds strange, as both video and audio is transmitted in similar manner. Except the address alias on which they are opened (XPMobile/Video vs XPMobile/Audio).
Btw, there is another way to fix the WebSockets issue for the video. Instead of rewriting the headers in the RP, you could make change of the MoS configuration. Fix is described here:
https://supportcommunity.milestonesys.com/s/article/Web-Client-does-not-stream-with-Mobile-Server-port-forwarding-troubleshooting?language=en_US
Hi Petar,
Thank you so much for the response!
Yes, running version 20.3, patched with the latest patches available.
I can see exactly the same behaviour with the audio stream whether connected directly or via proxy. I think the websockets open, but when going via the proxy, within 2-3 seconds the client seems to send a “CloseStream” and then the proxy server responds with a 502 error.
I’ve traced with wireshark, netmon and enabled IIS tracing. Nothing obvious coming out of the logs. The connection looks exactly the same going via proxy or going direct. The only difference is as above - after 2-3 seconds the proxy server returns a 502.
It is weird because as you say, both video and audio behaviour looks exactly the same from the outside. Open websocket, transmit data. But for some reason audio is refusing to work.
Thanks for that link! I did try setting the CORS header to a * initially, but that didn’t work. Just tested now following the article above (specifying internal address and external address) and sure enough the video works without rewriting headers now :-). But audio still has exactly the same symptoms.
I’ll try to repeat in order to be sure I’ve understood the issue correctly.
Audio is not working in all the cases - no matter if the Web Client is loaded trough the proxy or not (directly on the Mobile server in the same network).
If that is the case the problem is probably somewhere else. First things that came into my mind:
- User rights for the mic (both to see it and listen to its audio)
- Double check with the Smart Client and Mobile clients if the same Mic works there
- Check for something suspicious in the Mobile server log - like for example some exceptions
btw, I’m not completely sure this question is for this forum (dev one). Seem much more appropriate to the support one.
Sorry, maybe poor wording on my part on the last response.
The logs show the same information whether connection directly or going via proxy server (apart from the proxy server returning a 502).
However microphone works correctly connecting directly but does not work at all via the proxy (both on Android client and web browser). Microphone works correctly using the smart client as well.
The Mobile server logs also show the same - that the audio stream was connected to and passed. No errors (even though via the proxy it doesn’t work).
You’re right - this probably belongs in the support forum. Will post there! Thanks again for your assistance.