[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] Question	regardingdraft-hasebe-sipping-exceptional-procedure-examples-02.
From:       "Dale R. Worley" <dworley () pingtel ! com>
Date:       2006-05-29 2:08:20
Message-ID: 1148868500.28687.75.camel () niagra ! pingtel ! com
[Download RAW message or body]

On Thu, 2006-05-18 at 18:41 -0400, Paul Kyzivat wrote:
> Because this is a bug where the fix hasn't been formally fixed, I don't 
> think it is safe to assume *either* that it has been fixed or it hasn't. 
> So I think a BCP should allow both, with an explanation.

As Venkatesh points out, fixing the bug wouldn't change the apparent
behavior from the UAC's point of view, as CANCEL is hop-by-hop and a 200
response to it can only indicate that the next (stateful) hop has a
record of the request in question, and cannot be guaranteed to tell
about the UAS's state.

But even without that point, it's clear that the interaction of CANCEL
and a transaction is messy, and there's a lot of uncertainty and
disagreement on the proper response codes for CANCEL, and
implementations are likely to be inconsistent.  So one should judge
whether a CANCEL worked or not only by the response to the INVITE, which
is something implementations are likely to get right.

Dale



[prev in list] [next in list] [prev in thread] [next in thread]