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 <sobo...@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
