Subject: RE: [SIP] CANCEL and stateless proxies

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Oct 2000 03:17:56 -0400

This issue is actually more closely related to the SRV discussion. Your
issue with CANCEL could just as well be applied to retransmissions. If I
send an INVITE through a proxy, how can I be sure that a retransmission of
the INVITE goes the same way?

The solution is the same we proposed for SRV. Stateless proxies should route
requests within the same transaction to the same destination. Doing this
more generally than SRV is a bit harder, but here are some guidelines:

1. if the proxy routing logic depends on some static information plus a
random variable, make sure that random variable is generated so that it is
invariant across requests for the same transaction (hash of transaction,
take N bits, works well)

2. if the proxy routing is not dependent on things that have temporal
variations, and not dependent on randomization, you should have no problem.

3. if the proxy routing does have temporal variations, well, in this case
the proxy might really need to store some state around transition times.
This may seem unreasonable, but consider this: a proxy whose routing can
change as a function of time basically is a forking proxy, since it might
send an INVITE one way, and then a retransmission another way. We have a
requirement that forking proxies must be stateful. So, if you can't prevent
forking, you can't be stateless. 

-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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2000 6:05 AM
> To: [email-masked]
> Subject: [SIP] CANCEL and stateless proxies
> 
> 
> Hi,
> 
> A CANCEL request for a previous INVITE follows the same path as
> the INVITE. This 
> way the CANCEL request arrives to the same set of hosts as the
> INVITE.
> 
> Stateful proxies storing transaction state perform this routing
> fine.
> 
> What about stateless proxies? The CANCEL might be routed in a
> different way than 
> the previous INVITE.
> 
> This issue is somehow related to the "BYE after a INVITE"
> issue. It is 
> preferable to send a CANCEL rather than a BYE after a INVITE
> because stateful 
> proxies storing transaction state will route the CANCEL
> properly. The BYE might 
> be routed in a wrong way.
> 
> My question is: the same way proxies storing just transaction
> state (not call 
> state) might route a BYE to a different host than the previous
> INVITE, a 
> stateless proxy might route a CANCEL in a wrong way. What am I
> missing?
> 
> Thanks,
> 
> Gonzalo
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip