I have seen much of the FUD around here about not using UDP for SIP because "it's unreliable".
Yes, UDP is not guaranteed delivery like TCP, but that doesn't necessarily mean that a protocol running on it is unreliable. Protocols running on UDP, like SIP just need to understand that UDP datagram delivery is lossy and they need to add their own reliability to it. And they do. In reality, I don't believe, even on the Internet that UDP is as anywhere even remotely close to as unreliable as it seems to get made out to be in and around the linphone community (I frequently see problem reports being answered with "use TCP"). If UDP were as unreliable as it's made out to be around here, then protocols like QUIC would be a miserable failure. And they are not. In contrast, I find SIP call delivery (INVITE) over TCP with Android (Oreo at least) phones to be far more unreliable than UDP, exactly because TCP is a guaranteed delivery protocol. What I am seeing is that the phone uses TCP to REGISTER to the PBX successfully. If a call is made to the phone before the phone has a chance to go into sleep mode (i.e. right after the phone REGISTERs but the screen isn't turned off) everything works great. However, once the phone does go to sleep after the screen goes off, it also stops responding to network packets (except seemingly Firebase Cloud Messaging packets on port 5228 -- which wake the phone up, including networking). That means that if the PBX sends any more data to the phone over TCP while it is sleeping, it will go unACKed and be put into the TCP retry queue in the PBX's TCP stack for resend. The PBX continues to retry sending the TCP packet as it is supposed to per the TCP protocol spec, and I believe, backing off the timeout each time it goes unACKed. What this means however is that when the PBX wants to send an INVITE to the sleeping phone, that INVITE gets stuck behind (remember, part of the reliability guarantee of TCP is also guaranteed ordering) the packet that is in the TCP retry queue and won't make it to the phone until the current retry-wait timeout expires and the packet ahead of it is re-sent and ACKed. This could be quite a long time if it's been sitting in the queue for a long time having it's timeout backed off each time it is re-sent and unACKed. Push doesn't even help this situation, because even though a push will wake the phone up before the PBX sends the INVITE, the TCP backlog (for the phone) on the PBX has to be flushed before the INVITE will make it to the phone. The amount of time between the phone waking up from the push and the TCP backlog getting flushed could be relatively long and in fact what tends to happen is that the caller (to the PBX) has gotten tired of waiting or has been sent to voicemail before this TCP queue is flushed and the caller has hung up before the INVITE even makes it to the phone. Then a few (or more) seconds pass with the phone still awake from the push, the retry timer on the TCP backlog expires and the queue is flushed successfully to the phone including the INVITE, which the phone finally receives and rings in response to. The user answers, but by that time the call on the PBX has terminated and the user has answered a call that no longer exists. Thoughts or comments? Cheers, b.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linphone-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/linphone-users
