Subject: [SIP] RE: CANCEL - response sequence issue (again)

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 23 Oct 2000 01:25:22 -0400

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, October 20, 2000 6:02 PM
> To: [email-masked]
> Cc: Jonathan Rosenberg; [email-masked]
> Subject: Re: CANCEL - response sequence issue (again)
> 
> 
> 
> > Would it be possible to add what Jonathan Rosenberg 
> suggests below for
> > backward compatibility in a CANCEL/200 OK/487 Request Terminated
> > scenario.  This appears to be the cleanest solution.
> 
> Let me see if I can summarize the cases here:
> 
> - if call *was* established before CANCEL arrived (call exists)
>   200 (INVITE) is returned within 32s in RFC 2543 or bis
>   200 (CANCEL) is returned
> 
> - call failed before CANCEL arrived (no call in progress)
>   4xx/5xx (INVITE) is returned
>   200 (CANCEL) is returned
> 
> - if call was *not* yet established before CANCEL arrived (i.e., call
> does not exist)
>   200 (CANCEL) is returned
>   487 (INVITE) is returned if -bis, nothing if RFC2543
>   (arriving in either order)
> 
> This is presumably the case that is of concern. The UAC or proxy can't
> tell whether the 200 (INVITE) is just late (first case) or will never
> show up (third case, RFC2543).
> 
> For a proxy, would any state be needed, as long as the ACK can be
> generated for any late 487?

You can't generate an ACK statelessly. Thats because the request URI has to
be the same as the original request, so you need to remember it. Thus, the
proxy will need state, and this timer helps destroy that state when its
talking to a pure 2543 UAS or proxy which won't send 487.

> 
> For a UAC, may it have to wait the 32s just in case the call was
> established after all?

Waiting the full 32s is needed only in the extremely unlikely case of a
complete network outage lasting at least 32s, and recovering just before the
last final response is sent. Whilst one can argue that waiting this full
amount is more important for a UA than a proxy, I would much prefer to keep
these state machines the same in each case, and so use the same timer.

-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

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

---

From: Neil Deason <[email-masked]>
Date: Mon, 23 Oct 2000 14:04:06 +0100

Is there a general consensus whether the Require or 
Proxy-Require header should be used by clients to request
features of a Registrar? Require seems more correct as the
Registrar is the terminating server. However, a Registar
is typically co-located with a proxy. Maybe a clear 
statement in the spec would remove any scope for confusion.

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

---

From: Sean Olson <[email-masked]>
Date: Mon, 23 Oct 2000 15:15:18 +0200

I think this would depend on the feature you are trying to request
and whether you want the Registar to support the feature as a
proxy, server, or both. It seems clear to me. Maybe you could
give an example that would clarify the problem you have.

/sean
--
Sean Olson <[email-masked]>