Opened 16 years ago

Closed 15 years ago

Last modified 15 years ago

#503 closed defect (fixed)

Handle the case when CANCEL is responded with 200/OK but 487 is not sent

Reported by: bennylp Owned by: bennylp
Priority: normal Milestone: release-1.2
Component: pjsip Version: trunk
Keywords: Cc:
Backport to 1.x milestone: Backported:

Description (last modified by bennylp)

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 64*T1 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.

Change History (4)

comment:1 Changed 16 years ago by bennylp

  • Milestone changed from release-0.9.0 to Known-Issues

comment:2 Changed 15 years ago by bennylp

  • Milestone changed from Known-Issues to release-1.2

comment:3 Changed 15 years ago by bennylp

  • Resolution set to fixed
  • Status changed from new to closed

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

comment:4 Changed 15 years ago by bennylp

  • Description modified (diff)
Note: See TracTickets for help on using tickets.