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

From: "James Ford" <[email-masked]>
Date: Tue, 04 Feb 2003 07:45:07 +0000

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

---

From: "Jain, Rajnish (Rajnish)" <[email-masked]>
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,

What do you think?
James S Ford.

---

From: "Jain, Rajnish (Rajnish)" <[email-masked]>
Date: Wed, 12 Feb 2003 22:39:35 -0500

I agree w/ Sean that this problem needs to be addressed in the overall
scope of SIP transport layer connection management.  

It is well known that SIP is designed to be loosely coupled w/ transport 
layer. However, diverse forms of SIP entities (such as phones, proxy 
servers, B2BUAs, application servers) tend to be somewhat differently 
influenced w/ the systemic ripple created by connection-oriented 
transport layers. For instance, while it may be okay for a SIP phone to 
liberally request transport layer connections, it presents performance, 
scaling problems if two high traffic peer proxy servers keep churning 
through transport layer connections. These proxy servers would best 
serve the network if they communicate over persistent connections that 
are setup and torn down predictably. 

RFC 3261 suggests that a connection can be recycled, but for that to 
happen traffic arrival rate must be such that implementation defined 
idle timeouts don't occur. Any sporadic patches of idle time can render 
undesirable connection closure (as Vijay pointed out). Making just the
implementation defined timer very large makes the problem worst. That
way, the proxy server will tend to impose the large timer for all its 
connections even w/ SIP phones. Furthermore, since the timer is 
implementation defined, the two proxies may have vastly different
timer values (one very large and one very solve) which can really
imbalance overall interaction.

Rajnish Jain,
Lucent Technologies

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
Sent: Wednesday, February 12, 2003 8:50 PM
To: Vijay K. Gurbani; Christian Jansson; Cullen Jennings
Cc: Colasanto, Eric (Eric); James Ford; Jain, Rajnish (Rajnish);
[email-masked]; Sarit Galanos Mekler
Subject: Re: [Sip] Impossible to use real persistent connection with sip

I'm looking forward to reading the draft.
I think this is a common problem that deserves
greater scrutiny. I don't think there is any 
lack of potential solutions. I would like to see
some clean (informational) recommendations on
how this should be done. In addition to connection
persistence, I think connection re-use is an
interesting problem that could potentially be 
solved with a common design. This is similar
to recommendations on how best to use SCTP
in a SIP environment.

Regards,
Sean Olson
Microsoft

--- "Vijay K. Gurbani" <[email-masked]> wrote:
> Christian Jansson wrote:
> >>Section 18 of rfc3261 correctly instructs
> implementors to 
> >>close connections after a certain time (64*T1).  
> > 
> > No, it does not. Section 18 does not say when to
> close sockets, 
> 
> That's your interpretation.  When I read the
> following sentence from
> section 18:
> 
>     "It is RECOMMENDED that connections be kept open
> for some
>     implementation-defined duration..."
> 
> It implies to me that after the duration has passed,
> the entity is
> free to close the socket.
> 
> > but
> > rather that you should not close the socket to
> soon. So if you feel like
> > it, you could leave the connection open forever.
> 
> I am afraid I don't read it that way; i.e. leave the
> connection open
> forever.
> 
> > Not needed. Close the socket when you have to, and
> probably it will be
> > more effective to keep it open for a while in case
> you need it again (as
> > Cullen Jennings wrote).
> 
> Exactly how long is the question.  For some peering
> arrangements between
> service providers and for UACs always using a
> default outbound proxy,
> does it make sense to leave TCP/TLS sockets open for
> a longer time than
> a transaction.  That is the crux of the problem.
> 
> Cullen Jennings writes:
> > Hmm - I did not read 3261 quite that way.
> > 
> > I thought it was more along the lines of what you
> want to get too where 
> > it is up to the proxy and UA to make intelligent
> decision about when to 
> > close a connection. I think it would be good to
> provide some information 
> > level advice about schemes UA and Proxies might
> want to use to do a good 
> > job of this.
> 
> Right; or schemes between proxies.
> 
> > If this required more information to be passed
> between them to do a
> > good job of it that would be interesting but
> without seeing the 
> > scheme it is hard to see that they need any more
> information than 
> > they have today.
> 
> Fair enough.  Folks on the CC list (except
> [email-masked] :-)) are working
> on an I-D and it'll be available as soon as they are
> done.
> 
> Thanks,
> 
> - 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

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
_______________________________________________
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