Juha Heinanen <[email protected]> writes: > Greg Troxel writes: > >> Plus, if an INVITE is sent once over TCP, then I'd expect that is one >> TCP segment in one IP packet, and it's queued, and when the phone wakes >> up from the FCM notification it will receive it. > > How does the SIP Proxy know where (IP address/port/transport) to send > the INVITE? Or does it include the INVITE in the payload of the push > notification? If not, it needs to wait for the phone to register > itself.
Sorry, this got a bit jumbled. I see three cases of handling sending INVITE, and I was trying to talk about the first one here. User has registered and stays registered. Phone is working (meaning that when a packet arrives it will get it within a second or so, and timers for reregistration are firing adequately timely). server sends INVITE, and it arrives and works. This is what you are doing and favor (me too). User has registered and stays registered. Phone is doing extreme power saving and is not really working. Somehow, it is able to reregister often enough. Packets that arrive for the phone are either queued indefinitely or dropped or both. A call arrives at the server. The phone has somehow told the server a push service token, and the server sends a wakeup, and then sends INVITE. There is some messy resolution, maybe timely, maybe not, to retransmit lost packets and get back to a working state. This is what Brian is describing, I think. User has registered. User obtains a push service token, and sends that to the server with a "I am going to stay logically registered, but close the TCP connection." Then, when a call comes in, the server does a push service wakeup. Phone opens a TCP connection and does a resume, much like "tmux attach" on a new ssh connection to get back to your shell. Then server sends INVITE over that. This is the IETF approach. Yes, it's more complicated, and has more delay, and exposes a wakeup to the push service, but it isn't unsound. The i-d says that there are not yet implementations. The second case is probably workable if the server is aware that this is happening and declines to send anything over the connection unless it has sent a wakeup very recently and at least a few seconds ago. And if it has no OS-level TCP keepalives. This precludes sending presence updates without a push wakeup. Can anybody describe what linphone is doing, precisely, with push services? This is a question about the f-droid build as well, because that isn't linked against google play services. _______________________________________________ Linphone-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/linphone-users
