Handle the case when CANCEL is responded with 200/OK but 487 is not sent #503
Description
2008-03-06 20:38:43: @bennylp created the issue on trac ticket 503
RFC 3261 Section 9.1:
-"Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543-compliant UAS will not generate such a response. If there is no final response for the original request in 64T1 seconds (T1 is defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request."
Currently PJSIP relies on 487 response being received, hence if it's not the INVITE/dialog will get stucked forever.
The corresponding ticket for 1.0.x branch is ticket #796.
2008-05-29 08:57:24: @bennylp changed milestone from release-0.9.0 to Known-Issues
2009-03-05 14:32:16: @bennylp changed milestone from Known-Issues to release-1.2
2009-04-26 12:02:31: @bennylp changed status from new to closed
2009-04-26 12:02:31: @bennylp set resolution to fixed
2009-04-26 12:02:31: @bennylp commented
Fixed in r2646:
- added new API pjsip_tsx_set_timeout()
- set 64*T1 timeout after CANCEL is initiated
- also added SIPp scenario to simulate the UAS
2009-04-26 12:06:35: @bennylp edited the issue description