UDP vs TCP 9

[dsm600rr]

Hello all,

After learning some more on networking and protocols, curious why anyone would use TCP vs UDP in a live stream environment.

I know TCP is more reliable, as it waits for a reply from the client to confirm it received the sent packet, however this offers no benefit to a live stream.

With my ASBCE, my SIP Provider only supports UDP, so that is the protocol used.

However, on the link between my IPO and ASBCE is TCP, wondering if I should update that to the faster UDP Protocol?

Waiting on responses before I do so.

ACSS

 

[Westi]

TCP is more reliable to deliver packages but in voice it doesn't matter as much.
If there are voice packages missing the system will maybe ask for them but if they are delayed it will discard then anyways. The same if they come out of sequence.

UDP is fast and should the connection be flaky then the result is pretty much the same with either protocol.

Joe
FHandw, ACSS, ACIS

"Dew knot truss yore Spell Cheque

 

[derfloh]

Be aware that signaling can be UDP or TCP but media is always UDP.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[dsm600rr]

derfloh: Thank you. Did not know that. However, do you see any reason to use TCP in the IPO Environment in regards to SIP Trunking and Remote Workers? Wondering if I should keep the SBC > IPO Link TCP or change to UDP.

ACSS

 

[derfloh]

I’ve read somewhere that IX Workplace only connected through TLS or TCP.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[kyle555]

Workplace only works with TCP.

TCP has 2 benefits over UDP.

First is acknowledgements.

Secondly, and more importantly, is managing fragmentation. Your devices/routers have a max number of bytes per packet - MTU - usually 1500. SIP can have messages larger than 1500 bytes. They cannot be delivered by UDP.

In Aura enterprise stuff it's easy to have SIP messages >1500 bytes.

Regardless, SIP is a layer 7 protocl that relies on TCP to manage the message payload. What I mean by that is you can't have a UDP SIP message that says "BTW, there's 2500 bytes - you'll get the first 1500 in this UDP packet and expect the last 1000 bytes in the next UDP packet. TCP can do that.

The other thing is that the TCP ACK can let the SIP stack of the client/server know if the other end is there at all. SIP has its own timeouts, but imagine your phone can register to 2 servers.
If your phone is going to try 3 times before failing over, then that means either sending 3 UDP SIP messages and waiting for the timeout for each - which is several seconds - or sending 3 TCP SYNs. A TCP SYN can timeout a lot faster than a UDP SIP message so you can failover faster.

 

[kyle555]

Oh, also relative to your original comment about "live stream", SIP is just the signaling. The media is RTP and is always UDP.

It makes sense for the control messages to be acknowledged, but the actual live stream is always UDP. Same as in H323.

 

[ipohead]

I could tell you a UDP joke but you might not get it

 

[derfloh]

Since Covid I switched from TCP to UDP to avoid handshakes.

Sorry... Pretty off topic

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[dsm600rr]

derfloh:


kyle555: Appreciate the detailed response. Always learning. I currently have a lab Cisco ASA In front of me

ACSS