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

[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.

[bennylp]

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