Hi Juha, It is true that you could send and "see what happens", without any knowledge and indication about what the receiver supports. You could also discard the SIP headers indicating which methods, message bodies etc are supported, and just send whatever and then see whether the receiver supports it... :) I think it is much nicer to have a mechanism to indicate support of, and usage, of the techniques to use - instead of simply trying and see what works. It also gives the possibility for the edge proxy to provide a keep-alive frequency value (and trigger whatever actions if keep-alives are not received), and the UA will know that it will receive "responses" (CRLF "pong" and/or STUN response) to the keep-alives (and trigger whatever actions if not received). Also, for registration cases, if the edge proxy has no knowledge about whether the UA supports any keep-alive techniques, it may cause "keep-alives" by returning a very short registration refresh timer in the registration response. That is not a very good and light solution, but commonly used. In another mail you said: "that does make sense, but then the ua needs to let the proxy know, exactly which keepalive method(s) it supports and the proxy should be able to respond, which one it wants to receive if there is more than one that the us is advertising." As Hadriel said, the "keep" parameter DOES indicate that the UA supports the keep-alive techniques defined in the Outbound spec. It does NOT indicate "I support some kind of keep-alive".
Last, you say that if the UA does not get keep=yes back the UA will not send CRLFs. Not receiving keep=yes simply indicates that the edge proxy does not support the Outbound keep-alive techniques. What the UA does in that case is a UA implementation issue. Regards, Christer ________________________________ Lähettäjä: [EMAIL PROTECTED] puolesta: Juha Heinanen Lähetetty: ke 7.5.2008 8:01 Vastaanottaja: [email protected] Aihe: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt Right, but the whole thing here is the UA doesn't know if the proxy supports STUN/CRLF, or is legacy. If the UA does draft-outbound and so does the proxy, it can find out; if it does draft-sip-keep, it can find out. If the UA finds out the proxy can't do it, then it will not do it. hadriel, that would break currently working nat traversal with proxies that do not support CRLF keepalive, i.e., that are not able to response to double-CRLF with a single one. a tcp connected sip UA is namely still able to keep its nat binding open by sending double CRLFs, because it does get back tcp level acknowledgements even when it does not get back SIP keepalive acknowledgement (single CRLF). if it uses the keep param and does not get back keep=yes, it would not send CRLFs and its nat binding would die away. this is not a good idea at all. - juha _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
