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

From: "James Ford" <[email-masked]>
Date: Thu, 06 Feb 2003 07:16:49 +0000

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 06 Feb 2003 11:08:22 -0600

James Ford wrote:
 > 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.

We have debated this internally and arrived at the same preliminary
conclusion to use the parameter extensions of the Via header.  In
this manner, no special header is needed.

It also struck me while thinking about this problem that Rohan Mahy
has an I-D on connection reuse in SIP (see:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-connect-reuse-reqs-00.txt)
While it does not explicitly talk about persistent connections and
peering relationships between proxies, it does discuss reusing an open
connection for requests in either direction.

 > 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 we first need to identify if persistent connections falls in the
category of problems solved by Rohan's I-D.  If so, we pursue it in
that I-D.  If not, we can start a new I-D.

 > I think many implementations will be interested in using a real
 > persistent connection especially when TLS will be more deployed.

I think the issue will be more about peering relationships between
trusted entities where the trusted entities open and leave open for
a long time the TLS socket.  I don't think Rohan's I-D talks about
those scenarios, but I have not read it in a long while and plan to
do so in the next couple of days...

Regards,

- 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