[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Impossible to use real persistent connection with sip
- To: "Vijay K. Gurbani" <vkg@lucent.com>, "Mark Watson" <mwatson@nortelnetworks.com>
- Subject: RE: [Sip] Impossible to use real persistent connection with sip
- From: "Cullen Jennings" <fluffy@cisco.com>
- Date: Wed, 12 Feb 2003 09:16:59 -0800
- Cc: "'Colasanto, Eric \(Eric\)'" <ecolasanto@lucent.com>, "'James Ford'" <james_s_ford@hotmail.com>, "'Jain, Rajnish \(Rajnish\)'" <rajnishjain@lucent.com>, <sip@ietf.org>, "'Sarit Galanos Mekler'" <Sarit@radvision.com>
- Importance: Normal
- In-reply-to: <3E4A5E26.40405@lucent.com>
- List-help: <mailto:sip-request@ietf.org?subject=help>
- List-id: Session Initiation Protocol <sip.ietf.org>
- List-post: <mailto:sip@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,<mailto:sip-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,<mailto:sip-request@ietf.org?subject=unsubscribe>
- Sender: sip-admin@ietf.org
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. 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.
Cullen
> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg@lucent.com]
> Sent: Wednesday, February 12, 2003 6:46 AM
> To: Mark Watson
> Cc: 'Cullen Jennings'; '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
>
>
> Mark Watson wrote:
> > I fail to see the problem.
> >
> > Servers can close the connection whenever they like. pc=1 tells the
> > server to keep the connection for longer. Longer than what ?
> Longer than
> > it would have done otherwise ??
> >
> > If the server closes the connection, it presumably had a good reason.
> > Asking it nicely to ignore its own good reasons does not seem very
> > useful to me.
> >
> > Perhaps we should recommend that servers do not close connections
> > without a good reason ? Should we recommend that they do not initiate
> > connections without a good reason ? or that they should not reject
> > connections without a good reason ? Why should we believe there are
> > servers which will arbitrarily close connections for no reason, servers
> > that are so stupid they need a new parameter to tell them not
> to do this ?
>
> Mark:
>
> I don't think anyone is suggesting that every connection a server
> opens actively to a downstream entity or accepts passively from an
> upstream client remain open forever.
>
> The essence of the problem simply is that two high-signaling traffic
> proxies (or a UAC and its default outbound proxy) would like to keep
> a TCP (or TLS) connection open for traffic between them. This
> alleviates negotiating TLS security keys or TCP 3-way handshake for
> each transaction going between them.
>
> Admittedly, this was not too much a problem when UDP was the preferred
> mode of transport for SIP signaling. However, for good reasons, TCP is
> becoming the preferred transport. So I don't see why we can't have some
> thought put into investigating this problem.
>
> Section 18 of rfc3261 correctly instructs implementors to close
> connections after a certain time (64*T1). It also recognizes that
> two proxies in a peering relationship will actually have two
> connections open towards each other (which can be avoided). And it
> also rightly defines "persistence" to mean a transaction duration.
> rfc3261 must ensure that the transactional integrity of SIP is
> preserved, and it does.
>
> All that is being done now is an attempt to investigate an extension
> that will enable "persistence" to mean some duration longer than
> a transaction's lifetime. Exactly how long, how to negotiate it (or
> not) is what comes next.
>
> 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