2

All Rendezvous Guests Disconnecting

We're had a persistent issue lately across multiple users, all running 13.1.2. Occasionally, all Rendezvous guests (usually 2) will just drop from a call. 

Any sense on why this happens? Wirecast remains operational, but the guests drop and appear as question marks. They also stay connected on their end, and when the session is restarted they appear back in Wirecast.

The disconnect has happened randomly, when cutting to a guest, when clicking on the Rendezvous window, etc.

51replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • I've had the same experience. I've gotten quick on the trigger with disconnect/reconnect session but obviously not ideal. 

    Like
  • Is with with 13.1.2 or .3?

    Like
  • Ermanno Bonifazi 13.1.2

    Like
  • Bryce Seifert That's very strange. 13.1.2 added a lot of improvement for RV. I'm using it with great success for at least +1 session with 3 or 4 guest. RV have space for improvement but I've not seen the issue you are mentioning. I'm using Mac.

    Like
  • Ermanno Bonifazi  I'm using 13.1.3 and having the very same issue!

    Like
  • Bruno Ienne I'm sorry this happen.  Not to me in 13.1.3 as well. Check bandwith of the guests since RV need a lot of bandwith.

    Like
  • Bandwidth is certainly a factor along with internet connection reliability. I do understand it's hard to know for each guest and how the demands increase for each guest as you add more total guests. 

    I do think with Wirecast 13.1.2, Rendezvous is generally much more reliable but we may need to investigate what variable issues guests might have (and likely be unaware of) that might impact their connection.

    Like
  • Whilst I appreciate your reply CraigS, I have to disagree. 

     

    I've tested using known, good, reliable devices and connection. And yet Wirecast Rendesvous continues to be wholly unreliable on 13.1. When I downgrade to 13.0.x then it works.

     

    Even if there are NO guests on the call, the session still crashes out.

    Like
  • Drew Perry What would be very useful, would be to control the resolution/bitrate either per guest or per session (like in vMix). Very often I don't need 720p calls when their pip is only 240 pixels tall.

    Like
  • I would have to disagree that this is a bandwidth issue. I had this issue with three different operators today, all in different locations. 2 of them happened as they cut from a live guest to a video file. The video played normally, but all the guests dropped as soon as they cut. This happened to two different operators doing the same action, and that seems way to coincidental to be bandwidth. Additionally, the video even went out to the streaming destination without a hiccup.

    I could see one guest dropping due to bandwidth, but I find it strange that all of them are dropping at the same time right as the operator is performing an action.

    Weirder still, as reported by the guests, they stay connected in their Rendezvous session, and to them it appears as if nothing has happened. They're still able to talk to each other clearly and the operator is able to rejoin the session almost instantly. 

    Like 1
  • Since some people experience this and others don't there has to be a correlate. If it were random it would be hard for anyone to be exempt from these issues over time.

     

    If it occurs in 13.1.3 (please only use the current version of Wirecast) please note if you see a "P" next to the guest or not (P means going through our TURN server), the browser and version of and OS the guest is on. If you can have the guest run a speed test please do so and also note packet loss where possible. Granted you won't be able to get this from all (and maybe not even most) guests when this occurs, it can help. Perhaps location of the guest (or host) may be a factor as well.

    Like
  • Drew Perry said:
    What would be very useful, would be to control the resolution/bitrate either per guest or per session (like in vMix).

     Both receiving and sending (controlled by host?). 
    How does one make the determination that bandwidth is the issue to begin with, as some postulate here, that's not the cause?

    Like
  • CraigS The ability to control resolution is not just limited to vMix, LiveToAir also allows the control room to specify the resolution in and out as well since there is a websocket connection that feeds JavaScript on the remote machine. The resolution is able to be updated and even the camera / mix options available are able to be updated remotely. Essentially, the available inputs are sent to the control room which then populates a list that can be updated remotely and the resolution can be updated to suit the requirements.

    Regarding the correlation and multitude of posts in the forum recently (for long standing reported bugs and feature requests) pertaining to Rendezvour, perhaps if Telestream had it's engineers or support actually use the product more (or at all), these would be able to be seen. You're all likely working remotely now, how better to test your own functions than to setup both internal and external tests with people? I don't know if you recall, but there was a regular meeting that some of us had with internal teams where we used Rendezvous for the conversations and it was clear that even with high bandwidth, it was clear there was an issue. Telestream has stated it's made improvements to the feature as a whole, perhaps you need to use it LIKE your customers rather than simply running minor test suites that don't push the system to how hard your customers are using it.

    Like 1
  • CraigS
    One thought I just had is terms of it affecting some but not others: firewalls. Is there a documented list of port ranges (tcp + udp) that Rendezvous uses for WebRTC?

    Like
  • CraigS said:
    How does one make the determination that bandwidth is the issue to begin with, as some postulate here, that's not the cause?

    Ultimately, Craig.... its all about resources. If we had unlimited network speed and compute power, the world would be a happy place. But that's not where we are. So lets look at this objectively.

    We know that 1 guest works, without significant issues if there is a solid network and a solid platform for broadcast. We know that as more guests are added, that performance degrades. We know that there are reports in some cases of high CPU with a large number of guests... and in other cases, even with no CPU issues, that there are still quality issues and/or dropouts.

    If it works with 1 person, but not with a larger number, we have to ask why. The only thing different is the number of guests. So. What does the number of guests do? Lets count the number of video (and audio) streams that will be active for each of the possible number of guests

    • 1 guest = 2 Producer Streams
    • 2 guests = 4 Producer Streams, 2 Peer to Peer Streams = 6 Total
    • 3 guests = 6 Producer Streams, 6 Peer to Peer Streams = 12 Total
    • 4 guests = 8 Producer Streams, 12 peer streams =20 Total
    • 5 guests = 10 Producer Streams, 20 peer streams = 30 Total
    • 6 guests = 12 Producer Streams, 30 peer streams = 42 Total
    • 7 guests = 14 Producer Streams, 42 Total streams = 56 Total

    Its exponential. And if multiple guests are sharing lets say the same internet feed, that can make things go VERY badly VERY quickly.

    I requested before an option to allow turning off the peer to peer video feed between guests. This will reduce some of the network and compute load. You could still potentially leave the audio peers up, to allow "snappy" interaction, but the video should be able to be turned off. Just my opinion.

    Greg Kuhnert

    Like 1
  • Sounds like people are talking about multiple different issues.

    Bryce Seifert said:
    firewalls.

     Rendezvous finds an open port and the fallback, when it can't do peer to peer is our TURN server. Try port 443 though.

    Bryce Seifert said:
    Weirder still, as reported by the guests, they stay connected in their Rendezvous session, and to them it appears as if nothing has happened

     Which would mean none of the guests have dropped out but something happened to impact the host. I've seen a few other reports like that where guests are all still communicating but the host drops out.

    Like
  • CraigS said:
    none of the guests have dropped out but something happened to impact the host.

    This makes me curious, since all the hosts experiencing this issue are using identical machines, and those machines have a port filter installed on them by our IT department. I wonder if something is happening during production causing the host to get caught in that filter, and then disconnect. I wonder if the ports in use change or vary once guests are connected?

    Like
  • Bryce Seifert Do check port 443. Perhaps there's another pattern to this.

    Like
  • CraigS This is our port filter that exists for that range

    pass in log proto tcp from any to any port 443:445 flags S/SA keep state
    Like
  • Bryce Seifert There are two possibilities as to the root cause of your problems:

    1. If all of your Rendezvous guests were connecting to Wirecast via TURN, it is possible that an outage in the turn server at Telestream could cause a dropout where their peer to peer traffic would continue, but your Wirecast connection would drop. In the current version of Wirecast, your guests would show a "P" in the rendezvous dashboard. Assuming you dont see a "P", we move onto option 2.
    2. The only other option is network/firewall related. Assuming this is the other possible cause, there is insufficient information to determine the specific root cause and/or how to fix it.

    My suggestion: Try again. Confirm if you have a P next to every guest. If the answer is NO, then you will need to talk to your networking / firewall people for further assistance.

    And on the topic of firewall connections. Let me briefly say that it SHOULD work with a well configured firewall, providing you allow direct outbound access without a proxy server. The firewall will automatically open any other required ports for video connections.

    Greg Kuhnert

    Like
  • Greg Kuhnert I can confirm that this is happening with with guests not using the TURN. I've only seen the P on two guests out of probably 30 people.
     

    Like
  • Bryce Seifert 

    Bryce Seifert said:
    I can confirm that this is happening with with guests not using the TURN. I've only seen the P on two guests out of probably 30 people.

    If thats the case, I can confirm its a network or firewall issue that impacted you on that occasion. If it happens repeatedly, you'll need to get the people that own that infrastructure to assist.... Not a wirecast issue.

    Greg Kuhnert

    Like
  • Greg Kuhnert Seems like a good hunch, but also seems to be a problem that's not isolated to my network.

    Joey Daoud  Bruno Ienne  Are you both also in firewall situations with your dropouts?

    Like
  • I've had Wirecast disconnect from the session every internet connection I've tried, including a 200meg sync direct fibre connection. So not firewall issue for me.

     

    It's *very* easy to replicate for me. Open Wirecast, start a new rendezvous session. Don't get any guests to join it. Wait 1 hour. Try and join the session. The guest's experience is like normal. However Wirecast has to disconnect and then re-connect to the previous session.

    you can also cause the symptom by starting a session, get any number of guests on the call and eventually, the 'host' will disconnect but the guests stay connected. 

    I have tested on Mac and Windows, on a mixture of hardware and internet connections, with a mixture of guests, also on known good connections.

     

    However, when I run 13.0.x it works perfectly fine. In 13.1.x it disconnects.

    In either case I find the system basically unusable. It requires so much CPU and internet bandwidth for each guest and I regularly would have all 7 if I could. So I'm back to using Zoom and screen capturing it into Wirecast. 

    Like
  • Now submitted this with Telestream Case #00746642

    Like
Like2 Follow
  • 2 Likes
  • 13 hrs agoLast active
  • 51Replies
  • 193Views
  • 8 Following