There’s just one instance of KeepAliveManager which is used in case of NAT. So the stack can “only” support keep-alive associated with registration (RFC6223 section 4.2.2) as otherwise the client would need a separate instance for dialogs.
The keep parameter should only be sent in REGISTER requests and not in INVITE requests; same would apply to limit the analyze of the keep in VIA of REGISTER responses and not to those received in INVITE responses (which to me would be keep-alive associated with dialog; RFC6223/4.2.3).
Furthermore, the client should not reset the keep-alive frequency to its default value if it does receive anything but an explicit keep value zero (especially it should not reset the value if there’s no keep header at all).
There’s just one instance of KeepAliveManager which is used in case of NAT. So the stack can “only” support keep-alive associated with registration (RFC6223 section 4.2.2) as otherwise the client would need a separate instance for dialogs.
The keep parameter should only be sent in REGISTER requests and not in INVITE requests; same would apply to limit the analyze of the keep in VIA of REGISTER responses and not to those received in INVITE responses (which to me would be keep-alive associated with dialog; RFC6223/4.2.3).
Furthermore, the client should not reset the keep-alive frequency to its default value if it does receive anything but an explicit keep value zero (especially it should not reset the value if there’s no keep header at all).