>>I agree with Hadriel. It is very difficult to, in a spec, say what an > entity not supporting the spec should do - because implementors may > not even have read the spec. > >i don't remember i have proposed saying something about an entity (UA) not supporting the spec. what i have proposed is that an UA supporting the keep spec should still send CRLFs even it does >not get back keep=yes. > >>But, again, we can choose to not explicitly forbid sending CRLF, which means that people not > supporting "keep" can continue sending CRLF without anyone being able >>to tell them that what they are doing goes against some spec etc. > >i still don't understand why we need an addition to sip protocol for CRLFs keepalives. > >why can't you instead say in your draft that before sending a register or any other sip request, UA sends double-CRLF to find out if ob proxy supports CRLF keepalives. it does, if UA gets back >a single-CRLF and otherwise not. > >in my opinion, it would be much simpler than inventing yet another addition to sip protocol on top to the countless additions there already exists and that no-one has implemented.
That still doesn't indicate to the edge proxy that the UA supports the keep-alives. I don't think we can expect the edge proxy to remember every IP address/port from where it has received a double-CRLF, before it has received a SIP request from that same IP address/port. 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
