Subject: RE: CANCEL and Record-Route; was: RE: [SIP] Re: My comments on bi s-02

From: Igor Slepchin <[email-masked]>
Date: Tue, 5 Dec 2000 15:48:00 -0500

> > A proxy might be stateless and still record-route. Route 
> > actually does make
> > sense in a CANCEL in this scenario.
> 
> I think this is far more complex than it first seems.
> <...>
> A ---- P1 ----- P2 ------ P3 ------ B
> terminated by P3. So, its P1 that needs to insert Route into 
> CANCEL. Where
> does this route come from? From the RR in the final response 
> to INVITE? 

No, certainly not. It is taken from the request being CANCELed. This is only
useful (and only needed) for consecutive signaling, e.g., for reINVITEs.

In you scenario, stateful P1 would copy Route header from reINVITE to CANCEL
for that reINVITE. Stateless P2 would then receive a CANCEL with the same
Route as the reINVITE being CANCELed. This will ensure that CANCEL goes to
precisely the same place as the request.

> Adding RR to CANCEL seems a big, big departure from what we 
> have been doing
> until now. I'd much rather not do this.

This sounds more like an optimization to me. It eliminates the (somewhat
unlikely) chance that a sateless proxy would route CANCEL differently from
the request being CANCELed (due to some time-based logic, for example). I'm
not sure why this is a huge departure from what we have now but I don't
think that this change is critically needed either.

---
Igor Slepchin

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Dec 2000 18:39:48 -0500

> -----Original Message-----
> From: Igor Slepchin 
> Sent: Tuesday, December 05, 2000 3:48 PM
> To: Jonathan Rosenberg; Igor Slepchin; 'Billy Biggs'; Henning G.
> Schulzrinne
> Cc: SIP List
> Subject: RE: CANCEL and Record-Route; was: RE: [SIP] Re: My 
> comments on
> bis-02
> 
> 
> No, certainly not. It is taken from the request being 
> CANCELed. This is only useful (and only needed) for 
> consecutive signaling, e.g., for reINVITEs.

Ah. Problem is, these are the requests least likely to be cancelled. 100% of
the usage of CANCEL to date is for the original INVITE request, I would bet.

> 
> In you scenario, stateful P1 would copy Route header from 
> reINVITE to CANCEL for that reINVITE. Stateless P2 would then 
> receive a CANCEL with the same Route as the reINVITE being 
> CANCELed. This will ensure that CANCEL goes to precisely the 
> same place as the request.

Hmm. So the request arrives at P3 from stateless proxy P2. Now, the proxy
after P3 is P4, but P4 didn't record route. The Route in CANCEL thus points
to P5 next (since P5 did record-route). Now, based on this, P3 would forward
the CANCEL to P5, since thats the one listed in the Route. But, this is
wrong. The CANCEL should traverse P4 as well.

> This sounds more like an optimization to me. It eliminates 
> the (somewhat unlikely) chance that a sateless proxy would 
> route CANCEL differently from the request being CANCELed (due 
> to some time-based logic, for example). I'm not sure why this 
> is a huge departure from what we have now but I don't think 
> that this change is critically needed either.

Since this is only useful for CANCELing re-INVITE, AND only when stateless
proxies record-route, AND there are issues when the original INVITE path and
Record-Route path are not the same, I'd prefer not do this.

-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