Subject: RE: [SIP] Issue with domain names in Via header

From: "Arnoud van Wijk (ELN)" <[email-masked]>
Date: Thu, 15 Mar 2001 10:28:03 +0100

Hello Jonathan,
I agree with this. Also, this will enable us to have more then one domain name for each proxy.
(in case of Virtual providers probably0.

Greetz

Arnoud van Wijk

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: woensdag 14 maart 2001 23:25
To: [email-masked]'
Cc: Jonathan Rosenberg
Subject: [SIP] Issue with domain names in Via header

Folks,

There is an issue with via processing that prevents a useful feature from
being applied.

The problem is the following. Proxy P1 inserts a via with a domain name,
proxy1.foo.com, and forwards it to proxy 2. Proxy 2 checks the via, and
since it doesn't match the source IP address where the request came from
(they are not equal), inserts a received parameter with that IP address,
1.2.3.4. It forwards the request. When its time to send a response, P2 looks
at the Via, sees there is a received param, and uses the IP address present
there to forward the response. 

As a result of this, insertion of domain names in Via accomplishes nothing.
Ideally, I'd like to be able to insert a domain name which resolves to an
SRV record; that record having, in the example above, the highest priority
for 1.2.3.4, and lower priorities for backups. The result of this is that a
proxy could fail mid-transaction, and another can step in to take its place
to forward the response. Right now, this capability won't work.

To fix it, is simple. I would suggest modifying the text in 6.47.1, which
currently reads:

>A proxy SHOULD check the top-most Via header field to ensure that it
contains the sender's 
>correct network address, as seen from that proxy. If the sender's address
is incorrect, the 
>proxy MUST add an additional "received" attribute, as described in Section
6.47.2.

to:

A proxy then checks the top-most Via header. If it contains a domain name,
or it contains an IP address which is not equal to the one in the source IP
address of the request, the proxy SHOULD insert a "received" attribute into
that Via header, as described in Section 6.47.2.

Then, modify the rules in section 6.47.5, so that the third bullet, which
currently reads:

>Otherwise, if it is a receiver-tagged field (Section 6.47.2), send the
response to the 
>address in the "received" parameter, using the port indicated in the
"sent-by" value, or 
>using port 5060 if none is specified explicitly.

instead reads:

Otherwise, if it is a receiver-tagged field (Section 6.47.2), send the
response to the
address in the "received" parameter, using the port indicated in the
"sent-by" value, or 
using port 5060 if none is specified explicitly. If the sending the response
results in 
failure (such as an ICMP port unreachable), send the response to address in
the "sent-by" 
field.

The result of this change is that we send the response to the place the
request came from under normal conditions, but under failures, it can be
routed to a backup. This change is backwards compatible, and will result in
a nice feature, which is the reason usage of domain names was recommended in
the first place.

Comments?

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 15 Mar 2001 09:05:22 -0500

Change made in spec; can be backed out if necessary.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 15 Mar 2001 18:49:56 +0200

Hello,

> > a nice feature, which is the reason usage of domain names was recommended in

Very interesting addition. A stateless proxy will not be able to take
advantage of this, since it will not catch ICMP notifications, but a
stateful proxy will be able to bind the socket to the destination
address and make use of the mechanism Jonathan suggests.

I think after this addition there is just one missing piece in the
SRV/load-banacing/fail-over issue. Actually, it has a lot to do with
this.

Last september we added the following text to section 1.4.2 of bis:

   "Within a transaction, a stateless proxy MUST always select the same
   destination within the set of hosts with the same priority. This can
   be accomplished, for example, by using the modulo N of a hash of the
   Call-ID value or some other combination of transaction-identifying
   headers as the uniform random number described in the weighting
   algorithm of RFC 2782. Here, N is the sum of weights within the
   priority class."

I would suggest modifying this text to:

   "Within a transaction, a stateless proxy MUST always select the same
   destination within the set of hosts with the same priority. Within a
   session, a stateless proxy SHOULD always select the same destination
   within the set of hosts with the same priority. This can
   be accomplished, for example, by using the modulo N of a hash of the
   Call-ID value as the uniform random number described in the weighting
   algorithm of RFC 2782. Here, N is the sum of weights within the
   priority class."

The reasons for doing this are the following:

Adding To, From, Cseq, Top Via and Request-URI to the hash just improves
the randomization process within a session. However, within a session,
it is most likely that you want all the requests to go to the same
place. The call-Id is enough to randomize the selection for requests
belonging to different sessions. Therefore, the addition of "some other
combination of transaction-identifying headers " does not provide better
randomization and it reads less clear in the RFC.

With this addition we get a couple of features "for free".
1) There are several implementations that send a BYE instead of a CANCEL
when the user makes a call attempt and then gives up before receiving an
answer. If there are call stateful proxies in the network, they would
like to see this BYE. This addition allows all the proxies in the path
to see this BYE, although the Route header was not built yet.

2) I might send two instant MESSAGEs one after the other, very quickly
to another user. If the followed different paths, the receiving
application might be confused (the receiving application stores state
information, such as Route, for the IM session). Besides, they might
traverse different CPIM gateways (currently stateful). This addition
resolves this issue as well.

Therefore, I believe that with this addition everything we obtain is
positive.

Comments?

A related issue is how stateful proxies handle this. I would suggest to
have the same behavior as described above. This is very much related to
what Jonathan suggested:

Jonathan's suggestion for responses:
A stateless proxy sends responses to the "received" address, and it will
not be able to catch the ICMP notification. However, the stateful proxy
will. It also sends responses to the "received" address, but if it
receives an ICMP notification, it can then try the backup server.

My suggestion for requests:
If a stateful proxy is handling a particular trasaction and it receives
another request within the same session, it SHOULD choose the same
destination within the set of hosts with the same priority. If it
receives an ICMP notification, it can then try the backup server.

Comments?

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Neil Deason <[email-masked]>
Date: Fri, 16 Mar 2001 09:08:42 +0000

This doesn't fix the open issue with SRV randomisation
messing up attempts by stateless proxies to pick the 
same server.

http://lists.bell-labs.com/pipermail/sip/2000q4/003180.html

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 16 Mar 2001 23:09:27 +0200

Hello,

I am after a different issue.

Yours is solved by ordering the servers in a certain order
(alphabetical, for instance) before applying the process to choose one.

Regards,

Gonzalo