Iñaki Baz Castillo wrote:
> 2008/12/22 karthik karthik <karthik.class...@gmail.com>:
>> step3.
>> meanwhile the callee has sent 200(invite) without 18x directly.
>> ue<--200(invite)--pcscf<--200(invite)--scscf<--200(invite)--
>> ue--ack-->pcscf--ack-->scscf--ack-->
>> ue sends an ack though it had already sent a cancel.
>>
>> what is the expected bahaviour at pcscf?
>> pcscf knows it has sent 200(cancel) to ue.
>> still it forwards answer 200(invite) to ue since it is not a b2bua.
> 
> 
> 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.

As it was correctly said before, any proper UAC implementation should be 
prepared to receive final positive reply to INVITE transaction even 
after CANCEL transaction has ended up in final positive as well. There 
is nothing wrong with it, it's just a result of message propagation over 
network having a finite speed.

Regards,
-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to