Subject: RE: [Sip] Impossible to use real persistent connection with sip

From: Sarit Galanos Mekler <[email-masked]>
Date: Mon, 10 Feb 2003 11:31:17 +0200

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.
Servers that don't understand pc or don't want to keep the connection open 
are more then welcome to close it.
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.

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.

Regards,
Sarit Galanos.

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]]
Sent: Monday, February 10, 2003 9:28 AM
To: Colasanto, Eric (Eric); 'James Ford'; Jain, Rajnish (Rajnish);
[email-masked]
Cc: Gurbani, Vijay K (Vijay)
Subject: RE: [Sip] Impossible to use real persistent connection with sip

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.

I think this persistent connection question is intertwined with the ideas of
how SIP will do reliability. It's all fine and dandy to add a parameter
allows box A to tell box B that it is not allowed to crash but it is a
little harder for B to make sure it correctly implements this. Even if B is
capable of this sort of HA, it might want to close the connection for
administrative reasons such as getting new keying material on a TLS
connection.

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.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Colasanto, Eric (Eric)
> Sent: Thursday, February 06, 2003 5:51 AM
> To: 'James Ford'; Jain, Rajnish (Rajnish); [email-masked]
> Cc: Colasanto, Eric (Eric); Gurbani, Vijay K (Vijay)
> Subject: RE: [Sip] Impossible to use real persistent connection with sip
>
>
> I think a new parameter will work well to specify the creation of
> a persistent socket.
> ;pc=0 when the socket is NOT persistent, or don't include this parameter.
> ;pc=1 when the socket is persistent.
>
> After setting up this socket will all subsequent SIP messages be
> required to have the pc=1
> to utilize the persistent socket. Or will any SIP message
> destined for an endpoint supported by a
> persistent socket utilize the socket, reguardless of the presence
> of the pc parameter?
>
> Then there is the issue of when/how does one destroy the
> persistent connection(s).
> Should this be left to the application/user which is controlling
> the generation/consumption of
> the SIP messages?
>
>
> Eric J. Colasanto
> (508) 862-3386
>
>
>
> -----Original Message-----
> From: James Ford [mailto:[email-masked]]
> Sent: Thursday, February 06, 2003 2:17 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sip] Impossible to use real persistent connection with sip
>
>
> An even simpler solution will be to add a parameter to the Via
> header such
> as
> pc; (or pc=1 so that we will not have troubles with Microsoft). Pc stands
> for persistent connection.
>
> Guys, what do I need to do to move on this thing so that we will
> have a new
> draft to solve the problem?
> I think many implementations will be interested in using a real
> persistent
> connection especially when TLS will be more deployed.
>
> Thanks,
> James S. Ford
>
>
> >From: "Jain, Rajnish (Rajnish)" <[email-masked]>
> >To: "'James Ford'" <[email-masked]>, [email-masked]
> >CC: "Colasanto, Eric (Eric)" <[email-masked]>,
> "Gurbani, Vijay K
> >(Vijay)" <[email-masked]>
> >Subject: RE: [Sip] Impossible to use real persistent connection with sip
> >Date: Tue, 4 Feb 2003 07:20:22 -0500
> >
> >James,
> >
> >The option of adding a SIP header field seems to be more flexible. That
> >way,
> >when that header field is not present, the persistent connection
> is jointly
> >owned by both UAs. And at their discretion they can close it.
> This allows
> >us
> >to be backward compatible while enabling a new capability.
> >
> >Thanks,
> >Rajnish
> >
> >-----Original Message-----
> >From: James Ford [mailto:[email-masked]]
> >Sent: Tuesday, February 04, 2003 2:45 AM
> >To: [email-masked]
> >Subject: [Sip] Impossible to use real persistent connection with sip
> >
> >
> >Hi,
> >The SIP standard does not specify who is responsible for closing TCP
> >connections. This means that both client and server transaction can close
> >the connection. A reasonable implementation for a transaction will be to
> >close any open connection (incoming or outgoing) before termination in
> >order
> >to free unused resources.
> >This behavior actually makes it impossible to count on a persistent
> >connection.
> >For example, A UA that is always talking to the same destination
> using TLS
> >will want to use one connection per day. This is impossible since the
> >server
> >might close the connection as soon as the first transaction terminates.
> >
> >I can see several ways to solve this problem:
> >1.	Specify that the UA that opened the connection will be
> responsible for
> >closing it.
> >2.	Add a header to sip requests that asks the server not to close the
> >connection by itself.
> >
> >What do you think?
> >James S Ford.
> >
> >
> >
> >
> >
> >
> >_________________________________________________________________
> >Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> >http://join.msn.com/?page=features/featuredemail
> >
> >_______________________________________________
> >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >This list is for NEW development of the core SIP Protocol
> >Use [email-masked] for questions on current sip
> >Use [email-masked] for new developments on the application of sip
>
>
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Cullen Jennings" <[email-masked]>
Date: Mon, 10 Feb 2003 09:06:01 -0800

I just assumed that all reasonable proxies treated the TCP close as a
classic garbage collection problem. So they would leave it open until
they were low on resources then run some sort of least used or least
recently used algorithm to select the connections to close. Why would
any proxy default to close the connection after every transaction? 

I don't see why the hint is needed.

Cullen

> From: Sarit Galanos Mekler [mailto:[email-masked]] 
> Sent: Monday, February 10, 2003 1:31 AM
> To: 'Cullen Jennings'; Colasanto, Eric (Eric); 'James Ford'; 
> Jain, Rajnish (Rajnish); [email-masked]
> 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. Servers that don't understand pc or don't want to keep 
> the connection open 
> 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.
> 
> 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.
> 
> Regards,
> Sarit Galanos.
> 
> To: Colasanto, Eric (Eric); 'James Ford'; Jain, Rajnish 
> (Rajnish); [email-masked]
> 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.
> 
> I think this persistent connection question is intertwined 
> with the ideas of how SIP will do reliability. It's all fine 
> and dandy to add a parameter allows box A to tell box B that 
> it is not allowed to crash but it is a little harder for B to 
> make sure it correctly implements this. Even if B is capable 
> of this sort of HA, it might want to close the connection for 
> administrative reasons such as getting new keying material on 
> a TLS connection.
> 
> 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.
> 
> Cullen
> 
> 
> > Subject: RE: [Sip] Impossible to use real persistent 
> connection with 
> > sip
> >
> >
> > I think a new parameter will work well to specify the creation of a 
> > persistent socket. ;pc=0 when the socket is NOT persistent, 
> or don't 
> > include this parameter. ;pc=1 when the socket is persistent.
> >
> > required to have the pc=1 to utilize the persistent socket. Or will 
> > any SIP message destined for an endpoint supported by a
> > Then there is the issue of when/how does one destroy the persistent 
> > connection(s). Should this be left to the application/user which is 
> > controlling the generation/consumption of
> > the SIP messages?
> >
> >
> > Eric J. Colasanto
> > (508) 862-3386
> >
> >
> >
> > Subject: RE: [Sip] Impossible to use real persistent 
> connection with 
> > sip
> >
> >
> > An even simpler solution will be to add a parameter to the 
> Via header 
> > such as
> > Guys, what do I need to do to move on this thing so that we 
> will have 
> > a new draft to solve the problem?
> > >Subject: RE: [Sip] Impossible to use real persistent 
> connection with 
> > >sip
> > >The option of adding a SIP header field seems to be more flexible. 
> > >That way, when that header field is not present, the persistent 
> > >connection
> > is jointly
> > >connections. This means that both client and server 
> transaction can 
> > >close the connection. A reasonable implementation for a 
> transaction 
> > >will be to close any open connection (incoming or outgoing) before 
> > >termination in order to free unused resources.
> > >server might close the connection as soon as the first transaction 
> > >terminates.
> > >
> > >This list is for NEW development of the core SIP Protocol Use 
> > >[email-masked] for questions on current sip Use 
> > >[email-masked] for new developments on the application of sip
> >
> >
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip
> >
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>