> -----Original Message----- > From: Juha Heinanen [mailto:[EMAIL PROTECTED] > > openser takes care of udp UAs behind NATs, so to openser UAs stun > provides no added value. it just complicates the UA implementation.
But there is a reason. As the proxy, you can't currently know whether a UA will send CRLF or not automatically. The proxy can send stuff down that TCP connection to try to keep it open from the outside, but that has failure issues, not the least of which is the UA is the only one that can re-open the TCP connection and so really the UA has to be smart enough to (1) detect the failure, and (2) trigger itself to re-open it if it failed. The most common way I know of to do that today is by making the UA send Registers frequently, because that accomplishes both (1) and (2), in all cases and on all transports. A double-CRLF or STUN is theoretically more efficient to process than a Register, so in theory it should scale better. So what the proxy needs is a way to know that the UA will do one of those keepalive methods, to do (1) and (2), and can avoid making the UA send Registers as frequently. Ergo, this keep param is good for a proxy. Obviously the proxy could instead guess, by seeing a CRLF from a UA and thus backing off the Register frequency, but that assumes the UA will send the CRLF even though it's doing frequent Registers (which not all do). So that's a chicken/egg problem we can avoid with this simple param. Then of course there's a proxy-proxy connection, which this draft will also enable keepalives for. -hadriel _______________________________________________ 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
