Juha, Just to clarify.
Are you saying that OpenSer will respond to Double-CRLF with Single-CRLF over TCP? Regardless of keep or even outbound registration? I think that's what you are saying. I think that's actually very good. That's what I would like to see in general. And for the keep parameter. I agree with you. Keep parameter is just a mechanism to explictly declare that Keep-alive (Double-CRLF) is supported even if outbound registration is not used. But NOT including Keep does NOT mean that keep-alive is not going to be used, at least for CRLF. Sending unsolicited double CRLF is already allowed in RFC 3261. It's just that there is no garantee the server will respond with single CRLF. If it does, good. For STUN-over SIP, I'm not too sure how it should work. (I don't really care either to be honest). I think the point of the outbound draft was to say "don't send STUN over SIP unless you know your server supports it (through outbound registration, or explicit configuration, or keep parameter). > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Juha Heinanen > Sent: Wednesday, May 07, 2008 09:32 > To: Hadriel Kaplan > Cc: [email protected]; Christer Holmberg > Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt > > Hadriel Kaplan writes: > > > Openser will send back a CRLF when it gets a CRLF? > Interesting, but > it's proprietary. There is nothing in > SIP to say "send back a CRLF > when you get a CRLF". This > draft is proposing a standardized way to > do that, for both > transport types. > > openser will send back back single CRLF later this week, it > it receives double CRLF over tcp connection. i have not > claimed that this practise has been standardized somewhere. > the behavior is simply implemented, because several sip UAs, > for example, all nokia ones, do send double-CRLFs without any > negotiation if they are behind nats. as i have told, i don't > see any reason to negotiate this behavior at least when UA is > using tcp. > > > See my other email - it was what I meant - not getting the > keep=yes > means the other end doesn't support this draft. > > this is what you say now, not what you said yesterday. as i > said in my previous posts, what you say now is fine with me > as long as the draft clearly says that if UA does not get > back keep=yes, then this draft does not specify what the UA > should do. this allow current products keep on working > without this (at least in tcp case) useless negotiation stuff > that the draft is proposing. > > -- juha > _______________________________________________ > 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
