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

List:       sip-implementors
Subject:    Re: [Sip-implementors] CANCEL - 200 IINVITE crossover.
From:       "Rockson Li (zhengyli)" <zhengyli () cisco ! com>
Date:       2008-12-23 3:36:38
Message-ID: F86B91A10B14744E88408E80B8A30EF303FEC610 () xmb-hkg-412 ! apac ! cisco ! com
[Download RAW message or body]

I agree with Paul here, 
Actually the 200(CANCEL) just means the proxy got the CANCEL,
It does not mean the request is cancelled or proxy would be ensure the req being \
cancelled. Normally, Proxy would send the CANCEL downstream, however, since there's \
no provisional resp, Proxy has no means to complete the task.
UAC should be prepared to get the 200(INVITE) and reacts accordingly.

Thanks
-Rockson 

-----Original Message-----
From: sip-implementors-bounces@lists.cs.columbia.edu \
[mailto:sip-implementors-bounces@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat \
                (pkyzivat)
Sent: Tuesday, December 23, 2008 9:24 AM
To: Iņaki Baz Castillo
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] CANCEL - 200 IINVITE crossover.

I don't understand why stateless forwarding has been mentioned in the context of this \
question. AFAIK it has no relevance.

If we assume that the pcscf in the question is a transaction stateful proxy (and I'm \
pretty certain that any IMS implementation would be), then when the 200 INVITE is \
received, there *will* be a matching transaction for it.

The original responder is correct - there is no problem here at all. The UAC must be \
prepared to receive a 200 even though it sent a CANCEL, and it then may do whatever \
it wants (after sending the ACK) - it can keep the call, send a  BYE to the call, ...

	Thanks,
	Paul

Iņaki Baz Castillo wrote:
> 2008/12/22 Maxim Sobolev <sobomax@sippysoft.com>:
> 
> > > Alto consider the following draft:
> > > http://tools.ietf.org/html/draft-sparks-sip-invfix-02
> > > 
> > > It states that a transaction statefull proxy mustn't forward a 200 
> > > stateless, so in your case the 200 OK wouldn't arrive to the UAC (if 
> > > the proxy honors the above draft).
> > No, I believe your reading is incorrect. If proxy somehow absorbs 200 
> > OK so that it won't arrive to UAC in such situation then the dialog 
> > would remain in half-connected state - with UAS retransmitting 200 OK 
> > waiting for E2E ACK (proxy can't generate E2E ACK) and UAC still 
> > waiting for the final negative or positive response to its INVITE 
> > transaction. Eventually UAS would timeout and probably generate BYE 
> > in a desperate attempt to tear down the dialog, but since UAC has not 
> > received final response to INVITE it would reject BYE as out-of-order 
> > and continue waiting indefinitely (probably until transaction 
> > expiration timer hits). This would make things even more broken than they were in \
> > the example above.
> 
> Ok, so a proxy implementing draft-sparks-sip-invfix-02 just can drop a 
> stateless 200 OK for an INVITE in case it knows nothing about that 
> transaction. In the case above the proxy does know about the INVITE 
> transaction since it still has no final reply for it (even if the 
> proxy has received a CANCEL from upstream).
> 
> Thanks for pointing it.
> 
> 
> 
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


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