Francois Audet wrote: > Jiri, > > I think we are in 100% agreement then.
great. > > For UDP... I was certainly not a proponent of the STUN idea. > But after 6 months of arguing on the list and about 6000 postings, > the group decided to use STUN. > > I don't think we want to re-open that can of worms. :-) well perhaps having just a keep-alive app-indepednet document would be worth it, regardless what other combined work is going elsewhere :-) Anyhow, embedded STUN doesn't in fact appear so terrible to me. So after all, what do we want to do for keeping bindings alive? a) BCP b) ignore c) sip-keep. (sorted in my strongly descending order of preference). -jiri > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Jiri Kuthan >> Sent: Thursday, May 08, 2008 00:15 >> To: Audet, Francois (SC100:3055) >> Cc: [email protected]; Christer Holmberg >> Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt >> >> Francois Audet wrote: >>> >>>> Then we may very well consider making "respond to CRLF >> with CRLF" a >>>> proposed standardized way too. >>>> I mean it is simple and works. Which I prefer over negotiation >>>> protocols. >>> So, basically, you are proposing that for connection-oriented >>> transport, we use "respond to double-CRLF with single-CRLF" >> instead of Christer's draft. >>> I assume that would mean that for UDP transport, we'd still >> be using >>> Christer's draft. >>> >>> Is this your proposal? >> Hi Francois >> >> quite so, even I'm still a bit uncertain about what the least evil is >> :-) I think it is suboptimal to negotiate transport >> characterictics using application-specific protocol. CRLF^2 >> seems almost the right thing for TCP. TCP/keepalive seems >> even better to me -- I mean we can use it for every single >> app without reinventing the wheel. However I'm afraid that >> even if "cleaner", it would not work quite so well. >> >> The trouble with TCP/keepalive is twofold. One is, as Hadriel >> mentions, there are OSs that can't deal with it. The question >> is how serious shall be in protocol design about OSs whose >> TCP stack is not yet state-of-the-art. I'm inclined to be >> easy about it, this can be fixed. >> The other problem is very similar: there are NATs that ignore >> TCP keep-alives to extend bindings. The question is again how >> serious shall be in protocol design about software that could >> have been better. I'm actually worried more about the latter >> under the assumption that network is "imperfect" and >> end-devices better compensate for it. Thus I think >> CRLF^2 is the most preferable way for its robustness. >> >> Regarding UDP -- is there anything speaking against CRLF^2 >> too? I mean keeping things simple and non-special-cased is a >> good thing and I don't realized why this should not work. >> >> -jiri >> >> >> >> _______________________________________________ >> 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
