TCP Opened the Hotel Network—The Route Built for the Call Finished the Meeting

My client could hear every third word.

I was in a Toronto hotel room, eleven minutes into a pricing presentation that would decide whether our pilot project became a one-year contract. The slides were open. My camera was on. My VPN showed Connected over TCP.

The meeting itself was falling apart.

My voice arrived in pieces, screen sharing froze on an old slide, and the client’s questions reached me several seconds after their lips moved. I blamed the crowded hotel Wi-Fi, turned off my camera, and tried again. The audio improved for half a minute, then disappeared completely.

“Let’s take five minutes,” the client wrote in the chat.

I had spent the previous hour asking whether hotel Wi-Fi worked better with TCP or UDP.

The meeting was about to show me why that was the wrong decision to keep making.

UDP was faster until the hotel refused it

The hotel was full of business travelers and World Cup visitors. Corporate travel demand was strong in 2026, and the crowded lobby made that trend feel less like a statistic than a queue for every available chair.

At 7:10 that morning, the Wi-Fi had looked more than capable of handling the call.

A speed test showed 180 Mbps down and 64 Mbps up.

The hotel portal loaded normally.

Email, cloud documents, and streaming video all worked.

I opened my established VPN provider and left its protocol setting on automatic. It selected UDP, the usual performance-first choice.

The VPN connected.

The meeting link did not.

The browser displayed the company logo, waited for almost a minute, and returned Connection timed out.

I selected another nearby server.

The same thing happened.

A third server reached the sign-in page but failed after I entered my password.

That was when I searched the settings for TCP.

The basic trade-off is straightforward: UDP usually prioritizes speed, while TCP over a common web port can get through networks that reject the normal UDP route.

The hotel appeared to be demonstrating that difference perfectly.

Regular websites loaded without trouble. My UDP VPN showed a connection but could not carry the meeting.

I changed the provider to TCP 443.

The meeting opened immediately.

The login completed.

The waiting room appeared.

For a few minutes, TCP looked like the answer.

Then the call began.

TCP opened the meeting but could not keep it live

The first six slides went smoothly.

I greeted the client, shared the presentation, and began explaining the pricing model.

Then the hotel Wi-Fi slowed.

The meeting platform reduced my video quality. My screen-share controls stopped responding. The client’s voices began arriving late.

TCP had found a route through the hotel, but it was too heavy for a live conversation on a connection that kept hesitating. Every interruption created more waiting before the missing data was repaired and delivered.

The effect was easy to recognize.

The hotel Wi-Fi paused.

TCP tried to recover everything.

The conversation fell behind.

I stopped sharing my screen and sent the client a PDF instead.

The upload remained at 8 percent.

I turned off the camera.

The audio continued to break.

When I returned the VPN to UDP, the meeting disconnected completely.

Hotel guests have described keeping both UDP and TCP profiles available because some properties allow common web traffic while rejecting other VPN routes.

That matched the first half of my problem.

TCP could enter the network.

It did not make the meeting usable.

UDP was more responsive.

It could not reach the meeting at all.

Neither setting completed the job.

A stronger signal did not fix the protocol choice

During the five-minute pause, I carried the laptop into the corridor.

The Wi-Fi signal rose from three bars to four.

I rejoined over TCP.

The client’s voice sounded clearer, so I returned to the room and resumed the presentation.

The next slide contained an embedded dashboard.

It loaded halfway and froze.

My audio warning turned red.

Moving through the hotel had shifted the laptop between access points. The VPN still displayed Connected, but the meeting behaved as though I had briefly vanished.

I tried my phone hotspot next.

UDP connected immediately.

The meeting became responsive again.

Then the mobile signal dropped from 5G to LTE, and the dashboard took almost a minute to refresh.

The two available connections now offered opposite advantages.

Hotel Wi-Fi had enough bandwidth, but it pushed me toward TCP and its delays.

Mobile data allowed UDP, but the signal inside the room was too weak for the presentation.

I needed the hotel’s speed without forcing the entire call through a sluggish fallback.

The meeting pause had already lasted seven minutes.

Another round of manual protocol changes would only repeat what I had learned.

The smaller app started with the conversation

I closed the established provider and opened the smaller app I had installed as a travel backup.

It did not begin with a choice between TCP and UDP.

It asked what I was trying to do.

I selected the preset for a video meeting on restrictive hotel Wi-Fi.

The connection opened within a few seconds.

Then I tested it in the only place that mattered.

The waiting room appeared.

I joined.

The client’s voice arrived without a noticeable delay.

I turned the camera on.

The picture stayed clear.

Then I shared the presentation again and returned to the dashboard slide that had frozen before.

The chart loaded.

I changed the date range.

The figures updated while everyone watched.

“Much better,” the client said.

I continued.

The next ten minutes included live questions, a product demonstration, and a spreadsheet with several linked tabs. The hotel connection dipped twice, but the conversation remained usable. My video softened briefly and then recovered without removing me from the meeting.

The smaller app had chosen an obfuscated HTTP/3-based route. It passed through the hotel without forcing me to choose between a blocked UDP tunnel and an overloaded TCP fallback.

The result was clearer than the protocol explanation.

UDP through the first provider did not reach the call.

TCP reached it but could not carry the conversation cleanly.

The preset opened the meeting and kept it live.

That was the first time the VPN decision had served the presentation instead of interrupting it.

The hotel Wi-Fi disappeared during the final question

The client’s commercial director asked whether our pricing included the support team.

I opened the relevant spreadsheet tab.

At that moment, the hotel Wi-Fi vanished.

The laptop switched to my phone hotspot.

The meeting image stopped for two seconds.

Then the spreadsheet appeared.

I answered the question and continued speaking.

Nobody asked me to repeat myself.

The smaller connection recovered when the laptop moved from hotel Wi-Fi to mobile data, preserving the session instead of rebuilding the call from the beginning.

On screen, the transition was simple.

The Wi-Fi dropped.

The hotspot took over.

The meeting continued.

I could not observe the hotel’s internal filtering rules or every routing decision made inside either VPN app. I could see the result on the same laptop: the established provider’s UDP route could not reach the call, its TCP fallback introduced repeated stalls, and the smaller app carried the meeting across both hotel Wi-Fi and mobile data.

At the end of the presentation, the client asked me to send the final pricing workbook.

I uploaded it to the shared folder while we discussed the next steps.

The progress indicator moved steadily.

Thirty percent.

Sixty-four.

One hundred.

The file finished before the call ended.

At 8:24 a.m., the commercial director said:

“We’re comfortable moving forward. Send the final paperwork today.”

The meeting had reached the decision it was supposed to reach.

TCP or UDP no longer felt like the important question.

The follow-up did not require another account search

After the call, I needed to check a client message from my phone while packing for the airport.

The established provider had signed me out on that device after an update. Reconnecting it meant finding the password, opening my password manager, and approving another login.

The smaller app let me link the phone with a verification code displayed on the laptop.

There was no second email-and-password process.

I opened the client workspace, confirmed the workbook was present, and replied that the final paperwork would follow.

That phone connection had not saved the presentation. The meeting preset had already completed the urgent task.

The code removed the next small delay: continuing the client conversation on another device without beginning a new account recovery process.

I packed the laptop.

The phone remained connected.

The useful choice was not TCP or UDP

The smaller service has fewer server locations and a shorter public history than the established provider.

That can matter when someone needs a particular exit city.

It did not decide whether I could complete a live client meeting from that hotel.

UDP remained the sensible first choice for speed. TCP 443 remained a useful fallback when a hotel blocked the normal route. The mistake was treating either label as a complete solution.

The established provider made me choose between a responsive connection the hotel would not pass and a reachable connection that stalled under pressure.

The smaller app treated the hotel as a real working situation. It found a route the network accepted, kept the conversation responsive, and preserved the session when the Wi-Fi disappeared.

On that hotel connection, TCP answered how to open the meeting.

The better route answered how to finish it.