Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt

["Christer Holmberg" <christer.holmberg at ericsson.com>]

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ä: sip-bounces at ietf.org puolesta: Juha Heinanen
Lähetetty: ke 7.5.2008 8:01
Vastaanottaja: sip at ietf.org
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip