The behavior is expected, and is inline with the SIP spec. If call gets established after CANCEL is sent, then we'll let it continue to get established, and it is then user or app decision whether to continue or not. If not, then it should call hangup() one more time. We may change this behavior in the future though to make it do like what you want, though there's no definite plan for this yet. Patches would be welcome of course. Best regards, ?Benny On Mon, Sep 6, 2010 at 11:29 PM, Viktor Krikun <v.krikun at gmail.com> wrote: > Hello everyone, > > Writing some unit tests for my pjsua-based app I discovered an issue in call closing from CALLING state: Alice calls Bob, on switching to PJSIP_INV_STATE_CALLING Alice cancels the call (pjsua_call_hangup). As result the call never get canceled. > > That what I learned from Alice's logs: > 1. ?Tx INVITE > 2. pjsua_call_hangup() says "Delaying CANCEL since no provisional response is received yet" > 3. Rx 1XX (100 or something, ready to send CANCEL) > 4. Tx CANCEL > 5. Rx 200 OK. Note: SDP included multiple codecs. > 6. Tx ACK for the INVITE > 7.PJSUA says "Got answer with multiple codecs, start updating media session to use only one codec.." reINVITE initiated > 8. Rx 200 OK ?for the CANCEL > 9. Rx 100 Ringing, Rx 200 OK, Tx ACK (for the new, reINVITE ?SIP dialog ) > > In result we have new SIP Session established (after re-invite to negotiate single codec) which wouldn't be canceled. > > PS: full logs are attached. > > Have I missed something? ?Thanks for your help in advance! > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >
