[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Impossible to use real persistent connection with sip
I look forward to reading the draft. I have been hoping someone would
write some advice to implementers on when to close connection.
I initially did not understand that pc was meant to be a hint - I'm way
more comfortable with a hint than with anything that assumes a
reliability model beyond what SIP already has specified.
Cullen
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On
> Behalf Of Vijay K. Gurbani
> Sent: Monday, February 10, 2003 8:21 AM
> To: Cullen Jennings
> Cc: Colasanto, Eric (Eric); 'James Ford'; Jain, Rajnish
> (Rajnish); sip@ietf.org; Sarit Galanos Mekler
> Subject: Re: [Sip] Impossible to use real persistent
> connection with sip
>
>
> Cullen Jennings wrote:
> > Just to get a little more precise about this ... what does
> persistence
> > mean? For the length of the transaction? For the dialog? As long as
> > the registration is valid? Until some box crashes? Until
> the world moves
> > to IPv6.
>
> Hi Cullen:
>
> Yes, we've grappled with that as well. Clearly, to get most
> bang for the buck, the persistent connection lives beyond the
> dialog that established it; i.e. it spans transactions. One
> place where such persistent connections may be used is
> between a UAC and its default outbound proxy, or between two
> proxies that may have a trusted peering relationship between
> them for traffic between their domains.
>
> Exactly how to quantify this length of time is tricky. As
> you point out, sometime a peer may go down for administrative
> reasons, other times it may simply crash. Depending on how
> we specify and implement it, there may be an expiry time for
> this connection -- I don't know what the correct answer is right now.
>
> > I would be very happy to see some good thought on when
> devices should
> > close a TCP socket - I think that figuring out a good algorithm and
> > understanding the large scale consequences is going to be
> surprisingly
> > complicated.
>
> We're working on an I-D that extends the connect-reuse ID to
> outline some of these issues. I will post it to the list as
> soon as I can. It contains a lot of what Sarit also outlines below:
>
> Sarit Galanos Mekler (Sarit@radvision.com) writes:
> > First I would like to say that I think that the pc=1 is a
> good choice.
> > To my opinion adding the pc=1 to the via header is only a
> > recommendation to the server to keep the connection open.
>
> Unfortunately, this is just a hint to the server, and as you point out
> below:
>
> > Servers that don't understand pc or don't want to keep the
> connection
> > open are more then welcome to close it.
>
> But that may be all we need to do. I don't yet know if it is
> worthwhile to go through some negotiation mechanism (i.e.
> register Require and Proxy-Require tokens with IANA). Even
> it we do go the "pc=1" parameter route, we should register
> the "pc" token with IANA.
>
> > A server can also decide that it wishes to keep the connection open
> > only
> > if it is actually being used. An implementation can for
> example, set a
> > timer on server connections. When ever a message is
> received/sent on
> > the connection the timer is reset. when the timer expires
> the server
> > closes the connection.
>
> All this presumes that clients and servers are well-behaved.
> In the extreme case, I think that we may rely on I/O failing
> on a now unconnected socket because one of the peers crashed
> or got brought down for adminstrative reasons. That is, we
> proscribe behavior for well- behaved peers, taking in account
> extreme cases where one of them suddenly disappears.
>
> > The persistency level (dialog / transaction) if for the specific
> > application to decide. For dialog persistency the
> application will have
> > to keep the connection open for the duration of the call.
> Using the
> > pc=1 parameter will give a good chance for using
> connections for more
> > then one transaction. An option that today (almost) does not exist.
>
> Right.
>
> Cheers,
>
> - vijay
> --
> Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
> Wireless Networks Group/Internet Software and Services
> Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
> Naperville, Illinois 60566 Voice: +1 630 224 0216
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current
> sip Use sipping@ietf.org for new developments on the
> application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip