Hi budy, Cancel timer B on provisional respone for ICT is RFC compliant. Transaction layer *should* behave in that way. It's TU's responsibity to handle the case the call stays there forever. The issue is caused currently, by PJ lack of a mechanism of Dialog/Session timer management. Benny has marked them out but hasn't implemented that. Cases need to be handled: 1. Only provisional response is received Though proxy may send 487 on timer C triggered. UA SHOULD can terminate the call after a pre-configured timer duration 2. 1xx received, then caller cancels the call manually, however for some reasons, no 487 sent back As the case mentioned by Amit. Compared to case 1, CANCEL is involved. RFC 3261 has described the way to handle this case, by use of a timer to terminate the call if 487 not seen 3. No ACK received for 2xx(for INVITE), UAS side And even more complex cases, ex1. BYE lost Session timer can be used to deal with such case. ex2. Found by you =================================================================================== Hi, I have noticed that the timer B is cancelled even if a provisional response is recieved for the invite transaction. This leads to call slots not being freed in case no final response is recieved for the initial invite. A case for the above is where the invite is cancelled and the uas doesn't send a 487. The behavior seems to be against rfc3261. >From rfc3261 Section 9.1 ==================================================== 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. ================================================= I think line 2114 in sip transaction.c is causing this bug. Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080307/aa62a6ed/attachment.html
