Hi Juha, >>I think we can add some words about the case if keep=yes is not >>returned. But, if we for example talk about the UA still sending STUN >>requests I also think we need to say something about the potential >>issues also. > >not just "some words", but a clear recommendation (at least for the CRLF >case). Yes. >i don't know what the issues with stun might be (possible proxy crash or >blacklisting do not qualify).
I agree that proxy crash doesn't qualify (as you said earlier, such proxies should not be deployed in the first place), but I DO think the blacklisting is a valid real-life issue. There is also another thing: I guess one reason the edge proxy doesn't return keep=yes could be because it detects (using whatever mechanism) that the UA is NOT behind a NAT. In that case the UA may end up sending unecessary keep-alives, in case the UA itself doesn't know whether it's behind a NAT or not. >>Also, if the UA for example receives a very short registration >>refresh timer (since the edge proxy did note support "keep"), there >>probably is no reason to send keep-alives in addition to the >>registration refreshes. > >you can write that if registration interval would be as short as >default keepalive interval then it is not recommended to send >keepalives. Yes. Regards, Christer _______________________________________________ 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
