Hadriel Kaplan wrote:
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.
OK -- that is a good suggestion; quoting from my last response
to Dale:
OK; I think it may be good to separate the notion of persistent
connection (as suggested by Hadriel) and connection reuse. The
former is when a client uses the same connection to send multiple
requests in the downstream direction, and the latter is when the
downstream entity can use the same connection to send new requests
upstream. I will add this notion in the revision.
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.
The subtle difference here -- unlike in HTTP -- is that there
are requests coming towards the client from the server. In HTTP,
the communication is one-way: the browser opens a connection to
the server and sends requests over that connection and can treat
that as a persistent connection for subsequent requests. AFAIK,
in HTTP the server does not send a *request* towards the client
(the browser) over that same connection.
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.
Agreed.
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)
connect-reuse is arguing for this to be the default behavior in
SIP. Except of course, requests in the backwards direction should
not use a connection that has not been authenticated through TLS.
Some vendors restrict how many simultaneous connections they'll allow
from the same client, for security reasons, so are you thinking
along those lines?
Would that not in fact argue for persistent connections anyway?
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: [EMAIL PROTECTED],bell-labs.com,acm.org}
WWW: http://www.alcatel-lucent.com/bell-labs
_______________________________________________
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
