On 06/11/2011 01:18 PM, Iñaki Baz Castillo wrote:
> 2011/6/11 Joegen E. Baclor<[email protected]>:
>> I agree with this. Yes I followed this thread closely from the start.   The
>> question was a "why" (not where it is stated in the RFC) for the sake of
>> those, including myself, understand how a very basic scenario such as call
>> cancellation gets this very lengthy discussions up to now.  Clearly,
>> misinterpretation due to vagueness is the cause.
> My first question in the thread was similar to your previous one:
> "does the server/client transaction *status* change in the proxy when
> a CANCEL is received by it (so algo generated by it)?". The answer is
> not, nothing changes in the proxy's server/client transactions.
> Instead, the UAS's are supposed to reply 487 upon receipt of the
> CANCEL, and such 487 will terminate client transaction(s) in the
> proxy, and at the end, will also terminate the server transaction in
> the proxy (when it forwards the winning final reply upstream).

As implied in 16.10 ...


> Later in the thread I asked about how a proxy should behave when
> receives a CANCEL but cannot cancel pending branches because no 1XX
> response has been received yet from them. In the exotic case in which
> some branch replies a later 1XX the proxy should automatically send
> the CANCEL downstream (but it should still forward the 1xx response to
> the UAC).
>
As described in section 16.7 item 10  which drills down to section 9.1  ...


I have no issues here.  As i've said I followed this thread closely.  My 
point is, 16.10 has this implied by not mentioning that the response 
context will change in state or not.  Having not mentioned it, perhaps 
it implies no change in state is the correct interpretation.  Being 
implied, the reason is so vague  (as to why) make it really easy to 
misinterpret things.  This probably triggered your very first question 
that opened this thread.  Perhaps a text amendment is in order.



_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to