> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > There is an overall conflating of two concepts as "connection reuse". > > One is using one connection to send more than one request from one > > sender to one recipient. The second is using one connection to send > > requests in both directions. The first concept is already supported > > by RFC 3261; the second is what is being enabled by this I-D. But > > the I-D implements both actions using one alias table, obfuscating > > the distinction and so obfuscating the changes that the I-D is > > introducing. > > So this is an interesting and very relevant comment. You are > absolutely right that there are indeed two concepts of connection > reuse. However, I do not believe that the draft conflates them. > > It's using the same word for both, which requires very close reading > to figure out which concept is being talked about at which time. (I'm > not claiming that *you* don't keep the two ideas straight, but I'm > worried about the next 200 readers.)
Indeed, I had the exact same confusion and I'm worried about the next 199 too. :) I would call it "persistent connection", a la HTTP. With regards to TCP "persistent connection", where you mean the client can reuse the same TCP connection for requests going to the same server, is that really necessary to put in a standard? I mean it was always allowed, no? I guess it's good to make it explicit, but I'm not sure how one knows when it's the right thing to do or not. I agree there are clients creating new TCP connections per SIP session, and tearing down old ones, and that's very bad in some situations, but it's essentially a local policy decision. A client is free to open and close TCP connections at will. You can't make it keep one open forever. And there is nothing that the signaling is doing about it to help in this draft. Like for example if the server side stuck something in the response to indicate "you may keep this connection open and send any future requests to me over it if you can". (i.e., the Connection/Keep-Alive header model as in HTTP) Some vendors restrict how many simultaneous connections they'll allow from the same client, for security reasons, so are you thinking along those lines? -hadriel _______________________________________________ Sip mailing list https://www1.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
