Inline... ========================================================================================== On 3/6/08, ims3g at 126.com <ims3g at 126.com> wrote: > > 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 I guess in this case the user will just hangup. ? [aka]: That's true. RFC does not standardize the behaviour in that case. It's up to the application to decide. FYI, some user agents give alternative choice as I describe. ? > 2. 1xx received, then caller cancels the call manually, however for some > reasons, no 487 sent back True, currently this is not handled. I've added http://trac.pjsip.org/repos/ticket/503 for this. > 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 > Yep, those could be solved with session timer. cheers, -benny _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080307/b971e24f/attachment.html
