Hi Erkki, At IETF68 we agreed to add an indicator "timed-keepalive" that the *server* expects keepalives to happen according to the timers recommended in the draft. If the server asks for this, then the client needs to send pings (STUN over UDP or double CRLF over TCP or TLS). The *client* can tell if the server will send pongs (STUN binding responses over UDP, or single CRLF over TCP or TLS) if the server advertises "keep-stun" or "keep-crlf". This allows a battery operated client to use TCP keepalives or send pings less often if the server allows, and it allows the client in general to know if they should expect to receive pongs.
thanks, -rohan On 3/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi, >> Question 1: >> >> Is the single CRLF "pong" necessary or could the UA detect the >> flow failure just by receiving a socket or ICMP error when the >> connection is broken and not able to pass the double-CRLF "ping" >> to the proxy ? > >Sure, if you don't mind not getting calls for 10 minutes. And if some >moron hasn't blocked ICMP on your network (which unfortunately >corpsec guidelines frequently recommend). To overcome this problem, doesn't Outbound strongly promote the UA registering over multiple flows ? This requires the UA to detect when a flow fails. Since such detection takes time and leaves a window of opportunity for missed incoming requests, this mechanism allows the UA to use multiple flows to the proxy or registrar. Are you suggesting that this mechanism in the Outbound only has limited or even no value ? >It can take TCP a LONG time to know a flow has failed. This is a >large part of why I liked the STUN model. How does the addition of CRLF keepalive without CRLF "pong" make the situation worse compared using TCP keepalive, which has been considered acceptable for Outbound over several successive draft revisions and is still there without any "pong" other than TCP ACK ? And as you say, it can take TCP a LONG time to know a flow has failed, but not necessarily. The device which rebooted might indicate the broken connection by sending TCP RST, which immediately tells the sender about the flow failure. Even the STUN over TCP model will not guarantee an immediate detection of a failed flow as Outbound suggests that the time between successive keepalives over TCP should be between 95 and 120 seconds on top of which the STUN transaction adds 8 seconds to wait for the response. So even with STUN or CRLF "ping-pong" you could not getting calls for two minutes if the UA is relying on one single flow only or using two flows towards two different proxies over a single NAT which reboots. I am still questioning whether the requirement to add CRLF "pong" and 'keep-crlf' URI tags are really worth the extra complexity. Personally I am not at all convinced about it. Regards, Erkki _______________________________________________ Sip mailing list https://www1.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://www1.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
