Subject: [Sipping] draft-mahy-sipping-connect-reuse-reqs-00

From: "Sean Olson" <[email-masked]>
Date: Tue, 2 Jul 2002 10:54:59 -0700

This is a very interesting problem. Should the requirements
include the ability to deal with intermediaries such as
NAT/firewalls that may not strictly be SIP entities? Also, I 
wonder if the proxy-proxy connection problem is as critical
as the UAC-proxy connection reuse problem. Might SCTP be a
better solution for proxy-proxy connection management?

Thanks,

Sean Olson
Microsoft
http://www.microsoft.com/rtc

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Jul 2002 02:59:09 -0400

trimming to sipping...

Sean Olson wrote:
> NAT/firewalls that may not strictly be SIP entities? 

I'm not sure its a requirement so much as a conseque of the concept. In 
a prior mail on the sip list, I had indicated that I wanted to remove 
the Translate header from the sip-nat draft, in favor of a more general 
connection-reuse mechanism, which would have a side-effect of providing 
the Translate header functionality.

I wouldn't object to including a requirement that says that the 
mechanism should work when there is a NAT between the client and server.

> Also, I 
> as the UAC-proxy connection reuse problem. 

Not as critical, but definitely important. For many proxy-proxy cases, 
there is a long-lived persistent relationship, typically when those 
proxies are in the same domain. You'd really like that to be matched by 
a persistent connection.

> Might SCTP be a

I had been a long time skeptic of SCTP for SIP, but am now convinced 
that it is ultimately better than TCP for SIP, if for no other reason 
than it provides message level transport, instead of byte oriented 
transport. This eliminates the need to do the complicated Content-Length 
based message framing over a TCP connection.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 09 Jul 2002 11:04:57 +0300

Sean,

> better solution for proxy-proxy connection management?

Both SCTP and TCP have the problem described in this draft, IMO.

However, this problem would be solvable providing the proper port number
in the Record-Route entry. Assuming that SIP implementations check if
they have an existing connection with a transport address (destination
IP address and port number) before opening another one, everything would
work fine.

I see that the mechanism described in the draft has the advantage of
keeping the sender from worring about which ephemeral port is used to
send the request. Is there any other advantage if compared with
Record-Route entries with port numbers? If so, it should be discussed in
the draft.

In addition, I would add to the section about the problem statement that
if two SIP entities establish two TCP/SCTP connections rather than one,
the congestion avoidance data is not shared by the connections. This may
trigger a too aggressive behavior or a too conservative behavior ehrn
compared to the one achieved by using only one connection.

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 09 Jul 2002 11:30:22 +0300

Before I had missed that this draft is supposed to fill the role of the
old Translate header in the old sip-nat draft. I believe that this
should be mentioned, since it is an important advantage over the
Record-Route mechanism.

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 09 Jul 2002 16:29:57 +0300

Hi,

RFC3261/bis-9 mainly talks about using a single connection (or, one in each
direction) for a single transaction, and the connect-reuse draft talks about
being able to use a single connection for messages in both direction, for a
single session. Sometimes, however, when we talk about "reuse of connection"
we mean when a single connection (or, one in each direction) is used for
multiple sessions. I think it would be a good idea to mention that that kind
of "reuse" is out of the scope of the draft. Otherwise the draft subject
should more clear indicate what kind of reuse it refers to...

Of course, once a single connection is established, according to the
connect-reuse draft, it MAY be used for multiple sessions, but that's not the
scope of the draft, so...

Regards,

Christer Holmberg
Ericsson Finland