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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Mar 2001 01:08:07 -0500

Gonzalo,

Not a bad idea. The cases that it covers are corner cases, I think (cases
where subsequent messages in a call leg get sent before a Route is
established), but they are valid cases nonetheless. Of course, just because
the SRV results in the same next hop doesn't mean the routing processes will
be the same (i.e., the higher level routing process might be randomized, or
the logic might have changed). 

-Jonathan R.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 11:50 AM
> To: Henning Schulzrinne
> Cc: Arnoud van Wijk (ELN); Jonathan Rosenberg; 
> [email-masked]'
> Subject: Re: [SIP] Issue with domain names in Via header
> 
> 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]
> 

---
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: Gonzalo Camarillo <[email-masked]>
Date: Sat, 17 Mar 2001 22:29:30 +0200

Jonathan,

Jonathan Rosenberg wrote:
> established), but they are valid cases nonetheless.

Yes, they are not common cases but, as you said, they are valid. Even
more taking into consideration that section 10.3.1 of RFC2543bis
RECOMMEMDS to send both a BYE and a CANCEL if after retransmitting a
particular INVITE there is no answer.

I will be suggesting this change in my presentation on Tuesday.

> Of course, just because

Yes. I was just talking about DNS level randomization.

Anyway, high level routing logic does not represent a problem. A
stateless proxy does not implement this kind of logic, since otherwise
it would not be able to ensure that re-INVITEs and CANCELs follow the
first INVITE. A stateful proxy have to give higher priority to the rules
I was mentioning than to his own routing logic.

For instance, a proxy routes requests for sip:[email-masked] to
sip:[email-masked] until noon, and to sip:[email-masked] after noon.
If the proxy receives an INVITE at 11:59:55 and then a BYE at 12:00.02,
we do not want Bob's SIP phone to be ringing for ever. It will have to
send the BYE to Bob because it belongs to the same call, rather than
sending it to Laura because it is after noon.

Therefore, I do not think that high level logic represents a problem.

Gonzalo