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

From: Igor Slepchin <[email-masked]>
Date: Fri, 16 Mar 2001 19:19:03 -0500

I think this could be solved fairly easily for response failover case if we
require that proxy servers always add the received tag with the source IP.
They would then always send the response to that IP first and perform a DNS
lookup only if sending to the address in received failed. 

This may also be generally useful since stateless proxies would not be
required to perform a DNS lookup before sending responses...

---
Igor Slepchin

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Friday, March 16, 2001 4:09 AM
> To: Gonzalo Camarillo
> Cc: Henning Schulzrinne; Arnoud van Wijk (ELN); Jonathan Rosenberg;
> [email-masked]'
> Subject: Re: [SIP] Issue with domain names in Via header
> 
> 
> 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
> 
> Gonzalo Camarillo wrote:
> > 
> > Hello,
> > 
> > > > 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.
> > 
> > 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?
> 
> _______________________________________________
> 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.
> 

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Sat, 17 Mar 2001 02:35:02 +0200

Hello,

The response problem is already solved. What I was saying is that my
issue is very related to the one that Jonathan pointed out. His was
about responses. Mine is about requests.

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]