Subject: Re: [Sipping] Questions on connect-reuse

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 04 Apr 2003 13:31:53 +0300

Christer,

> Q1.
> 
> Why is the reason the "alias" parameter is put in the Via header? Isn't
> the Via used for response routing only? Wouldn't it fit better as a
> header (or URI) parameter used in the Contact- and Record-Route headers
> instead?

The alias parameter is meaningful between a SIP entity and its next hop 
(hop-by-hop) when they have a connection. You cannot tell a server two 
hops away to reuse the existing connection you have with it, because you 
do not have any existing connection.

The top-most Via is always from the previous hop. This is not true for 
Contact or Record-Route entries.

> Q2:
> 
> Assume I make a SRV lookup, and I get a list with different server
> addresses.
> 
> Now, for one of the returned addresses I have an existing TCP connection
> which I could use. But, I also receive another address, which has higher
> priority. So, which has higher priority: an existing connection, or the
> priority identifier in the SRV response? One may argue this is an
> implementation/local policy/whatever issue, but I think it would be a
> good idea to mention it in the textt.

If alias is used properly, I would assume that the client would place a 
host name in the Via entry with the alias parameter. This way, the other 
SIP entity will not even perform the DNS lookup. It will have the 
exisintg TCP connection indexed using the host name.

> Q3:
> 
> Assume I send an INVITE to an emphemeral port (the TCP connection was
> established by the remote party), and I receive one or more provisional
> responses, or a non-2xx responses. Then, the TCP connection goes down,
> so I have to establish a new one, to send the CANCEL or ACK. Now, since
> the remote party most likely isn't listening to the emphemeral port I
> will have to send the CANCEL/ACK to the port I originally got in the SRV
> lookup (or from configuration). I think it would be a good idea to also
> mention this case, since RFC3261 says that CANCEL and non-2xx ACKs MUST
> be sent to the same address, and port, as the INVITE.

Good point. We will have to clarify this in the revision of RFC 3261.

Thanks,

Gonzalo

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Mon, 07 Apr 2003 08:51:57 +0300

Hi Gonzalo,

Thanks for the reply! Comments inline.

> Contact or Record-Route entries.

[CHH] Via is used for responses, and assuming response messages are always
sent on the same connection where the request came from I am not really sure
it's needed for that (of course, the alias data MAY also be in the Via, if
needed).

The main idea of the "extended" (Rohan's draft) connect-reuse function, as I
have understood, is to be able to reuse the connection for all messages, in
BOTH directions, during the whole session. So, for that you need to have the
alias data also in the route information, so that a node can send a request
(in the "backward direction" of the call). And, requests are sent using the
route data.

> exisintg TCP connection indexed using the host name.

[CHH] Like I said, the data is also needed in the route information.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 07 Apr 2003 10:49:27 +0300

Christer,

the client wants the server to create an alias even if the server never 
sends requests back to the client within this dialog. The server may 
send requests that belong to different dialogs, for instance. Therefore, 
you argument in favor of Route loses its stregth.

In addition to that, having that information in the Via header field is 
quite good from the processing point of view. When you receive a 
request, you parse the Via header field to add a received parameter, for 
instance... it seems like a good time for creating the alias.

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 07 Apr 2003 12:10:31 +0300

Hi,

> instance... it seems like a good time for creating the alias.

True.

Another question:

Assume the connection goes down between two servers. Now, both create a new
connection at the same time, so we will have two connections between the servers
(this scenario is what the connect-reuse extension is supposed to avoid). Now, is
this something we should accept as something which can happen? I don't think we
can say that one of the servers to close one of the connections, because we don't
know which server would do it, and we don't know which connection it would
close...

And, since there are now two connections between the node, is there any priority
on which should be used when a request is sent: the connection (which our server
created) to the "real" port (which would be used if there was no existing
connection) of the other server, or the connection (created by the remote server)
to the emphemeral port of the other server?

Another question:

RFC3261 basically talks about re-use of connections in one direction. Also,
RFC3261 doesn't say (I appologise if it does and I missed it) anything about port
overriding ("use the connection even if the port of your lookup is different")
which the connect-reuse draft says. So, I would just like to confirm that it means
that a RFC3261 node, NOT supporting the connect-reuse extension, should send
requests to whatever port is has recieved, no matter if a connection already
exists to the same IP address, but another port?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Apr 2003 23:46:45 -0400

inline.

> know which server would do it, and we don't know which connection it would

It is not worth trying to figure out which to close. Both connections 
would exist.

> to the emphemeral port of the other server?

This is no different than the case where I have multiple TCP connections 
open to the same well-known port. The spec doesn't specify a load 
balancing algorithm across connections. Generally, you should prefer one 
  of them, rather than spreading across them, for reasons of congestion 
control. That probably needs to be said in rfc3261.

> exists to the same IP address, but another port?

Correct. In rfc3261, the combination of IP and port serve as the 
connection index.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com